Портал Captive на отдельном устройстве от точки доступа

620
phepp

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

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

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

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

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

3

3 ответа на вопрос

1
davidgo

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

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

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

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

К сожалению, не похоже, что мой маршрутизатор поддерживает DD-WRT. Поправьте меня, если я ошибаюсь, но похоже, что передача обслуживания может быть самым большим препятствием на основе вашего ответа. Я не против того, чтобы "передача" была ручной на стороне клиента. По сути, возможность, которую я ищу здесь, - это возможность предоставить пользователям доступ к главному маршрутизатору после того, как они прошли настраиваемый портал с привязкой к маршрутизатору. То есть я согласен с тем, что заставляю пользователя вручную отключаться от Pi и переподключаться к маршрутизатору, пока не требуется общий секрет. phepp 6 лет назад 0
Я понимаю, что вы пытаетесь сделать (но не вариант использования), и вежливо пытаюсь указать, что это не имеет смысла. На вашем сетевом уровне лучшее решение, вероятно, состоит в том, чтобы разместить основной / второй маршрутизатор за вашим основным маршрутизатором. davidgo 6 лет назад 1
0
user2497

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

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

0
grawity

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

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

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

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

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

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

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

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

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