5.2.1-009 и IP-пулы.

[Wishmaster]

Всем привет! Назрел тут вопрос, не научился ли УТМ в свежих версиях отдавать IP из пула стандартными средствами, без костылинга с free-radius. Ну, например, чтобы в ip-группе вместо IP можно было указать пул и оно бы работало. Сам использую 006, а в документации к новой версии упоминаний не нашел. Кто использует 009 поделитесь инфой пожалуйста.

Спасибо.

[serjk]

В 006 так же в IP-группе можно указать подсеть, а не один адрес. И RADIUS будет выдавать уникальные адреса из этой сети. Или что-то другое имеется в виду?

В целом, рекомендую обновить до 008 или 009 - они гораздо стабильнее, и в случае обнаружения проблем их проще исправить.

[Wishmaster]

Если разным пользователям в разных ip-группах указать одну и ту же подсеть, будет ли нормально выдавать? Дублей не будет? И второе, как быть, если пул состоит из нескольких сеток, которые нельзя объединить общей маской? Было бы здорово сделать так, чтобы вместо ip можно было указать ippool name, а уже в настройке ippool добавить нужные диапазоны. Вполне логичное, на мой взгляд, решение.

Апгрейдиться на 009 нам особого смысла нет, все работает, кроме того, прикручен ряд костылей. Будем переходить уже сразу на 5.3, отсюда и вопрос был в соседней теме.

Спасибо!

[serjk]

Пересекающиеся диапазоны адресов в IP-группах по-прежнему нельзя задавать, но идея интересная. Имя пула так же можно задать только для dialup услуг.

Относительно нескольких подсетей в одном пуле - в следующем 009-update такая возможность будет (функционал реализован и работает). Пока для этого нужно добавить несколько IP-пулов с одним именем. RADIUS может выдавать адреса как последовательно, так и из случайного диапазона.

[Wishmaster]

Пересекающиеся диапазоны адресов в IP-группах по-прежнему нельзя задавать, но идея интересная. Имя пула так же можно задать только для dialup услуг.

Относительно нескольких подсетей в одном пуле - в следующем 009-update такая возможность будет (функционал реализован и работает). Пока для этого нужно добавить несколько IP-пулов с одним именем. RADIUS может выдавать адреса как последовательно, так и из случайного диапазона.

Да, я забыл уточнить, речь идет об услуге "Передача IP-трафика".
А с чем связано ограничение использования пулов IP в других услугах? Просто любопытно. По логике, биллинг оперирует единой структурой и массивом IP, и по большому счету, ему должно быть глубоко фиолетово, к какой услуге этот IP привязан. Или не так? Вообще, если, как вы говорите, частично этот функционал уже работает, может есть смысл допилить его до полноценного варианта, по типу того, что я описал?

[Wishmaster]

В догонку к предыдущему сообщению:

Чтоб была понятна суть предложения, опишу ситуацию. Сейчас мы используем ВПН+НАТ, у нас около 10 серверов, IP прописаны статически в УТМ. Руководство озаботилось уходом от НАТ, значит нужно или всем привязывать статически реальники либо выдавать через пул. Есть около 10 сеток реальников на /24, причем из разных подсетей, которые нельзя обединить в один кусок.

Будь в биллинге возможность сделать пул с несколькими сетками и указать его в настройках сервисной связки - ip-группы, проблема решалась бы за 10 минут. А так получается - проблема не имеет адекватного решения.

[serjk]

В целом, этот случай охватывается функционалом динамического распределения IP-адресов (услуга dialup + услуга передачи трафика). Этот вариант в чем-то не подходит?

[Wishmaster]

В целом, этот случай охватывается функционалом динамического распределения IP-адресов (услуга dialup + услуга передачи трафика). Этот вариант в чем-то не подходит?

Честно сказать, я не пробовал совмещать эти услуги. Попробую. Спасибо за подсказку.

[Wishmaster]

Прочитал еще раз мануал, попробовал вашу рекоммендацию, но увы, это не то. У многих клиентов в сервисных связках IP-трафика по нескольку IP-групп. Допустим, у человека есть 3 IP-группы, соответственно 3 логина, ему требуется один фиксированный ip, а остальные - не важно. Сейчас мы фиксированно ставим рельник на одну ip-связку, и на две оставшиеся также фиксированно прописываем фейковые IP из сетки 172.16 для NAT. Коммутируемый доступ, как я понял, предлагает только одну связку логин-пароль, но с возможностью мультиконнекта.

Если я не прав, поправьте пожалуйста. И, если возможно, не могли бы вы подробнее описать алгоритм, как применить существующий функционал для решения указанной задачи?

Спасибо!

[serjk]

Да, сервисная связка dialup имеет один логин и пароль.

Относительно представленной схемы, динамическое распределение IP адресов нужно тестировать (создать связку передачи трафика с одним статическим адресом/логином и связки dialup с динамическим распределением адресов и ограничением на количество сессий, либо несколько связок dialup). Cитуация достаточно нестандартная.

[Wishmaster]

Да, сервисная связка dialup имеет один логин и пароль.

