Как скрытно работает перенаправление скрытого портала

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

  • Кнопка нажата, и Mac-адрес пользователя добавляется к "чему-то", и с этого момента DNS выполняет правильное разрешение (??) или, возможно, iptables перенаправляет запросы DNS на другой общедоступный хост DNS ( ??)
  • Я просматривал этот сайт, и Google в течение нескольких дней даже пытался посмотреть код Packetfence (я не разработчик perl), мне нужно подтвердить, верен ли описанный выше процесс, или список правильных шагов. Я просмотрел это сообщение об ошибке сервера , это подробности о том, как происходит перенаправление, и, что более важно, как НЕ сделать перенаправление после того, как пользователь «аутентифицирован».

    Я признателен, если кто-нибудь обладает этими знаниями, чтобы заполнить пробелы или указать мне на веб-сайт с " как / что происходит перенаправление - dns / dhcp / http / iptables).

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

    Спасибо!

    1
    задан 13 April 2017 в 15:14
    1 ответ

    Первое, что вам нужно для достижения перенаправления, это какой-нибудь встроенный аутентификатор ( контроллер доступа ), так как в контексте темы вам понадобится контроллер беспроводного фургона, если вы выберете централизованное управление точкой доступа. Вы также можете разместить в плену портал типа сетевого контроллера доступа с особенностями Wall gardened

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

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

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

    Наиболее широко используемое одобрение - перехват HTTP-запроса, поданного пользователем, и 302 кода в качестве ответа клиенту. в чили это голубь через funtion ниже

    http_redirect2() { cat < < EOF

    HTTP/1.1 302 Redirect

    Location: $1

    Set-Cookie: PORTAL_SESSIONID=$PORTAL_SESSIONID

    Set-Cookie: COOVA_USERURL=$COOVA_USERURL

    Подключение: закрыть

    EOF

    exit
    

    }

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

    Я могу помочь вам с этим, если вы хотите

    .
    1
    ответ дан 3 December 2019 в 23:51

    Теги

    Похожие вопросы