Cisco+PPPoE (Заглушка, кто как делал?)
Cisco+PPPoE (Заглушка, кто как делал?)
Коллеги так сказать, приветствую!
Кто как делал заглушку для абонентов у которых отрицательный баланс?
Встает задача, пока ISG не допилен до конца у нетапа, сделать заглушку о том, что денег на счете нет иди положи.
В радиусе есть строчка, авторизовывать даже при отрицательном балансе. Главное, чтобы юзверя редиректило на страницу, что у него баланс в минусе.
Кто как сделал на Cisco?
Есть Идея выдавать пул при отрицательном балансе, другой и этот пул весь заворачивать на заглушку. Может у кого по-другому?
Кто как делал заглушку для абонентов у которых отрицательный баланс?
Встает задача, пока ISG не допилен до конца у нетапа, сделать заглушку о том, что денег на счете нет иди положи.
В радиусе есть строчка, авторизовывать даже при отрицательном балансе. Главное, чтобы юзверя редиректило на страницу, что у него баланс в минусе.
Кто как сделал на Cisco?
Есть Идея выдавать пул при отрицательном балансе, другой и этот пул весь заворачивать на заглушку. Может у кого по-другому?
Re: Cisco+PPPoE (Заглушка, кто как делал?)
так и делаем)TiRider писал(а): Есть Идея выдавать пул при отрицательном балансе, другой и этот пул весь заворачивать на заглушку. Может у кого по-другому?
Re: Cisco+PPPoE (Заглушка, кто как делал?)
Cian, TiRider, а на какой версии UTM5 Вы это делаете, 5.3-002 или 5.3-003?Cian писал(а):так и делаем)TiRider писал(а): Есть Идея выдавать пул при отрицательном балансе, другой и этот пул весь заворачивать на заглушку. Может у кого по-другому?
Если на 003, то понятно -- этот функционал заявлен. Но 003 пока в RC статусе, не хочется на боевой сервер ставить.
Если на 002, то каким образом Вы это делаете?
Штатный utm5_radius в 5.3-002 вроде как не позволяет гибко манипулировать RADIUS-атрибутами.
Re: Cisco+PPPoE (Заглушка, кто как делал?)
гибко не позволяет, ноLovingFox писал(а): Если на 002, то каким образом Вы это делаете?
Штатный utm5_radius в 5.3-002 вроде как не позволяет гибко манипулировать RADIUS-атрибутами.
из документации 5.3-002 стр.172
Код: Выделить всё
blocked_pool_name
Имя IP-пула, адреса из которого выдаются заблокированным пользователям для ограниченного доступа
-
- Сообщения: 73
- Зарегистрирован: Чт фев 02, 2012 16:10
- Откуда: Александров
- Контактная информация:
Re: Cisco+PPPoE (Заглушка, кто как делал?)
Вот на 5.3-002 так и делал.Правда,не с цыской,а с Ericsson SE-100.Работало,но криво.Точнее,профиль редиректа на страницу "Дай денег!" не навешивался.Если на 002, то каким образом Вы это делаете?
Штатный utm5_radius в 5.3-002 вроде как не позволяет гибко манипулировать RADIUS-атрибутами.
гибко не позволяет, но
из документации 5.3-002 стр.172
этот функционал доступен с UTM 5.2.1-009Код: Выделить всё
blocked_pool_name Имя IP-пула, адреса из которого выдаются заблокированным пользователям для ограниченного доступа
А кто как делает сброс сессии ?
Т.е. при отрицательном балансе , выдается IP из пула, в котором есть доступ скажем к заглушке, ну к сайту и платежным системам.
После того как абонент сделал оплату, пока сессия не перегрузится , он так и будет висеть в этом пуле и тупить, "почему у меня инет не робит я ведь сделал оплату!" Сбрасывать сессию через rfw , больше я не вижу вариантов.?
Т.е. при отрицательном балансе , выдается IP из пула, в котором есть доступ скажем к заглушке, ну к сайту и платежным системам.
После того как абонент сделал оплату, пока сессия не перегрузится , он так и будет висеть в этом пуле и тупить, "почему у меня инет не робит я ведь сделал оплату!" Сбрасывать сессию через rfw , больше я не вижу вариантов.?
Re: Cisco+PPPoE (Заглушка, кто как делал?)
Да, так можно, конечно.mrmix25 писал(а):гибко не позволяет, ноLovingFox писал(а): Если на 002, то каким образом Вы это делаете?
Штатный utm5_radius в 5.3-002 вроде как не позволяет гибко манипулировать RADIUS-атрибутами.
из документации 5.3-002 стр.172этот функционал доступен с UTM 5.2.1-009Код: Выделить всё
blocked_pool_name Имя IP-пула, адреса из которого выдаются заблокированным пользователям для ограниченного доступа
Но для такого варианта применительно к Cisco ISG я пока не нашел другого решения, кроме как загружать дополнительный сервис REDIRECT на абонентскую сессию PPPoE всегда, даже когда абонент НЕ заблокирован. Плюс еще один сервис (OPEN_GARDEN) со списком IP-адресов, куда абоненту разрешено ходить в заблокированном состоянии.
В этих дополнительных сервисах ip_src -- это ip-пул заблокированных абонентов. Т.е. если у абонента обычный IP-адрес (он не заблокирован), то сервисы не работают, а только присутствуют на PPPoE-сессии.
Вот именно то, что лишние сервисы присутствуют (и занимают память на BRAS), но не работают, мне и не нравится...
Есть какой-нибудь более элегантный способ манипулировать сервисами заблокированных абонентов применительно к Cisco ISG, с оговоркой на ограничение utm_radius в 5.3-002?
Возможно некропост, но у меня реализована такая схема на Juniper MX в качестве браса, UTM 5.3-002, посмотрел новый функционал ISG для UTM 5.3-003 подожду пару месяцев пока заборят детские болезни и попробую переделать всю схему полностью, сейчас это набор костылей, но суть реализации такая:
1) На всех тарифах на сабскрайбер навешан фаирвол, который если IP входит в диапазон blocked_pool_name редиректит все запросы 80 и 53 портов на отдельный сервак.
Пример тарифа 50 мегабит:
2) На серваке стоит правило iptables все запросы с диапазона blocked_pool_name идущие не на этот сервак, заворачивать на его локальные сервисы
Это некрасивая реализация, но на версии 5.3-002 лучшее что смог придумать, для 5.3-003 уже прикинул схему как красиво навешивать нужные svc профили, тогда можно будет отказаться нафиг от пула blocked_pool_name разрешить авторизацию всегда и всем сразу с нормальными внешними адресами, а потом уже навешивать нужные профили, что позволит при любых изменениях не рвать абоненту сессию и делать достаточно гибкие связки.
В планах реализация фишки: оповещение абонентов за несколько дней до окончания бабла навешиванием всплывающего банера, чувак закинь бабла, а то отключим (с кнопкой ознакомлен и записью в отдельную табличку базы таких ознакомленных), но в текущей схеме с отдельным пулом и разрывом сессии получается хрень, так что буду ковырять ISG.
1) На всех тарифах на сабскрайбер навешан фаирвол, который если IP входит в диапазон blocked_pool_name редиректит все запросы 80 и 53 портов на отдельный сервак.
Пример тарифа 50 мегабит:
Код: Выделить всё
set dynamic-profiles svc-pppoe-policer-50m interfaces pp0 unit "$junos-interface-unit" family inet filter input policer-50m
set dynamic-profiles svc-pppoe-policer-50m interfaces pp0 unit "$junos-interface-unit" family inet filter output policer-50m
set firewall family inet filter policer-50m interface-specific
set firewall family inet filter policer-50m term 1 from destination-address 195.114.ХХ.ХХ/32
set firewall family inet filter policer-50m term 1 from destination-address 195.114.ХХ.ХХ1/32
set firewall family inet filter policer-50m term 1 from source-prefix-list NoMoneyHosts
set firewall family inet filter policer-50m term 1 from protocol tcp
set firewall family inet filter policer-50m term 1 from protocol udp
set firewall family inet filter policer-50m term 1 from destination-port 80
set firewall family inet filter policer-50m term 1 from destination-port 53
set firewall family inet filter policer-50m term 1 then accept
set firewall family inet filter policer-50m term 2 from source-prefix-list NoMoneyHosts
set firewall family inet filter policer-50m term 2 from protocol tcp
set firewall family inet filter policer-50m term 2 from protocol udp
set firewall family inet filter policer-50m term 2 from destination-port 80
set firewall family inet filter policer-50m term 2 from destination-port 53
set firewall family inet filter policer-50m term 2 then routing-instance neg_dep
set firewall family inet filter policer-50m term 3 from source-prefix-list NoMoneyHosts
set firewall family inet filter policer-50m term 3 then discard
set firewall family inet filter policer-50m term default then policer 50m
set firewall policer 50m if-exceeding bandwidth-limit 50m
set firewall policer 50m if-exceeding burst-size-limit 640k
set access address-assignment pool NoMoney-POOL family inet network 10.200.0.0/19
set access address-assignment pool NoMoney-POOL family inet range 1st low 10.200.0.1
set access address-assignment pool NoMoney-POOL family inet range 1st high 10.200.31.254
set access address-assignment pool NoMoney-POOL family inet xauth-attributes primary-dns 195.114.ХХ.ХХ/32
set access address-assignment pool NoMoney-POOL family inet xauth-attributes secondary-dns 195.114.ХХ.ХХ1/32
set access address-protection
set routing-instances neg_dep instance-type forwarding
set routing-instances neg_dep routing-options static route 0.0.0.0/0 next-hop 195.114.ХХ.ХХ
2) На серваке стоит правило iptables все запросы с диапазона blocked_pool_name идущие не на этот сервак, заворачивать на его локальные сервисы
Код: Выделить всё
Chain PREROUTING (policy ACCEPT 15M packets, 959M bytes)
pkts bytes target prot opt in out source destination
128K 7429K DNAT tcp -- eth0 any anywhere !195.114.ХХ.ХХ multiport dports http to:195.114.ХХ.ХХ:80
0 0 DNAT tcp -- eth0 any anywhere !195.114.ХХ.ХХ multiport dports domain to:195.114.ХХ.ХХ:53
2475 158K DNAT udp -- eth0 any anywhere !195.114.ХХ.ХХ multiport dports domain to:195.114.ХХ.ХХ:53
В планах реализация фишки: оповещение абонентов за несколько дней до окончания бабла навешиванием всплывающего банера, чувак закинь бабла, а то отключим (с кнопкой ознакомлен и записью в отдельную табличку базы таких ознакомленных), но в текущей схеме с отдельным пулом и разрывом сессии получается хрень, так что буду ковырять ISG.