3

Я пытаюсь настроить систему аутентификации для домашнего WiFi, которая не зависит от того, какая точка доступа / маршрутизатор используется. Эта система аутентификации будет строго следовать модели неавторизованного портала, но я не верю, что детали (пользовательского) неавтоматизированного портала важны.

Для этого я бы хотел разместить портал и аутентификацию на недорогом устройстве (например, Raspberry Pi). Однако после того, как они подтвердят свою подлинность, я бы хотел, чтобы пользователи были подключены к другой точке доступа. То есть Raspberry Pi будет выполнять только этап аутентификации, но не будет действовать как точка доступа обычного использования для аутентифицированных пользователей. Опять же, оптимально это будет работать с любой точкой доступа / маршрутизатором, которая имеет обычную защищенную паролем сеть Wi-Fi.

Вот желаемый поток входа в систему для этого проекта:

  1. Пользователь подключается к WiFi с поддержкой Raspberry Pi
  2. Пользователь направляется на сайт портала, размещенный на Pi, и входит в систему.
  3. (Предполагается, что аутентификация прошла успешно) Пользователь отключен от Pi и подключен к основной точке доступа
  4. Пользователь теперь может просматривать Интернет как обычно

Существуют ли методы для достижения такого рода вещи? Я отдаю себе отчет в том , как настроить Raspberry Pi , чтобы действовать и в качестве точки доступа и адаптивного портала, а не только как адаптивный портал.

|источник

3 ответа3

1

На самом деле это нереально сделать безопасно, хотя это возможно при использовании типа «Rube Goldberg».

Я предполагаю, что это может быть сделано - грубо - путем настройки маршрутизатора DHCP на PI и предоставления короткого времени аренды до освобождения - и изменения раздачи IP-адреса (и не включения DHCP на маршрутизаторе) - но тогда у вас будет огромный битва, гарантирующая, что это не может быть обойдено с некоторой простой статической адресацией.

Вы можете в значительной степени достичь чего-то подобного с помощью взаимодействия маршрутизатора, чтобы запретить порт DNS (запросы порта 53) на WAN с любого устройства, отличного от портала авторизации, и раздать портал DNS пленника с DHCP и получить портал авторизации предоставляет DNS-ответы для себя, пока пользователь не будет освобожден. Это может быть подорвано с помощью простого VPN или туннеля.

Это намного сложнее, чем кажется (что-то, с чем я играю в свое свободное время - не так много!), Но в зависимости от вашего роутера, будет что-то вроде "Wild Dog" - который встроен в современные версии DD-WRT - работа для вас - может показаться, что маршрутизатор выполняет базовую запись и передает работу портала другому устройству.

|источник
0

Учитывая, что OpenBSD работает на Raspberry Pi, вы можете использовать authpf, чтобы позволить каждому пользователю аутентифицировать свой сеанс с помощью pubkey/password, и позволить таким аутентифицированным клиентам проходить через брандмауэр - однако он действительно лучше всего работает непосредственно на маршрутизаторе, отвечающем за фильтрацию. См. Https://www.openbsd.org/faq/pf/authpf.html и Google для примеров реализации.

Более удобный для пользователя вариант - это что-то вроде https://coova.github.io/CoovaChilli/ Похоже, что он активно поддерживается и имеет поддержку RADIUS.

|источник
0

Опять же, оптимально это будет работать с любой точкой доступа / маршрутизатором

Точки доступа управляют Wi-Fi (канальный уровень), маршрутизаторы управляют IP (сетевой уровень). Хотя они часто объединяются в одну пластиковую коробку, они по-прежнему выполняют две разные функции.

Таким образом, идея пленных порталов заключается в том, что устройство по обычному пути пакетов перехватывает их и генерирует поддельный ответ "перенаправления", который сообщает пользователю, что он должен посетить страницу входа. Перенаправление может быть сделано:

  • шлюз по умолчанию (маршрутизатор) путем перехвата всего TCP-соединения с использованием iptables (наиболее распространенный метод);
  • DNS-сервер, возвращая поддельные ответы поиска DNS, которые указывают на "плененный" сервер (ненадежный и очень легко обойти);
  • точка доступа или коммутатор, переписывая заголовки пакетов так, чтобы пакет достиг другого шлюза (очень редко, но технически возможно)…

В любом случае, тем не менее, ваш "пленный портал" Raspberry должен быть вставлен в обычный путь. Даже если вы создадите его с использованием метода «поддельного DNS-сервера» (который обрабатывает очень мало трафика, но также очень легко обходится), вам как минимум потребуется перенастроить основной маршрутизатор для предоставления IP-адреса Raspberry через DHCP.

(И многие дешевые беспроводные маршрутизаторы на самом деле не позволяют вам это настраивать - я думаю, вам придется отключить обычную службу DHCP, а также полностью обслуживать DHCP из Raspberry.)

Короче говоря, нет, я не верю, что встроенное портальное устройство "подключи и работай" возможно реализовать таким образом.

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

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .