Доступ в Интернет в отелях, кафе в аэропортах часто блокируется специальным порталом, который заставляет вас перейти на определенную веб-страницу при первом использовании, например страницу оплаты или какую-либо страницу, чтобы принять условия обслуживания или страницу аутентификации / авторизации. Вы видите это как с беспроводным, так и с проводным подключением.
Как это работает?
Конечно, это зависит от производителя беспроводного продукта, но, по моему опыту, обычно работает примерно так:
Location: заголовок, который перенаправляет вас на страницу входа / политики (например, http://hotelwireless.net/login). Он может находиться непосредственно на интеллектуальной точке доступа или на центральной станции управления.Что касается того, как его называть, я слышал, что его чаще всего называют «перехватывающим порталом» или «порталом беспроводного доступа».
Во-первых, для выполнения перенаправления вам понадобится встроенный аутентификатор (контроллер доступа). В контексте вашей темы вам понадобится контроллер беспроводной сети, если вы выберете централизованное управление точкой доступа. ИЛИ вы также можете разместить контроллер доступа к сети типа Captive Port с функциями Wall Garden.
NAS отслеживает трафик, входящий в нисходящий канал (на стороне клиента) через необработанный сокет в беспорядочном режиме, и когда обнаруживается инициированный браузером трафик для неаутентифицированного клиента, ему в качестве ответа дается перенаправление HTTP. Таким образом, браузер при получении перенаправляется на домашнюю страницу нашего портала CAPTIVE, которая может быть размещена на сервере аутентификации или из коробки на каком-либо внешнем веб-сервере.
Единственная задача этой страницы - предоставить пользователю пользовательский интерфейс для ввода учетных данных. введенные учетные данные пересылаются обратно демону аутентификатора, например, chilli в случае coova chilli, затем эти учетные данные передаются в виде запроса радиуса на сервер 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
Адаптивный портал - это аутентификация уровня 3, которая требует, чтобы устройства подключились к сети и получили IP-адрес и соответствующую информацию DNS перед аутентификацией через администрирующий портал. Следующие шаги объясняют весь процесс адаптивного портала, когда собственная 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.