Я пытаюсь настроить систему аутентификации для домашнего WiFi, которая не зависит от используемой точки доступа/маршрутизатора. Эта система аутентификации будет тесно связана с моделью портала захвата, но я не думаю, что детали (настраиваемого) портала захвата важны.
Чтобы добиться этого, я хотел бы разместить портал авторизации и аутентификацию на недорогом устройстве (например, Raspberry Pi). Однако после аутентификации я хотел бы, чтобы пользователи были переподключены к другой точке доступа. То есть, Raspberry Piтольковыполнить шаг аутентификации, но не будет действовать как точка доступа обычного использования для аутентифицированных пользователей. Опять же, оптимально это будет работать с любой точкой доступа/маршрутизатором, имеющим обычную защищенную паролем сеть WiFi.
Вот желаемый процесс входа в систему для этого проекта:
- Пользователь подключается к Raspberry Pi с поддержкой WiFi.
- Пользователь перенаправляется на сайт портала авторизации, размещенный на Pi, и входит в систему.
- (При условии успешной аутентификации) Пользователь отключается от Pi и подключается к основной точке доступа.
- Теперь пользователь может просматривать веб-страницы как обычно.
Есть ли какие-нибудь методы для достижения такого рода вещей? Я знаю, как настроить Raspberry Pi, чтобы он действовал какобаточка доступа и портал авторизации, но не только как портал авторизации.
решение1
На самом деле это нереально сделать надежно, хотя это можно сделать, используя схему типа «Руба Голдберга».
Полагаю, это можно сделать — грубо говоря — настроив DHCP-маршрутизатор на PI и предоставив короткий срок аренды до освобождения, а также изменив выдаваемый IP-адрес (и не включая DHCP на маршрутизаторе), — но тогда вам придется приложить немало усилий, чтобы гарантировать, что это нельзя будет обойти с помощью простой статической адресации.
Вы можете в значительной степени достичь чего-то похожего с помощью сотрудничества маршрутизатора, чтобы запретить порт DNS (запросы порта 53) в WAN с любого устройства, кроме портала захвата, и раздавая DNS портала захвата с DHCP, и заставляя портал захвата предоставлять ответы DNS для себя, пока пользователь не будет освобожден. Однако это можно обойти с помощью простого VPN или туннеля.
Это намного сложнее, чем кажется (я как раз с этим и играюсь в свободное время, так что не так уж и много!), но в зависимости от вашего маршрутизатора, подойдет ли вам что-то вроде «Wild Dog», встроенное в современные версии DD-WRT? Похоже, что маршрутизатор выполняет базовый захват и передает работу по порталу другому устройству.
решение2
Учитывая, что OpenBSD работает на Raspberry Pi, вы можете использовать authpf, чтобы позволить каждому пользователю аутентифицировать свою сессию с помощью открытого ключа/пароля и позволить таким аутентифицированным клиентам проходить через брандмауэр — однако, это действительно лучше всего работает непосредственно на маршрутизаторе, отвечающем за фильтрацию. См.https://www.openbsd.org/faq/pf/authpf.htmlи поищите в Google примеры реализаций.
Более удобный вариант — это что-то вродеhttps://coova.github.io/CoovaChilli/ Судя по всему, он активно поддерживается и имеет поддержку RADIUS.
решение3
Опять же, оптимально это будет работать с любой точкой доступа/маршрутизатором.
Точки доступа управляют Wi-Fi (канальный уровень), маршрутизаторы управляют IP (сетевой уровень). Хотя их часто объединяют в одну пластиковую коробку, они по-прежнему выполняют две различные функции.
Итак, идея порталов захвата заключается в том, что устройство на обычном пути пакетов перехватывает их и генерирует поддельный ответ «перенаправления», который сообщает пользователю, что ему нужно посетить страницу входа. Перенаправление может быть выполнено следующим образом:
- шлюз по умолчанию (маршрутизатор), перехватывая все TCP-соединение с помощью iptables (наиболее распространенный метод);
- DNS-сервер, возвращая поддельные ответы на поиск DNS, которые указывают на «захваченный» сервер (ненадежно и очень легко обойти);
- точку доступа или коммутатор, переписывая заголовки пакетов таким образом, чтобы пакет достигал другого шлюза (очень редкийно технически возможно)…
В любом случае, однако, ваш «портал пленения» Raspberryимеетдля вставки в обычный путь. Даже если вы создаете его с помощью метода "поддельного DNS-сервера" (который обрабатывает очень мало трафика, но его также очень легко обойти),как минимумВам необходимо будет перенастроить основной маршрутизатор, чтобы он предоставлял IP-адрес вашему Raspberry через DHCP.
(И многие дешевые беспроводные маршрутизаторы на самом деле не позволяют вамнастроить(Я полагаю, вам придется отключить обычную службу DHCP и обслуживать DHCP полностью с Raspberry.)
Короче говоря, нет, я не верю, что устройство портала авторизации «plug and play» возможно реализовать таким образом.
На самом деле, у него есть серьезные проблемы с точки зрения безопасности. Если онбылиесли Raspberry Pi может просто подключиться и каким-то образом перехватить трафик всех пользователей без настройки маршрутизатора... то любой мошеннический клиент с вредоносным ПО также сможет просто подключиться и перехватить трафик всех пользователей.