Captive-портал
Принцип работы Captive-портала
Общее
Captive-портал (далее — портал) — это специальный сайт, с помощью которого можно взаимодействовать с клиентом, расширяя возможности стандартных методов аутентификации, авторизации и учета (далее — AAA) RADIUS. Портал также позволяет провести необходимые проверки, уведомить клиента и показать дополнительную информацию.
Операционная система клиентского устройства определяет наличие подключения к интернету с помощью отправки HTTP-пробы (то есть HTTP GET-запроса) на определенный адрес (в AxelNAC посмотреть список этих адресов можно на странице Конфигурация -> Расширенные настройки доступа -> Captive-портал -> URL механизма обнаружения Captive-портала). Если в ответ приходит код 200 (запрос успешно выполнен), то клиент считает, что у него есть доступ к сети. Подобный механизм используется почти на всех устройствах, которые могут работать с браузером. Если в ответ приходит код 302 или 307, то клиент понимает, что его перенаправляют, и переходит по ссылке, которая содержится в ответе. Эта ссылка ведет на портал AxelNAC, то есть на портал.
Понятие портала в AxelNAC тесно связано с понятием регистрации. Обычно логика настраивается следующим образом: только зарегистрированное устройство получает продуктивный доступ, то есть роль и, соответственно, продуктивный VLAN. В общем случае, если в профиле подключения не активирован параметр Регистрировать устройства автоматически, то клиент должен перейти на портал и выполнить там определенные действия для получения продуктивной роли и авторизации в системе.
То, каким образом происходит перенаправление пользователя, зависит от типа используемого сетевого оборудования (подробно некоторые механизмы перенаправления описываются ниже). Однако перенаправление всегда выполняется в два этапа: сначала на страницу профиля NAS, затем на портал.
В AxelNAC портал встроен в систему и расположен на узлах кластера, соответственно, поддерживается балансировка нагрузки и отказоустойчивость. Если по какой-либо причине отправка HTTP-пробы не произошла автоматически, достаточно открыть в браузере любой HTTP-ресурс.
Перенаправление HTTPS-трафика
Обращаем внимание на то, что перенаправить HTTPS-трафик в большинстве случаев невозможно из-за самой идеологии данного протокола и его дополнения HSTS (HTTP Strict Transport Security). Протокол HTTPS изначально разработан именно для того, чтобы было невозможно подменить адресата. Здесь следует учитывать следующее:
- Если пользователь заходит на HTTP-сайт, он немедленно перенаправляется на портал. Это работает независимо от используемого браузера;
- Если пользователь посещает HTTPS-сайт, не использующий HSTS, он получает предупреждение. При нажатии кнопки Продолжить он перенаправляется на портал. Это также работает независимо от браузера;
- Если пользователь посещает HTTPS-сайт, использующий HSTS, и его браузер поддерживает HSTS, то единственный способ попасть на портал — посетить другой сайт. У многих пользователей в качестве домашней страницы установлены https://www.google.com или https://www.yandex.ru. Эти сайты используют HSTS, поэтому перенаправление будет невозможно.
Механизмы перенаправления
Перенаправление на портал можно обеспечить несколькими способами. Эти способы зависят от используемого сетевого оборудования (NAS), к которому подключен клиент. Профили NAS в AxelNAC изначально разработаны для поддержки требуемого механизма перенаправления и различаются по своему поведению. Ниже указаны некоторые их варианты.
Коммутаторы Cisco
В проводных подключениях на коммутаторах Cisco и других устройствах с похожим режимом работы механизм перенаправления на портал реализуется с использованием внутреннего HTTP-сервера самого коммутатора. В этом варианте именно сетевое оборудование активно участвует в обработке первого HTTP-запроса клиента и формировании перенаправления.
После первичной RADIUS-аутентификации коммутатор получает параметры роли регистрации, включая VLAN регистрации, ACL и ссылку для перенаправления. Клиент получает ограниченный сетевой доступ, достаточный для получения IP-адреса, DNS и шлюза по DHCP. После получения IP-адреса, он отправляет HTTP-пробу на адрес в интернете.
Коммутатор использует механизм IP Device Tracking (IPDT) для сопоставления IP-адреса клиента с его портом и состоянием сессии. Получив HTTP-запрос, коммутатор направляет его на свой внутренний HTTP-сервер и возвращает клиенту ответ 302 или 307 со ссылкой на промежуточную страницу профиля данного NAS в AxelNAC. Эта страница используется для передачи параметров подключения, после чего AxelNAC перенаправляет клиента непосредственно на адрес портала. Таким образом, перенаправление всегда выполняется в два этапа: сначала на страницу профиля NAS, затем на портал.
Назначенный на этапе регистрации ACL ограничивает доступ клиента, определяет, какой трафик должен быть перенаправлен на портал, какой пропущен без перенаправления, и предотвращает цикличное перенаправление. В правилах ACL используются как разрешающие, так и запрещающие записи, где permit применяется для перенаправления, а deny — для обхода перенаправления или прямого пропуска трафика.
После успешной авторизации на портале AxelNAC пересчитывает роль клиента на продуктивную. Далее AxelNAC направляет CoA-запрос для реаутентификации клиента, после чего коммутатор отправляет новый RADIUS-запрос. AxelNAC отправляет ответ с новыми параметрами порта, такими как продуктивный VLAN и продуктивный ACL. В этом ответе ссылка на портал уже не передается, и дальнейшее перенаправление прекращается.
Для моделей NAS без поддержки CoA используются альтернативные способы изменения состояния подключения, такие как Disconnect Messages и SNMP-запрос.
При использовании механизма Disconnect Messages невозможно использовать Port Bounce. Значит, супликант клиента не получит новый новый IP-адрес по DHCP, так как не сможет понять, что его перевели в другой VLAN.
При работе портала по HTTPS в настройках должны быть указаны корректные сертификаты, а клиентское устройство должно доверять сертификату сервера, иначе доступ к порталу может быть заблокирован на уровне браузера.
Контролеры беспроводного доступа и коммутаторы HUAWEI
При использовании контроллеров беспроводного доступа и коммутаторов Huawei механизм перенаправления и последующей авторизации отличается от реализации на коммутаторах Cisco и строится вокруг портального протокола Huawei.
Адрес страницы профиля сетевого устройства указывается в настройках контроллера в явном виде, например в виде HTTP-адреса http://<IP>/Huawei::Model/. Одновременно на стороне NAS объявляются специальные параметры, которые передаются в AxelNAC при перенаправлении клиента, в виде ссылки url-parameter device-ip AC-IP device-mac AC-MAC redirect-url redirect-url ssid ssid user-ipaddress user-ipaddress. В нее входят следующие параметры: IP-адрес и MAC-адрес устройства, SSID, IP-адрес клиента и URL перенаправления. Эти параметры используются AxelNAC для идентификации конкретного устройства и текущего сеанса подключения.
При подключении клиента к публичной незащищенной SSID либо при подключении по ethernet через MAB NAS изначально открывает доступ только к порталу и перенаправляет все HTTP-запросы клиента. Первое перенаправление выполняется на страницу профиля данного NAS в AxelNAC с передачей всех необходимых параметров, после чего эта страница автоматически перенаправляет клиента на сам портал.
После авторизации клиента на портале дальнейшее взаимодействие между AxelNAC и NAS выполняется через портальный протокол Huawei. AxelNAC отправляет на контроллер специальный пакет REQ_AUTH на порт UDP 2000, уведомляя NAS об успешной авторизации клиента. В ответ NAS инициирует стандартную RADIUS-аутентификацию и направляет в AxelNAC запрос RADIUS Access-Request.К этому моменту продуктивная роль клиента уже рассчитана на портале, поэтому повторная интерактивная аутентификация не требуется, и AxelNAC отправляет ответ Access-Accept с параметрами продуктивного доступа.
Далее NAS направляет в AxelNAC пакет RADIUS Accounting-Request, на который AxelNAC отвечает Accounting-Response. После этого NAS прекращает перенаправление запросов клиента и открывает ему доступ в интернет, дополнительно отправляя в сторону AxelNAC пакет ACK_AUTH на порт UDP 2000.
В текущей версии AxelNAC используется только Portal protocol, реализация HTTP или HTTPS протокола ожидается в будущих версиях. При этом следует учитывать, что в AxelNAC портал встроен в систему, поэтому взаимодействие может отличаться от классических схем Huawei, где портал и AxelNAC рассматриваются как отдельные компоненты.
Huawei portal protocol совместим с Portal 2.0 protocol of China Mobile Communications Corporation (CMCC).
Точки доступа ELTEX
При использовании точек доступа корпоративного класса Eltex механизм перенаправления и подтверждения авторизации реализуется через собственный портальный протокол точки доступа.
Адрес страницы профиля сетевого устройства указывается в настройках точки доступа в явном виде и содержит набор обязательных параметров, включая сведения о точке доступа, клиенте, SSID, исходном URL и IP-адресе NAS. Ссылка выглядит следующим образом:
http://10.31.205.206/Eltex::AP?switch_url=<SWITCH_URL>&ap_mac=<AP_MAC>&client_mac=<CLIENT_MAC>&wlan=<SSID>&redirect_url=<ORIGINAL_URL>&nas-ip=<NAS_IP>
Эти параметры используются AxelNAC для идентификации конкретного устройства и текущего подключения.
Данный механизм применяется как для точек доступа, работающих в автономном режиме, так и для точек доступа, подключенных к контроллеру в режиме локального переключения VLAN, при котором клиентский трафик не туннелируется через контроллер.
При подключении клиента к незащищенной публичной SSID точка доступа инициирует MAB-аутентификацию и отправляет в AxelNAC RADIUS-запрос с MAC-адресом клиента. AxelNAC, применяя механизм MAC-Auth, возвращает ответ Access-Reject, который используется точкой доступа как управляющий сигнал для включения перенаправления. Одновременно клиенту присваивается роль registration.
При работе с точкой доступа ELTEX, AxelNAC возвращает ответ Access-Reject, тогда как при стандартном взаимодействии по MAB ответ будет Access-Accept.
После включения перенаправления HTTP-запросы клиента направляются на страницу профиля NAS в AxelNAC, которая автоматически перенаправляет клиента на портал.
После успешной аутентификации на портале AxelNAC вычисляет продуктивную роль и формирует HTTP-ответ с кодом 307, в котором в качестве адреса перенаправления указывается точка доступа. В параметрах передаются специальные атрибуты Eltex с результатом авторизации.
Клиент, следуя этому перенаправлению, возвращается на точку доступа и передает ей полученные параметры. Точка доступа направляет в AxelNAC второй RADIUS-запрос, используемый для проверки подлинности результата авторизации.
Получив подтверждение в виде Access-Accept, точка доступа отключает перенаправление и предоставляет клиенту доступ в интернет.
Следует учитывать, что взаимодействие точки доступа с портальным протоколом подробно описано в официальной документации Eltex. При этом необходимо помнить, что в AxelNAC портал встроен в систему, поэтому фактическое взаимодействие может отличаться от классических схем, где портал и AxelNAC рассматриваются как отдельные серверы.
DNS-Enforcement
При использовании механизма DNS-Enforcement перенаправление клиента на портал осуществляется не за счет перехвата HTTP-трафика, а за счет управления разрешением имен в DNS.
Для работы данного механизма AxelNAC должен быть настроен как первичный DNS-сервер для клиента. В этом случае все DNS-запросы клиента направляются непосредственно в AxelNAC.
Когда клиент пытается отправить HTTP-пробу на адрес в интернете, он сначала выполняет DNS-запрос для определения IP-адреса соответствующего имени хоста. AxelNAC, выступая в роли DNS-сервера, получает этот запрос и вместо реального IP-адреса возвращает в ответе собственный IP-адрес.
В результате клиент направляет HTTP-пробу не на внешний ресурс, а непосредственно на WEB-сервер AxelNAC. Получив такой запрос, WEB-сервер AxelNAC отвечает кодом 302 или 307 и перенаправляет клиента на адрес своего портала. Таким образом, механизм перенаправления реализуется полностью на уровне DNS и HTTP, без участия сетевого оборудования.
Механизм DNS-Enforcement может использоваться не только в режиме INLINE, но и в VLAN регистрации или VLAN изоляции. После первичной аутентификации по RADIUS AxelNAC предоставляет клиенту VLAN, в которой AxelNAC назначен в качестве DNS-сервера. Клиент перенаправляется на портал, проходит авторизацию, после чего с использованием механизмов CoA, DM или других методов получает новые права и переводится в продуктивную VLAN с продуктивным DNS-сервером.
Механизм DNS-Enforcement не работает в сетях с использованием NAT, поскольку в этом случае подмена DNS-ответов не позволяет корректно управлять перенаправлением клиента.
Роль Captive-портала в процессе AAA
Типовое использование портала в сценарии гостевого доступа
При подключении к открытой гостевой SSID NAS направляет MAC-адрес клиента в качестве логина и пароля в AxelNAC. AxelNAC, используя механизм MAC-Auth, в ответ отправляет RADIUS Access-Accept и устанавливает роль registration, то есть клиент остается незарегистрированным.
Обычно для роли registration в настройках профиля сетевого оборудования указываются VLAN без выхода в интернет, ACL и ссылка для перенаправления на портал. Это позволяет клиенту получить IP-адрес в изолированной сети регистрации и подключиться к порталу, используя указанную ссылку.
Попадая на портал, клиент может ввести дополнительные данные для регистрации, например адрес электронной почты, код из SMS или данные для спонсорского доступа. Дополнительно может использоваться двухфакторная аутентификация. При успешном завершении этого процесса клиент регистрируется и получает продуктивную роль, то есть такие настройки VLAN и ACL, при которых он имеет доступ к интернету и другим сетевым ресурсам без принудительного перенаправления. В настройках продуктивной роли ссылка перенаправления отсутствует.
Прочие сценарии использования портала
Описанный выше сценарий является лишь одним из вариантов использования портала. В общем случае он применяется для обогащения данных AAA клиента сверх того, что может быть получено из стандартного RADIUS-запроса, после чего принимается решение о регистрации устройства.
В сценариях проверки соответствия требованиям безопасности (posturing) портал также используется для взаимодействия с пользователем. Через портал может отображаться процесс и результат сканирования, а при определенных настройках — предлагаться варианты самостоятельного исправления выявленных несоответствий.
Также портал может быть полезен для показа пользователю любого сообщения после перевода хоста в роль изоляции. Реализуется это путем указания ACL и ссылки редиректа на портал в настройках роли изоляции. Один из вариантов, где это применимо — сценарий с подменой MAC-адреса. В целом портал с необходимой информацией можно показать пользователю не только в ролях регистрации и изоляции, а при применении любой роли, в настройках которой есть ACL и ссылка редиректа. Это позволяет реализовывать гибкое взаимодействие с пользователем в сложных сценариях.
Настройки в профиле подключения
MAC Auth переопределяет роль с портала
Если эта настройка включена, AxelNAC не будет использовать роль, рассчитанную на портале. Пример: если для данного профиля подключения не требуется получение данных с портала, например если необходимо авторизовать принтер по локальной базе данных, но злоумышленник каким-либо образом зайдет на портал и введет свои данные для получения другой роли, например для получения другого VLAN, указанная настройка не позволит этого сделать.
С другой стороны, при включенной настройке возможна ситуация, при которой пользователь никогда не получит продуктивную роль и останется в незарегистрированном состоянии. Это связано с тем, что стандартное поведение AxelNAC при MAC-аутентификации заключается в отправке Access-Accept без регистрации клиента. Данная настройка по умолчанию выключена.
Использовать учетные данные dot1x повторно
Эта настройка позволяет порталу сразу получить учетные данные пользователя из RADIUS-запроса, не запрашивая их повторно на самом портале. Пример: пользователь прошел аутентификацию dot1x по MSCHAPv2, но в текущей политике компании требуется выполнить сканирование соответствия операционной системы перед регистрацией и предоставлением продуктивной роли. В этом случае пользователя перенаправляют на портал. Чтобы не вводить логин и пароль повторно, указанная опция позволяет автоматически передать их порталу, и пользователю сразу отображается страница сканирования, при этом сканирование начинается автоматически.
Поиск и устранение неисправностей
Данный раздел описан в статье Поиск и устранение неисправностей при работе с Captive-порталом.