Cisco ISG (L2tp+ip:addr-pool) problem

[vanishox]

Добрый день.

Ребят, подскажите, кто сталкивался с такой штукой.

 

На asr1002 поднимаю L2TP + ISG + radius.

 

Возникла необходимость - пользователям прошедшим аутентификацию выдавать белые адреса и вешать полисер, тем кто не прошел - выдавать серые адреса и вешать редирект.

 

Само соединение L2TP устанавливается, нужные сервисы скачиваются и применяются, но возник затык с разделением адресов.

Полазив на форумах - я нашел, что такие задачи решали через - CiscoAVPair: ip:addr-pool=poolXXX

 

Попробовал внедрить такую штуку у себя:

 

ip local pool VPDN  172.16.0.1 172.16.0.10
ip local pool pool1 10.10.10.1 10.10.10.10


interface Virtual-Template1
ip unnumbered Loopback2
no ip redirects
no ip proxy-arp
ip tcp adjust-mss 1420
peer default ip address pool pool1                # - по дефолту оставляю юзеров в одном из пулов
no snmp trap link-status
keepalive 30 3
ppp authentication chap ms-chap pap ISG_L2TP_AUTH # - аутентификация
ppp authorization IPoE                            # - авторизация
ppp ipcp address required
ppp ipcp no-renegotiation
ppp timeout ncp 60
ppp timeout authentication 15

 

В радиусе отдаю пул в одном из подвешиваемых сервисов:

Sending Access-Accept of id 21 to 10.10.66.136 port 1645
Cisco-AVPair = "ip:l4redirect=redirect  to group PORTAL"
Cisco-AVPair += "ip:traffic-class=input access-group name REDIR-TRAFF"
Cisco-AVPair += "ip:traffic-class=output access-group name REDIR-TRAFF"
Cisco-AVPair += "ip:addr-pool=VPDN"
Framed-Protocol = PPP
Service-Type = Framed-User

 

В деталях сессии вижу, что "вроде бы" сервис применился к сессии:

 

Interface: Virtual-Access2.2

Policy information:
 Context 3E81A3EC: Handle 3E00033E
 AAA_id 0000582E: Flow_handle 0
 Authentication status: authen
 Downloaded User profile, excluding services:
   ssg-account-info     "AOPEN_DNS"
   ssg-account-info     "AL4REDIRECT_SERVICE"
 Downloaded User profile, including services:
   ssg-account-info     "AOPEN_DNS"
   ssg-account-info     "AL4REDIRECT_SERVICE"
   l4redirect           "redirect  to group PORTAL"
   addr-pool            "VPDN"
   Framed-Protocol      1 [PPP]
   service-type         2 [Framed]
   traffic-class        "input access-group name open_servers_in"
   traffic-class        "output access-group name open_servers_out"
 Config history for session (recent to oldest):
   Access-type: Web-service-logon Client: SM
    Policy event: Apply Config Success (Service)
     Profile name: OPEN_DNS, 5 references 
       traffic-class        "input access-group name open_servers_in"
       traffic-class        "output access-group name open_servers_out"
   Access-type: Web-service-logon Client: SM
    Policy event: Apply Config Success (Service)
     Profile name: L4REDIRECT_SERVICE, 5 references 
       l4redirect           "redirect  to group PORTAL"
       traffic-class        "input access-group name REDIR-TRAFF"
       traffic-class        "output access-group name REDIR-TRAFF"
       addr-pool            "VPDN"
       Framed-Protocol      1 [PPP]
       service-type         2 [Framed]
   Access-type: PPP Client: SM
    Policy event: Process Config Connecting
     Profile name: apply-config-only, 2 references 
       ssg-account-info     "AOPEN_DNS"
       ssg-account-info     "AL4REDIRECT_SERVICE"
 Active services associated with session:
   name "OPEN_DNS"
   name "L4REDIRECT_SERVICE"

Session inbound features:
Traffic classes:
 Traffic class session ID: 144
  ACL Name: REDIR-TRAFF, Packets = 30, Bytes = 3620
 Traffic class session ID: 939
  ACL Name: open_servers_in, Packets = 0, Bytes = 0
Unmatched Packets = 0, Re-classified packets (redirected) = 0

Feature: Layer 4 Redirect
 Rule table is empty
Session outbound features:
Traffic classes:
 Traffic class session ID: 144
  ACL Name: REDIR-TRAFF, Packets = 16, Bytes = 896
 Traffic class session ID: 939
  ACL Name: open_servers_out, Packets = 0, Bytes = 0
Unmatched Packets = 0, Re-classified packets (redirected) = 0

Configuration sources associated with this session:
Service: OPEN_DNS, Active Time = 00:02:35
Service: L4REDIRECT_SERVICE, Active Time = 00:02:35
Interface: Virtual-Template1, Active Time = 00:02:35

 

Но при этом адрес получаю все равно из pool1:

 

C        10.10.10.7/32 is directly connected, Virtual-Access2.2

 

Версия IOS - asr1000rp1-advipservicesk9.02.06.00.122-33.XNF.bin

 

