ISGv2 Intro: различия между версиями

Материал из noname.com.ua
Перейти к навигацииПерейти к поиску
Строка 104: Строка 104:
 
Полный список такой, однако по описаниям далеко не все понятно
 
Полный список такой, однако по описаниям далеко не все понятно
 
* access-reject Radius authentication failed - если Radius прислал Acсess-Reject
 
* access-reject Radius authentication failed - если Radius прислал Acсess-Reject
* account-logoff Upon an account logoff
+
* account-logoff Upon an account logoff - насколько я могу судить, это возможно только с CoA, если пришел внешний пакет
 
* account-logon Upon an account logon - Radius прислал Acсess-Accept
 
* account-logon Upon an account logon - Radius прислал Acсess-Accept
 
* acct-notification Upon an Accounting Notification event
 
* acct-notification Upon an Accounting Notification event
* credit-exhausted Upon the billing server returning qt=0 qv=0 it>0
+
* credit-exhausted Upon the billing server returning qt=0 qv=0 it>0
 
* dummy-event Dummy event to test suspendable actions
 
* dummy-event Dummy event to test suspendable actions
 
* flow-timeout Upon flow timeout of a service
 
* flow-timeout Upon flow timeout of a service

Версия 14:30, 9 мая 2023

Введение в ISG

  • Intelligent Services Gateway (ISG) — это набор функций программного обеспечения Cisco и есть только у Cisco, аналогичный функционал у других вендоров называется иначе.


Шлюз интеллектуальных служб (ISG) представляет собой решение для терминирования абонентов/подписчиков для гибкой настройки услуг (не очень понятное определение с сайта)

ISG занимается следующими ключевыми аспектами управления подписчиками:

  • Идентификация абонента
  • Определение службы и политики
  • Применение политики сеанса
  • Управление жизненным циклом сеанса
  • Учет доступа и использования услуг
  • Мониторинг состояния сеанса
  • CoA (Radius) для изменения состояния "не лету"


ISG 1.png

По картинке немного яснее

  • по первому пакету сходить за авторизацией, потом за политиками и сделать или доступ в интернет или редирект на портал или еще что-то по желанию
  • сервисы (набор правил для абонента) можно при желании хранить и полностью локально в конфигурации устройства

Ключевые термины которые нужно разобрать

  • Subscriber Sessions
  • Subscriber Access
  • Subscriber Identification
  • Subscriber Services
  • Policies
  • Dynamic Policy Updates

Subscriber Sessions

Сессия (иногда переводят как сеанс) ISG — это общий системный контекст, который создается для каждого подписчика, взаимодействующего с пограничным устройством.
По сути - это какой-то объект в памяти устройства который имеет собственный идентификатор и создается при первом взаимодействии абонента с шлюзом - по сути по первому пакету.
И этот программный объект содержит информацию по авторизации, службам (ограничение скорости или файрволл и прочее)

Так как мы живем в мире победившего ethernet то сессия это абстракция, в отличии от PPP где сессия изначально подразумевало наличие телефонного соединения

Subscriber Access

Пока что совершенно непонятный термин

Under ISG, the provisioning and handling of specific access media and protocols is decoupled as far as possible from the functionality that is applicable to all session types. This model has the following benefits:

* A common set of subscriber services may be used on an ISG at which heterogeneous subscriber networks are aggregated.
* A common set of subscriber services may be used for multiple ISGs, even when the access technology differs.
* For a given subscriber, the access method may be altered (through provisioning or roaming) without any need to change the service provisioning.

As new access protocols become available, they can be leveraged by existing edge deployments without requiring changes to the service content; new access protocols plug into the ISG framework.

Subscriber Identification

По событиям (первый пакет как самый частый пример) - сходить с запросом с тем что есть на RADIUS
А есть обычно IP адрес и МАК опционально

Пишут что стартом сессии может быть и DHCP

Для IP-сеанса, когда начало сеанса сигнализируется событием протокола DHCP, может быть активирована политика перенаправления TCP. Эта политика облегчит сбор имени пользователя и учетных данных на внешнем веб-портале.

Subscriber Services

Сервис (или услуга) - это набор политик которые применяются к абонентской сессии
Сервис сожет быть активирован в 3 случаях

  • As a result of control policy execution - самый интересный и важный, подводит к понятию control policy
  • By receipt of a CoA service-logon command - понятно что по CoA пакету можно что-то триггернуть
  • By reference in a user profile, where the service is flagged for automatic activation - что написано понятно, как это написать в конфиге - пока нет

Policies

ISG introduces support for two basic policy types:

  • Traffic policies
  • Control policies

Traffic policies

Traffic policy определяют обработку пакетов данных и состоят из

  • traffic class который определяет критерии на основе пакетов для которых применима политика, и
  • одного или нескольких traffic actions, которые являются функциональными экземплярами, которые выполняют определенные операции с потоком данных и часто называют функциями.

