[vanishox]

Парни, добрый день.

 

Подскажите по следующей ситуации:

 

1. Для стенда использую Сisco 7206 с "Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 12.2(33)SRD4, RELEASE SOFTWARE (fc2)".

2. Необходимо авторизовывать пользователей IPoE на транзитном маршрутизаторе (не на том, к которому подключен пользователь).

3. Используя для этого ISG, столкнулся со следующей проблемой:

- при приходе любого пакета по направлению: "От клиента в интернет" пользователь авторизуется нормально, сессия устанавливается, трафик ходит нормально.

- при приходе любого пакета по направлению: "Из интернета к пользователю" сессия не поднимается.

 

4. В доках нашел, что должно все работать:

 

Routed IP Subscriber Identity

By definition, subscriber IP addresses are at least routable in the access network. If the access network is a routed network, subscriber IP addresses can be used to uniquely identify IP subscribers.

When using a subscriber IP address as the identifier, ISG assumes that the subscriber IP address is unique. If the access network is deployed with Layer 3 load balancing, redundancy, or asymmetric routing, ISG also assumes that IP traffic from the same IP subscriber may arrive at different access interfaces. To support this type of deployment, ISG assumes a single IP address space for all access interfaces connecting to the same access network.

If there is a requirement to support several IP address spaces over a single physical access network, the access network must use some Layer 2 encapsulation to create a separate logical access network for each IP address space. In this case, ISG can still have a single IP address space for all the logical access interfaces that connect to a logical access network.

When subscriber IP addresses are private IP addresses, the access network must be able to route such subscriber traffic. If the subscriber traffic is destined for the Internet, NAT must be performed.

For routed IP subscribers, the subscriber IP address serves as the key for an IP session. ISG associates IP traffic with an IP session as follows:

   In the upstream direction, the source IP address of an IP packet is used to identify the IP session. The source IP address is the subscriber IP address.

   In the downstream direction, the destination IP address of an IP packet is used to identify the IP session. The destination IP address is the subscriber IP address.

If the IP subscriber is a VPN user, the subscriber IP address must be routable in both the global routing table and the VPN routing table on ISG.

For an IP subnet subscriber, a subscriber IP address is defined as an IP prefix address instead of a /32 IP host address. This IP prefix covers a range of IP addresses used by end users but represents a single logical IP subscriber for ISG. In this deployment, all end users share the same connectivity and services provided by ISG. 

 

5. Собственно вопросы:

- Кто-нибудь поднимал такую штуку?

- Оно действительно работает так как описано в доках?

- На каком железе и IOS поднемали ее? (Может я столкнулся с ограничением в IOS)

[vanishox]

Да ладно!

 

Загнал тест на ASR-1002 c IOS = "asr1000rp1-advipservicesk9.03.10.06.S.153-3.S6-ext.bin"

 

Та же самая ситуация - при исходящем траффике от клиента сессия стартует, при входящем к клиенту - НЕТ.

 

Хммм, получается что фича в доке по ссылке (описывающей инициализацию сессии):

 

 For routed IP subscribers, the subscriber IP address serves as the key for an IP session. ISG associates IP traffic with an IP session as follows:

   In the upstream direction, the source IP address of an IP packet is used to identify the IP session. The source IP address is the subscriber IP address.

   In the downstream direction, the destination IP address of an IP packet is used to identify the IP session. The destination IP address is the subscriber IP address. 

 

Не работает! :(

 

У кого-нибудь есть поддержка в TAC asr1002? :)

[buckethead]

Мне кажется здесь написано просто про то, каким образом ISG отделяет сессии между собой, а не о старте как таковом.

[vanishox]

Хммм, в таком контексте я даже и не рассматривал описание в доке.

Вполне возможно, что выдал желаемое за действительное.

 

Предистория:

 

- Есть часть клиентов, у которых есть услуга выделенного доступа в интернет - выдается VLAN с белым IP адресом (или подсетью).

- Нужно подвязать к биллингу пропуск IP траффика к клиенту и от клиента по наличии галки в статусе счета - "в работе" или "отключен"

 

Меня смущает следующее - если у клиента кончилась (или оборвалась) сессия, то новая стартует только при наличии какого-либо таффика от него.

 

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

 

Соответственно может возникнуть ситуация типа "deadlock" - сессия обрывается, оборудование траффик не генирирует, доступа "извне" к оборудованию нет пока не стартует сессия.

 

Кто-нибудь в таком режиме IPoE+ISG использовал?

[ShyLion]

Соответственно может возникнуть ситуация типа "deadlock" - сессия обрывается, оборудование траффик не генирирует, доступа "извне" к оборудованию нет пока не стартует сессия.

 

Кто-нибудь в таком режиме IPoE+ISG использовал?

