vanishox

Пользователи
  • Публикаций

    50
  • Зарегистрирован

  • Посещение

Информация о vanishox

  • Звание
    Абитуриент
  • День рождения

Контакты

  • ICQ
    0
  1. Tau продолжи ,плиз, дальше свою мысль с разрешением пользователю доступа на captive.apple.com. (Забыл сразу сказать - регистрация на портале происходит по номеру телефона и отправки смс с кодом доступа в Инет).
  2. Ребята, добрый день. Модернизировал свой wi-fi портал регистрации пользователей hotspot в точках присутствия наших wi-fi зон, чтобы он запоминал абонентов по cookie на месяц-год [100 лет :) ], все бы ничего, но столкнулся с проблемой в " яблоневке" (так я называю iOS) - у них с 9.2.1 версии при регистрации на Wi-Fi captive portal выпилена возможность хранить cookie в настройках их урезанного - "pop-up window browser" как они его называют. Таким образом их браузер не запоминает куки от портала, а портал не может запомнить его. Кто-нибудь сумел победить такую штуку?
  3. 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
  4. Не похоже на спуфинг. Когда я пытаюсь со своих серверов пропингать хосты с клиентской подсети, в радиус также приходят попытки авторизации с ip адресами моих серваков.
  5. 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-ка.
  6. Хммм, в таком контексте я даже и не рассматривал описание в доке. Вполне возможно, что выдал желаемое за действительное. Предистория: - Есть часть клиентов, у которых есть услуга выделенного доступа в интернет - выдается VLAN с белым IP адресом (или подсетью). - Нужно подвязать к биллингу пропуск IP траффика к клиенту и от клиента по наличии галки в статусе счета - "в работе" или "отключен" Меня смущает следующее - если у клиента кончилась (или оборвалась) сессия, то новая стартует только при наличии какого-либо таффика от него. Но бывает случаи, когда белые адреса используются клиентами для всяких серверов, терминалов, банкоматов, камер и прочего оборудования, которое может не генерировать траффик, пока к нему не придет запрос. Соответственно может возникнуть ситуация типа "deadlock" - сессия обрывается, оборудование траффик не генирирует, доступа "извне" к оборудованию нет пока не стартует сессия. Кто-нибудь в таком режиме IPoE+ISG использовал?
  7. Да ладно! Загнал тест на 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? :)
  8. Парни, добрый день. Подскажите по следующей ситуации: 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)
  9. Всем привет. Ребят, подскажите пожалуйста по следующим вопросам: Вопрос 1: 1.1 Есть ASR-1002 с Cisco IOS Software, ASR1000 Software (PPC_LINUX_IOSD-ADVIPSERVICESK9-M), Version 15.3(3)S6, RELEASE SOFTWARE (fc5) 1.2 На нем поднят сабинтерфейс L3 в сторону пользователя с серым адресом вида: interface Port-channel1.3806 description сlient_1 encapsulation dot1Q 3801 ip address 192.168.1.1 255.255.255.0 ip nat inside ip flow ingress service-policy type control client-control ip subscriber l2-connected initiator unclassified mac-address 1.3 По контрольной политике происходит аутентификация и авторизация сервисов по сессии (выдача на сессию ограничений по скорости) 1.4 Пользователь ходит в инет через PAT. Вопрос - как на сабинтерфейсе ограничить суммарную скорость для всех пользователей? Например - на сессию для каждого пользователся выдается полисер = 1 Мбит, нужно ограничить всю скорость на сабинтерфейс = 30 Мбит. Вопрос 2: 2.1 Есть тестовая 7206VXR с Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 12.2(33)SRD4 2.2 Поднимаю на ней L2TP 2.3 При подключении пользователя с лимитным тарифом - ему отдается сервис с препйэд конфигом TRAFFIC_PREPAID,он выглядит так: subscriber feature prepaid TRAFFIC_PREPAID threshold time 60 seconds threshold volume 1 Mbytes interim-interval 1 minutes method-list author ISG_authz method-list accounting ISG_accnt password superpassword 2.4 По этому конфигу препэйд-сервер отдает квоту - например QV100000000 2.5 Сервис с квотой подтягиваются - квота расходуется все ок. 2.6 При окончании квоты срабатывает перезапрос квоты и выдается например QV0 - кончился траффик. 2.7 Я хотел при помощи контрольной политики вида: policy-map type control TEST class type control always event quota-depleted 1 set-param drop-traffic FALSE ! class type control always event credit-exhausted 1 service-policy type service name REDIRECT_PORTAL ! прописанной на virtual-template для L2TP: interface Virtual-Template1 ip unnumbered Loopback0 no ip redirects no ip proxy-arp ip tcp adjust-mss 1420 peer default ip address pool VPDN no snmp trap link-status keepalive 10 2 ppp authentication chap ms-chap ms-chap-v2 ISG_L2TP_AUTH ppp authorization ISG_L2TP_ACCT ppp ipcp address required ppp timeout ncp 60 ppp timeout authentication 15 service-policy type control TEST Ловить событие credit-exhausted и подвешивать политику для редиректа на сессию. Но при таких настройках политика не подтягивается к сессии и при получении квоты = QV0 происходит просто отсоединении препэйд сервиса, а сессия продолжает работать и пускать траффик пользователя в интернет. 2.8. Пока что в качестве альтернативного варианта сделал так: - отдаю сервис с квотой с приоритетом например 10 - отдаю сервис редиректа с приоритетом например 20 - при окончании квоты - сервис с квотой просто отсоединяется и остается только сервис с редиректом, по которому весь траффик пользователя редиректится на портал Но хотел бы уточнить - можно ли (и если можно, то как?) использовать контрольную политику в моем случае.
  10. Спасибо за ответ. Я к чему спрашиваю: 1. Есть тестовая 7206VXR с Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 12.2(33)SRD4 2. Поднимаю на ней L2TP 3. При подключении пользователя с лимитным тарифом - ему отдается сервис с препйэд конфигом TRAFFIC_PREPAID,он выглядит так: subscriber feature prepaid TRAFFIC_PREPAID threshold time 60 seconds threshold volume 1 Mbytes interim-interval 1 minutes method-list author ISG_authz method-list accounting ISG_accnt password superpassword 4. По этому конфигу препэйд-сервер отдает квоту - например QV100000000 5. Сервис с квотой подтягиваются - квота расходуется все ок. 6. При окончании квоты срабатывает перезапрос квоты и выдается например QV0 - кончился траффик. 7. Я хотел при помощи контрольной политики вида: policy-map type control TEST class type control always event quota-depleted 1 set-param drop-traffic FALSE ! class type control always event credit-exhausted 1 service-policy type service name REDIRECT_PORTAL ! прописанной на virtual-template для L2TP: interface Virtual-Template1 ip unnumbered Loopback0 no ip redirects no ip proxy-arp ip tcp adjust-mss 1420 peer default ip address pool VPDN no snmp trap link-status keepalive 10 2 ppp authentication chap ms-chap ms-chap-v2 ISG_L2TP_AUTH ppp authorization ISG_L2TP_ACCT ppp ipcp address required ppp timeout ncp 60 ppp timeout authentication 15 service-policy type control TEST Ловить событие credit-exhausted и подвешивать политику для редиректа на сессию. Но при таких настройках политика не подтягивается к сессии и при получении квоты = QV0 происходит просто отсоединении препэйд сервиса, а сессия продолжает работать и пускать траффик пользователя в интернет. 8. В качестве альтернативного варианта сделал так: - отдаю сервис с квотой с приоритетом например 10 - отдаю сервис редиректа с приоритетом например 20 - при окончании квоты - сервис с квотой просто отсоединяется и остается только сервис с редиректом, по которому весь траффик пользователя редиректится на портал Но хотел бы уточнить - можно ли (и если можно, то как?) использовать контрольную политику в моем случае.
  11. Возник такой вопрос - применяется ли контрольная политика на PPP интерфейсе (описанная в virtual-template) при старте сессии и отдачи сервисов из радиуса? В контрольной политике старт сессии никак не описывается - сессия стартует не из нее.
  12. Возник такой вопрос - применяется ли контрольная политика на PPP интерфейсе (описанная в virtual-template) при старте сессии и отдачи сервисов из радиуса? В контрольной политике старт сессии никак не описывается - сессия стартует не из нее.
  13. Возник такой вопрос - применяется ли контрольная политика на PPP интерфейсе (описанная в virtual-template) при старте сессии и отдачи сервисов из радиуса? В контрольной политике старт сессии никак не описывается - сессия стартует не из нее.