В качестве проекта я создаю собственные веб-страницы адаптивного портала для «неаутентифицированных» пользователей. Это пользователи, которые не нажали кнопку на моей странице адаптивного портала. Я хочу, чтобы это было вне диапазона (как вариант развертывания пакетной защиты), чтобы моя машина Linux не действовала как маршрутизатор / прокси.
Для этого мне нужно знать, КАК устройство, в моем случае iPhone под управлением iOS 8, перенаправляется на страницу адаптивного портала.
Вот что, я думаю, должно произойти:
Я прошел через этот сайт, и Google в течение нескольких дней даже пытался взглянуть на код Packetfence (я не разработчик perl), мне нужно подтвердить, верен ли мой описанный выше процесс, или список правильных маркеров шаги. Я смотрел на эта ошибка сервера post, это подробная информация о том, как происходит перенаправление, и, что более важно, как НЕ сделать перенаправление после того, как пользователь «аутентифицирован».
Я признателен, если у кого-нибудь есть эти знания, чтобы заполнить пробелы или указать мне на веб-сайт, на котором есть «как / что выполняет перенаправление - dns / dhcp / http / iptables).
Проблема, которую я пытаюсь решить, состоит в том, чтобы сформулировать технический процесс того, как это работает, расширяя другие сообщения на этом сайте, в которых говорится, что «первый запрос должен быть перенаправлен». У меня вопрос ... как / какие инструменты мне нужны для этого.
Спасибо!
Первое, что вам нужно для перенаправления, - это встроенный аутентификатор (контроллер доступа), так как в контексте темы вам понадобится контроллер беспроводной локальной сети, если вы выберете центральное управление AP. вы также можете разместить контроллер доступа к сети в виде адаптивного портала с функциями Wall Gardened
NAS отслеживает трафик, поступающий по нисходящему каналу (на стороне клиента) через необработанный сокет беспорядочного режима, и когда обнаруживается инициированный браузером трафик для неаутентифицированного клиента, ему в качестве ответа дается перенаправление HTTP. таким образом, браузер при получении перенаправляется на домашнюю страницу нашего портала CAPTIVE, которая может быть размещена на сервере аутентификации или из коробки на каком-либо внешнем веб-сервере.
Единственная задача этой страницы - предоставить пользователю интерфейс для ввода учетных данных. введенные учетные данные пересылаются обратно демону аутентификатора, как перец чили в случае coova chilli, далее эти учетные данные передаются в виде запроса радиуса на сервер RADIUS или могут быть проверены локально. После успешной аутентификации состояние клиента на аутентификаторе помечается как авторизованное, и клиенту предоставляется доступ.
Наиболее широко используемый подход - перехват HTTP-запроса, инициированного пользователем, и кода 302 в качестве ответа клиенту. в чили это голубь через функцию ниже
http_redirect2 () {cat <<EOF
HTTP / 1.1 302 перенаправление
Расположение: $ 1
Set-Cookie: PORTAL_SESSIONID = $ PORTAL_SESSIONID
Установить cookie: COOVA_USERURL = $ COOVA_USERURL
Подключение: закрыть
EOF
exit
}
Это перенаправление может быть легко достигнуто с помощью программного интерфейса tuntap с интерфейсом на стороне клиента, который перехватывает клиентский трафик. Дальнейшее перенаправление также может быть достигнуто через отравление DNS. но иногда может вызывать проблемы, если ответы кэшируются в клиентском браузере. Дальнейшие действия могут быть выполнены более конкретно в зависимости от проблемной области.
Я могу помочь тебе с этим, если ты хочешь