ISGv2 Intro: различия между версиями
Sirmax (обсуждение | вклад) |
Sirmax (обсуждение | вклад) |
||
Строка 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) для изменения состояния "не лету"
По картинке немного яснее
- по первому пакету сходить за авторизацией, потом за политиками и сделать или доступ в интернет или редирект на портал или еще что-то по желанию
- сервисы (набор правил для абонента) можно при желании хранить и полностью локально в конфигурации устройства
Ключевые термины которые нужно разобрать
- 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 от биллинга)