Не пойму в чем может быть затык. Если кто сталкивался, подскажите плиз.

Edited May 13, 2015 by vanishox

[furai]

Возможно эта штука не работает на сервисе. Вы уверены что вешать нужно не на юзера, а на сервис? Если взять к примеру Framed-ip-address - этот атрибут выдается юзеру и я не вижу никаких причин выдавать его на сервис.

Debug subscriber error, debug raduis не ругаются?

Еще у вас древний софт, в котором эта фишка может вообще никак не работать. TAC сейчас рекомендует 3.10.5.

Кстати некоторые (если не все) радиусы (напр. freeradius) поддерживают внутренние пулы адресов, так можно получить некоторый workaround, если ваш вариант не заработает.

[vanishox]

furai, спасибо за ответ. Похоже, что вы правы:

 

Нашел в cisco doc - http://www.cisco.com/en/US/docs/ios-xml/ios/isg/configuration/15-1s/isg-acess-ppp-sess.html#GUID-80FF20A1-F218-4334-BE41-986323D2DFA3

 

For locally terminated PPP sessions, ISG supports the following methods of IP address assignment:

IP address in a user profile
IP subnet in a user profile
Named address pool in a user profile
Local address pools
Standard methods of IP address management for PPP

 

Там же отдельно описывается случай со сменой IP адресов при переходе из одного vrf в другой vrf - но, как я понял, там сервис подвешивается на уже установленную сессию, а не на стартующую.

 

Буду крутить выдачу аттрибутов в user profile.

 

По поводу

Кстати некоторые (если не все) радиусы (напр. freeradius) поддерживают внутренние пулы адресов, так можно получить некоторый workaround, если ваш вариант не заработает.

есть примеры, где почитать?

[YuryD]

furai, спасибо за ответ. Похоже, что вы правы:

 

Буду крутить выдачу аттрибутов в user profile.

 

Это довольно таки странно, но работало. У меня utm-радиус, поэтому isg там невозможен, невозможно передать атрибуты с одинаквовым именем и разными значениями - они затирают предыдущие. Cisco-av-pair прописаны в сервисных связках тарифного плана для рейтлимит. Но никто мне не помешает добавить юзеру другие атрибуты шейпера индивидуально.

IP задаётся радиусом, но давным давно, после объединения нескольких контор мне удалось на 2511 выдавать пользователям либо IP, либо разные имена пулов... Это конечно не isg... Но в словарях радиуса Framed-Ip-address и Ip-pool это немного разные вещи, int32 и строка. За давностию лет настройки биллинга вместе с диалапом утеряны, но это точно работало...

[vanishox]

Проверил на стенде:

- действительно через service profile пул не вешается при старте сессии.

- пул вешается адекватно через user profile с аттрибутом "Cisco-AVPair = ip:addr-pool=pool1"

Edited May 13, 2015 by vanishox

[YuryD]

Немного не понимаю идеи с ip-pool. Кроме кажущегося упрощения ситуации возникают куча граблей, от размера пула, до выборки данных по клиенту по разным запросам... А загнать пользователя по деньгам в редирект можно и по иному, но проще оставить доступ в ЛК, всё остальное заблочить. Кстати и хромовский протокол перестанет работать :) Тот который udp/80/443

[furai]

YuryD, насколько я понимаю, ТС выдает заблоченным абонам айпишники из серого пула для экономии белых адресов. Вполне нормальное решение.

 

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

[YuryD]

YuryD, насколько я понимаю, ТС выдает заблоченным абонам айпишники из серого пула для экономии белых адресов. Вполне нормальное решение.

 

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

[zhenya`]

Ну никто не мешает давать строчку с пулом, если в билинге не прописан адрес, и если прописан через фрамед айпи.

Edited May 14, 2015 by zhenya`

[vanishox]

furai, zhenya - парни, вы читаете мои мысли!? :)

 

А вообще, идея состоит в том, чтобы пользователям L2TP при отрицательном балансе или при неправильном пароле - выдавать серый адрес с сервисом редиректа, и никуда не выпускать кроме кошелька (ну и может быть пары банковских сайтов для пополнения оплаты).

 

Также это позволит снизить нагрузку на биллинг и железо, когда у пользователей кончается тариф их роутер начинает с постоянным периодом долбать ASR и Billing в пустую.

 

Когда таких пользователей немного - еще можно жить, но когда их несколько тысяч...

[ShyLion]

Если у абонента при положительном балансе должен быть реальный IP, то какой смысл выдавать ему серый? Все равно за ним должно быть резервирование на случай внезапной проплаты. Исходя из этого достаточно просто редирект навешивать когда денег нет. Тем более, что обычно нужен доступ к банковским системам для оплаты онлайн, которые добавляются в исключения из редиректа.

Емкость реального пула должна соответствовать количеству заключенных договоров а не количеству активных абонентов, иначе можно словить проблемы на ровном месте.

ИМХО

 

NATилка у тебя на другом роутере?

Edited May 15, 2015 by ShyLion