Задача.
Необходимо разделить пользователей PPTP VPN на тех, кто выходит в Интернет с использованием NAT и кто не пользуется NAT-ом. Очевидно их надо разбросать по разным подсетям и одну сеть натить, а другую - нет.
В Abills для этого можно использовать IP Pool. Для этого читаем внимательно http://abills.net.ua/wiki/doku.php/abills:docs:modules:dv:ru и находим параметр IP Pool.
Переходим в Система -> Интернет -> Тарифные планы и привязываем наш пул к тарифному плану:
После применяем к пользователю тарифный план и все должно работать. Для этого переходим Клиенты -> Логины -> Информация -> Сервисы -> Internet -> Тарифные планы
Важная вещь. Например, у нас есть 3 тарифных плана 1Mbit, 3Mbit, 5Mbit. Названия говорят сами за себя. Я не придумал ничего, кроме того, чтобы пользователю применять тарифный план. Но если так, то необходимо привязать пул к тарифному плану. Для этого на 1 скорость я создаю 2 тарифных плана: 1Mbit-NAT и 1Mbit-NONAT. Названия говорят сами за себя и соответствуют нашим пулам. Несколько громоздко, но работает. И еще, Тарифные планы легко делят между собой один и тот же пул адресов.
UPD1: Все было бы хорошо, если бы не было так печально.
Вылезла одна проблема при переводе на пулы. Раньше пользователю VPN вбивался статический IP и это было нехорошо. Решили ж сразу если и приводить все в божеский вид то и адреса раздавать из пулов автоматически. Хочешь повесить разные ACL - делай пул и вешай ACL на него. И тут случилось горе. Интернет стал работать нестабильно. Причина как оказалась банальная.
Когда в Abills-е меняешь статику на динамику то по логике надо просто в свойствах пользователя затереть статический IP-адрес, что и было успешно сделано с несколькими пользователями. Проверив работоспособность такой схемы, настройки были завершены..., а с утра мы получили нестабильно работающий Интернет.
В чем была причина? Осмотр показал нормальную работу биллинга, настроек VPN-соединения, вроде маршрутизатор работал в штатном режиме. Далее причина оказалась простая: Если чистишь статический IP, как было написано выше, то ЭТОНЕПРАВИЛЬНО! После того как очищается IP и нажата кнопка "Изменить", Abills решает вбить в пустые поля значения 0.0.0.0 0.0.0.0 для адреса и маски. Выглядит это примерно так:
Это приводило к тому, что в таблице маршрутизации появлялись все новые маршруты в 0.0.0.0, указывающие на IP-адрес выданного VPN-клиенту. Маршруты были с кодом U (U - per-user static route) и появлялись при новом подключении каждого неправильно переведенного пользователя на динамический адрес.
Век живи - век наступай на грабли.
Вописанном случае приходилось сбрасывать сессии, которые "подвисли" на маршрутизаторе и не были видны из интерфейса биллинга. Небольшой пример как с этим бороться.
Как сбросить сессию не с биллинга, а непосредственно с Cisco-роутера.
Смотрим идентификатор туннеля (TunID), который хотим сбросить:
И убиваем его, сразу же проверяя жив ли он:
Все, туннеля с TunID 130 больше нет на нашем маршрутизаторе.
PS: Есть предложения и замечания? Сообщайте.
Необходимо разделить пользователей PPTP VPN на тех, кто выходит в Интернет с использованием NAT и кто не пользуется NAT-ом. Очевидно их надо разбросать по разным подсетям и одну сеть натить, а другую - нет.
В Abills для этого можно использовать IP Pool. Для этого читаем внимательно http://abills.net.ua/wiki/doku.php/abills:docs:modules:dv:ru и находим параметр IP Pool.
Внимание! Для контроля IP-адресов необходимо создавать эти пулы и на сервере доступа (NAS). Так советует Abills. Но врет. Убиваю пулы на Cisco и адреса спокойно выдаются. Завожу пулы на Cisco, отслеживаю использование пула и ничего не показывает - статистики по использованию пула нет. Так что создание пулов на Cisco можно смело пропустить.В качестве NAS у нас ;) используется Cisco 2821. Создаем пулы IP-адресов:
ena
conf t
ip local pool NAT-VPN-Pool 192.168.250.1 192.168.250.251
ip local pool NONAT-VPN-Pool 192.168.251.1 192.168.251.251
exit
wr memДалее в Abills идем в Система -> Сервер доступа -> IP POOLs и создаем пулы:
Переходим в Система -> Интернет -> Тарифные планы и привязываем наш пул к тарифному плану:
После применяем к пользователю тарифный план и все должно работать. Для этого переходим Клиенты -> Логины -> Информация -> Сервисы -> Internet -> Тарифные планы
Важная вещь. Например, у нас есть 3 тарифных плана 1Mbit, 3Mbit, 5Mbit. Названия говорят сами за себя. Я не придумал ничего, кроме того, чтобы пользователю применять тарифный план. Но если так, то необходимо привязать пул к тарифному плану. Для этого на 1 скорость я создаю 2 тарифных плана: 1Mbit-NAT и 1Mbit-NONAT. Названия говорят сами за себя и соответствуют нашим пулам. Несколько громоздко, но работает. И еще, Тарифные планы легко делят между собой один и тот же пул адресов.
UPD1: Все было бы хорошо, если бы не было так печально.
Вылезла одна проблема при переводе на пулы. Раньше пользователю VPN вбивался статический IP и это было нехорошо. Решили ж сразу если и приводить все в божеский вид то и адреса раздавать из пулов автоматически. Хочешь повесить разные ACL - делай пул и вешай ACL на него. И тут случилось горе. Интернет стал работать нестабильно. Причина как оказалась банальная.
Когда в Abills-е меняешь статику на динамику то по логике надо просто в свойствах пользователя затереть статический IP-адрес, что и было успешно сделано с несколькими пользователями. Проверив работоспособность такой схемы, настройки были завершены..., а с утра мы получили нестабильно работающий Интернет.
В чем была причина? Осмотр показал нормальную работу биллинга, настроек VPN-соединения, вроде маршрутизатор работал в штатном режиме. Далее причина оказалась простая: Если чистишь статический IP, как было написано выше, то ЭТОНЕПРАВИЛЬНО! После того как очищается IP и нажата кнопка "Изменить", Abills решает вбить в пустые поля значения 0.0.0.0 0.0.0.0 для адреса и маски. Выглядит это примерно так:
Внимание! Если вы переводите на динамику со статики в Abills то делайте это правильно. Для динамики прописывайте адрес 0.0.0.0, а маску 255.255.255.255. И будет счастье.Конечно, после это так и было сделано. И все начало нормально работать.
Век живи - век наступай на грабли.
Вописанном случае приходилось сбрасывать сессии, которые "подвисли" на маршрутизаторе и не были видны из интерфейса биллинга. Небольшой пример как с этим бороться.
Как сбросить сессию не с биллинга, а непосредственно с Cisco-роутера.
Смотрим идентификатор туннеля (TunID), который хотим сбросить:
PS: Есть предложения и замечания? Сообщайте.
