Как работают сетевые подключения портала?

Доступ в Интернет в гостиницах, аэропортах и ​​кафе часто закрывается специальным порталом, который при первом использовании вынуждает вас перейти на определенную веб-страницу, например на страницу оплаты или на какую-либо страницу, чтобы принять условия обслуживания или страницу аутентификации / авторизации. Это видно по беспроводным и проводным соединениям.

Как это работает?

Это, конечно, зависит от поставщика беспроводного продукта, но, по моему опыту, оно работает примерно так:

1. Ваш ноутбук устанавливает беспроводное соединение с интеллектуальной точкой доступа, которая может быть подключена к централизованной станции управления.
2. Ваш первый веб-запрос перехватывается и на него приходит Location:заголовок, который перенаправляет вас на страницу входа / политики (например, http://hotelwireless.net/login ). Это может жить непосредственно на интеллектуальной точке доступа или на центральной станции управления.
3. После того как вы завершили аутентификацию, ваш MAC-адрес добавляется в список разрешенных клиентов, в результате чего будущие запросы будут правильно перенаправляться в Интернет или на доступные ресурсы интрасети.

Что касается того, как это назвать, то я слышал, что его чаще всего называют «порталом захвата» или «порталом беспроводного доступа».

Сначала для достижения перенаправления вам необходим встроенный аутентификатор (контроллер доступа). В контексте вашей темы вам понадобится контроллер беспроводной локальной сети, если вы выбираете централизованное управление AP. ИЛИ вы также можете разместить контроллер сетевого доступа в виде невыпадающего портала с функциями Wall Garden.

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

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

Как достигается перенаправление

Наиболее широко используемый подход заключается в перехвате HTTP-запроса, инициированного пользователем, и кода 302 в качестве ответа клиенту. В чили это делается с помощью функции ниже

http_redirect2() {

cat < <  EOF
HTTP/1.1 302 Redirect 

Location: $1

Set-Cookie: PORTAL_SESSIONID=$PORTAL_SESSIONID

Set-Cookie: COOVA_USERURL=$COOVA_USERURL

Connection: close

EOF
    exit

}

Это перенаправление может быть легко достигнуто прагматически управляемым интерфейсом Tun Tap к интерфейсу на стороне клиента, который перехватывает трафик клиента. Дальнейшее перенаправление также может быть достигнуто с помощью отравления DNS, но может иногда вызывать проблемы, если ответы кэшируются в браузере клиента. Дальнейшие действия могут быть сделаны более конкретно в зависимости от предметной области. Я могу помочь вам с этим, если вы хотите.

Это прекрасное описание на https://www.arubanetworks.com/vrd/GuestAccessAppNote/wwhelp/wwhimpl/js/html/wwhelp.htm .

Вот часть этого:

Процесс аутентификации на Captive Portal

Портал Captive - это аутентификация Уровня 3, которая требует, чтобы устройства подключались к сети и получали IP-адрес и соответствующую информацию DNS перед аутентификацией через портал Captive. Следующие шаги объясняют весь процесс неавторизованного портала, когда для аутентификации неавтоматизированного портала используется нативный ArubaOS:

1. Устройству, которое связывается с гостевым SSID, назначается начальная роль (роль гостевого входа в систему в примере конфигурации). Эта начальная роль позволяет использовать DHCP, поэтому пользователь получает IP-адрес.

2. Пользователь открывает браузер и отправляет запрос HTTP (или HTTPS) в какой-либо пункт назначения (например, www.bbc.com).

3. Средство распознавания на устройстве отправляет запрос DNS для разрешения www.bbc.com. Начальная роль (роль гостевого входа в систему) разрешает службы DNS, поэтому распознаватель может взаимодействовать с сервером DNS.

4. DNS-сервер отвечает с правильным адресом www.bbc.com.

5. Средство распознавания сообщает браузеру, какой IP-адрес использовать, на основе ответа DNS.

6. Браузер инициирует TCP-соединение с портом 80 адреса www.bbc.com.

7. Контроллер перехватывает соединение и подменяет начальные TCP-рукопожатия процесса HTTP. В этот момент клиентский браузер считает, что он связывается с сервером bbc.com.

8. Когда браузер отправляет запрос HTTP GET для веб-страницы, контроллер отвечает, что bbc.com «временно перемещен» в.

9. Браузер закрывает соединение.

10. Браузер пытается подключиться, но сначала ему нужно отправить запрос DNS для адреса.

11. Фактический DNS-сервер отвечает, что он не может разрешить https://securelogin.arubanetworks.com , но контроллер перехватывает этот ответ и изменяет пакет, чтобы сказать, что securelogin.arubanetworks.com находится по IP-адресу самого контроллера. Помните, что важно, чтобы DNS-сервер отправлял ответ на запрос. Только тогда контроллер может подделать ответ от DNS-сервера. Отправка запроса DNS без получения ответа не является достаточной, поскольку без ответа контроллер никогда не поможет клиенту разрешить securelogin.arubanetworks.com.

12. Браузер инициирует HTTPS-соединение с адресом контроллера, который отвечает страницей входа в портал, где гость аутентифицируется.

13. После успешной аутентификации пользователю назначается роль пост-аутентификации (роль auth-guest в конфигурации примера). Это роль по умолчанию в профиле портала.

14. После аутентификации браузер перенаправляется на bbc.com по адресу, первоначально разрешенному DNS. Кроме того, если страница приветствия настроена, браузер перенаправляется на страницу приветствия.

15. Для успешного перенаправления на исходную веб-страницу контроллер подделывает ответ от bbc.com, чтобы сообщить клиенту, что bbc.com «окончательно переехал» на bbc.com. Этот шаг исправляет «временное перемещение», которое произошло как часть авторизованного входа на портал.

16. Это заставляет клиента повторно запросить DNS для адреса www.bbc.com.

17. Браузер начинает взаимодействовать с реальным сервером bbc.com.