Относительно представленной схемы, динамическое распределение IP адресов нужно тестировать (создать связку передачи трафика с одним статическим адресом/логином и связки dialup с динамическим распределением адресов и ограничением на количество сессий, либо несколько связок dialup). Cитуация достаточно нестандартная.

Если честно, то ничего сильно "нестандартного" в ситуации нет. У биллинга есть функционал создавать услугу передачи IP трафика, есть штатный функционал добавления в эту услугу неограниченного количества связок логин-IP. Вполне логично иметь механизмы как явного ручного указания IP адреса, так и автоматического.

То, что вы предлагаете с dial-up очень сложно реализуемо и совершенно непонятно, насколько беспроблемно это будет работать.

Если уж вы переписываете систему почти полностью (по словам ваших коллег), может возможно внедрить функционал, который позволит использовать пулы в любых услугах, где используется IP адрес, без шаманства и костылестроения. Спасибо!

[serjk]

По сути, Вы предлагаете более удобный вариант динамического распределения адресов, т.к. системе в любом случае придется привязывать конкретный IP из пула к сервисной связке. Предложение интересное, будем думать.

Хотелось бы услышать мнение других пользователей по этому функционалу.

[Витька]

По сути, Вы предлагаете более удобный вариант динамического распределения адресов, т.к. системе в любом случае придется привязывать конкретный IP из пула к сервисной связке. Предложение интересное, будем думать.

Хотелось бы услышать мнение других пользователей по этому функционалу.

Было бы очень здорово, если бы для динамического распределения адресов был придуман какой-то более внятный механизм, чем сейчас.
К счастью, у нас нет необходимости считать трафик на динамических адресах, поскольку они доступны только на безлимитах. Поэтому сейчас в тарифы впн у нас входят три услуги - передача ip-трафика. диалап и абонка. Если абонент хочет статику, мы подключаем передачу трафика. Хочет динамику - отключаем передачу трафика, подключаем диалап.

В итоге в личном кабинете для этого куча костылинга, чтобы скрыть внутренности от абонента и дать ему просто переключатель "статический адрес" - "динамический адрес".

С точки зрения удобства использования гораздо разумнее было бы в свойствах IP-группы отказаться, как это ни странно, от обязательного ввода IP-адреса. Просто ввести галочку "динамическая раздача" непосредственно в окне IP-группы услуги передача трафика. Но это мечты-мечты.

[Витька]

По сути, Вы предлагаете более удобный вариант динамического распределения адресов, т.к. системе в любом случае придется привязывать конкретный IP из пула к сервисной связке. Предложение интересное, будем думать.

Хотелось бы услышать мнение других пользователей по этому функционалу.

Было бы очень здорово, если бы для динамического распределения адресов был придуман какой-то более внятный механизм, чем сейчас.
К счастью, у нас нет необходимости считать трафик на динамических адресах, поскольку они доступны только на безлимитах. Поэтому сейчас в тарифы впн у нас входят три услуги - передача ip-трафика. диалап и абонка. Если абонент хочет статику, мы подключаем передачу трафика. Хочет динамику - отключаем передачу трафика, подключаем диалап, то есть не совмещаем эти две услуги, как написано в руководстве.

В итоге в личном кабинете для этого куча костылинга, чтобы скрыть внутренности от абонента и дать ему просто переключатель "статический адрес" - "динамический адрес".

С точки зрения удобства использования гораздо разумнее было бы в свойствах IP-группы отказаться, как это ни странно, от обязательного ввода IP-адреса. Просто ввести галочку "динамическая раздача" непосредственно в окне IP-группы услуги передача трафика. Но это мечты-мечты.

[Wishmaster]

По сути, Вы предлагаете более удобный вариант динамического распределения адресов, т.к. системе в любом случае придется привязывать конкретный IP из пула к сервисной связке. Предложение интересное, будем думать.

Хотелось бы услышать мнение других пользователей по этому функционалу.

Было бы очень здорово, если бы для динамического распределения адресов был придуман какой-то более внятный механизм, чем сейчас.
К счастью, у нас нет необходимости считать трафик на динамических адресах, поскольку они доступны только на безлимитах. Поэтому сейчас в тарифы впн у нас входят три услуги - передача ip-трафика. диалап и абонка. Если абонент хочет статику, мы подключаем передачу трафика. Хочет динамику - отключаем передачу трафика, подключаем диалап, то есть не совмещаем эти две услуги, как написано в руководстве.

В итоге в личном кабинете для этого куча костылинга, чтобы скрыть внутренности от абонента и дать ему просто переключатель "статический адрес" - "динамический адрес".

С точки зрения удобства использования гораздо разумнее было бы в свойствах IP-группы отказаться, как это ни странно, от обязательного ввода IP-адреса. Просто ввести галочку "динамическая раздача" непосредственно в окне IP-группы услуги передача трафика. Но это мечты-мечты.

IP пулов может быть несколько, для разных условий и нужд. Так что логичнее как раз вписать вместо IP адреса имя ip-пула, тем самым активируя динамическое распределение конкретного пула. Хочешь статику - вбей IP. Если делать галочку, то тогда нужен еще и dropbox со списком ip-пулов, что усложнит и так не сильно простой интерфейс.