Действия над трафиком, настроенные в политике трафика, вызываются для пакетов данных, которые соответствуют критериям, определенным классом трафика.
Тут пример не помешает (TODO)

Network-forwarding policies — это особый тип traffic policy, для которого действие представляет собой действие пересылки по сети,
например маршрутизация пакетов с использованием определенного VRF или пересылка пакетов через L2.

Network-forwarding policies являются «бесклассовыми» в том смысле, что невозможно уточнить критерии, для которых применимо действие переадресации.

Control policies

Control policies определяют обработку системных событий (handling) и состоят из одного или нескольких

  • control policy rules (правил политики управления)
  • decision strategy ( и стратегии принятия решений)

decision strategy определяет, как оцениваются составляющие правила политики.

Правило политики управления состоит из класса управления (предложения с гибким условием), события, для которого оценивается условие, и одного или нескольких управляющих действий. Управляющие действия — это общие системные функции, такие как «аутентификация» или «активация службы».

Dynamic Policy Updates

События

Полный список такой, однако по описаниям далеко не все понятно

  • access-reject Radius authentication failed - если Radius прислал Acсess-Reject
  • account-logoff Upon an account logoff - насколько я могу судить, это возможно только с CoA, если пришел внешний пакет
  • account-logon Upon an account logon - Radius прислал Acсess-Accept
  • acct-notification Upon an Accounting Notification event
  • credit-exhausted Upon the billing server returning qt=0 qv=0 it>0
  • dummy-event Dummy event to test suspendable actions
  • flow-timeout Upon flow timeout of a service
  • quota-depleted Upon the depletion of allocated quota
  • radius-timeout RADIUS server timed out during authentication - Radius не ответил за определнный тайм-аут
  • service-failed Upon failure of a service
  • service-start Upon a request to start a service
  • service-stop Upon a request to stop a service
  • session-default-service Upon providing default service
  • session-restart Upon a session being restarted
  • session-service-found Upon network plumbing service determined
  • session-start Upon a session being created
  • timed-policy-expiry Upon a timed policy expiry - Событие возникает когда на сессии был установлен таймер и он истек



timed-policy-expiry

Событие возникает когда на сессии был установлен таймер и он истек, например

class-map type control match-all ISG-IP-UNAUTH
 match authen-status unauthenticated
 match timer UNAUTH-TIMER



policy-map type control ISG-CUSTOMERS-POLICY
 class type control ISG-IP-UNAUTH event timed-policy-expiry
  1 service disconnect
 !
...
 class type control always event radius-timeout
  20 set-timer UNAUTH-TIMER 60
  30 service-policy type service name POLICY_MAP_SERVICE_ON_SESSION_RADIUS_TIMEOUT_

В этом случае (если радиус не работает) произойдет событие radius-timeout,

session-start

policy-map type control IPOE_CUSTOMERS
 class type control COND_LAST event timed-policy-expiry
  10 service disconnect
 !
 class type control always event session-start
  10 authorize aaa list ISG_AUTH_LIST password radiuspassword identifier source-ip-address 
  20 set-timer 2MIN 2
...

Или

policy-map type control ISG-CUSTOMERS-POLICY
 class type control ISG-IP-UNAUTH event timed-policy-expiry
  1 service disconnect
 !
 class type control always event session-start
  10 authorize aaa list AAA-LIST-ISG-AUTH password secret identifier source-ip-address
  20 set-timer UNAUTH-TIMER 5
  30 service-policy type service name POLICY_MAP_SERVICE_ON_SESSION_START_
Политика IPOE_CUSTOMERS управляет всем циклом жизни сесcии. 
И является ключевым элементом, который описывает что, когда и как делать с абонентской сессией. 
В приведенном ниже примере она достаточна проста. 
По событию session-start на биллинг( метод ISG_AUTH_LIST) пошлется access-request ,
где в качестве username будет указан ip адрес клиента.Если авторизация не удастся, тогда на сессию повесится 2х-минутный таймер и она завершится по его истечению(event timed-policy-expiry).

Обращаю внимание ,что во всех мануалах рекомендуется на данном этапе (event session-start) третьим и четвертым действием разрешить клиенту 
временный доступ к ресурсам в OPENGARDEN и заблокировать/заредиректить все остальное. 

А при событии account-logon(по приходу access-accept от биллинга) снять эти сервисы. В виду того,что фантазия системного администратора безгранична, 
предлагается самостоятельно под себя настроить сценарий того что надо делать с клиентом в эти две минуты. 
Как правило до этого шага могут дойти абоненты если лег радиус и от него нет ответов. В приведенном примере если абонента не 
удается авторизовать он все равно будет иметь доступ в интернет(пока Вы чините radius).
И в большинстве случаев это будут вполне легитимные клиенты , если на доступе настроен dhcp snooping/ip source guard и прочие фичи.


session-restart

service-stop

radius-timeout

access-reject

account-logon

ccount-logon(по приходу access-accept от биллинга)

Ссылки