Таких абонентов 1 на миллион. Такому и вручную кислород перекрывать можно.

Обычно NTP траффик есть всегда, всякие Windows Update и прочие Google Play постоянно генерят траффик наружу, DNS запросы и т.д.

[zhenya`]

если схема л3 коннектед, можно до л3 ядра кинуть доп влан без политики и туда pbrом перекидывать tcp syn пакеты из интернета в сторону абонентов, которым надо поднимать сессию при трафике из интернета.

 

для всех это жуть. постоянно идет брут по ssh / telnet

[Wingman]

Соответственно может возникнуть ситуация типа "deadlock" - сессия обрывается, оборудование траффик не генирирует, доступа "извне" к оборудованию нет пока не стартует сессия.

 

Кто-нибудь в таком режиме IPoE+ISG использовал?

Таких абонентов 1 на миллион. Такому и вручную кислород перекрывать можно.

Обычно NTP траффик есть всегда, всякие Windows Update и прочие Google Play постоянно генерят траффик наружу, DNS запросы и т.д.

Таких клиентов дохерища и больше, особенно среди юриков.

 

На asr1k мы это решили статик листами:

 

interface TenGigabitEthernet0/2/0.999
....
ip subscriber routed
 initiator unclassified ip-address
 initiator static ip subscriber list ur
end

 

Сам лист:

ip subscriber list ur
 ip source x.x.x.x
 ip source y.y.y.y

Возможно, можно и масками задавать.

 

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

[ShyLion]

Спасибо, учтем что так можно.

[vanishox]

2Wingman Спасибо за подсказку - попробую.

[vanishox]

2Wingman проверил, все завелось. Спасибо еще раз.

1. ip static session + ip subscriber list действительно работают.

2. ip subscriber list поддерживают не только точечные ip, но и подсети с масками вида:

ip subscriber list leased_lines
 ip source 10.10.64.12 mask 255.255.255.252

3. По ходу теста возник еще вопрос - с интернета сыпется левый траффик на сети клиентов, который пытается авторизоваться в радиусе:

rad_recv: Access-Request packet from host 10.10.10.10 port 1645, id=168, length=168
User-Name = "121.239.122.142"
User-Password = "test_pass"
Framed-IP-Address = 121.239.122.142
Cisco-Account-Info = "S121.239.122.142"
NAS-Port-Type = Virtual
NAS-Port = 0
NAS-Port-Id = "15/0/1/78"
Service-Type = Outbound-User
NAS-IP-Address = 10.10.10.10
Acct-Session-Id = "53A742EA0029D3F4"
NAS-Identifier = "ASR-1002-ISG"
Event-Timestamp = "Oct  5 2016 13:12:44 MSK"

 

Можно ли такой траффик как-то фильтровать на ASR-ке, чтобы радиус и базу не вешать левыми запросами?

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

[zhenya`]

Сессия только изнутри может создаться.. может спуфинг?

[vanishox]

Не похоже на спуфинг.

Когда я пытаюсь со своих серверов пропингать хосты с клиентской подсети, в радиус также приходят попытки авторизации с ip адресами моих серваков.

[vanishox]

zhenya`

 

Вы были правы. Нужная сессия стартует только с тем IP адресом (подсетью), которая прописана в ip subscriber list.

 

Мой предидущий невнятный пост с левой авторизацией связан с тем, что я попутал конфиги цисок - с7206 (на которой изначально делал тесты) и asr-1002 (на котором в итоге начал все поднимать).

 

Путаница возникла на asr-1002 в следующем конфиге:

 

interface Port-channel1.78
description TEST-VKI-ISG
encapsulation dot1Q 78
ip address 10.10.10.10 255.255.255.252
service-policy type control vki_control
ip subscriber routed
 initiator unclassified ip-address                        <--------- вот тут ошибка (получаетя инициируется сессия по транзитному ip-srs-address)
 initiator static ip subscriber list vki

 

Получилось смешно:

- я тестировал на asr-1002, а изменения (no initiator unclassified ip-address) сделал на с7206 по запарке попутав вкладки терминала (хостнеймы стояли одинаковые на узлах).

- и получилась ситуация когда asr-1002 авторизует пользователей и по ip subscriber list и по неклассифицированным ip-src-address, проходящих через интерфейс Po1.78

 

Исправил уже давно, а сегодня решил отписать сюда, дабы не смущать тех, кто будет поднимать ISG у себя и читать эту тему. :)

 

Рабочий конфиг интерфейса:

interface Port-channel1.78
description TEST-VKI-ISG
encapsulation dot1Q 78
ip address 10.10.10.10 255.255.255.252
service-policy type control vki_control
ip subscriber routed
 initiator static ip subscriber list vki

Изменено 24 октября, 2016 пользователем vanishox