LINUX.ORG.RU
ФорумTalks

Captive Portal для самых маленьких

 , ,


4

6

Здравствуйте мои маленькие любители авиационного спирта =) !

Последние пару дней занимался настройкой Wi-Fi, да не простого, а стильного-модного-молодёжного, со своим Captive Portal. Для тех, кто в танке: это когда ты подключаешься к Wi-Fi сети, но прежде чем допускать тебя к интернетам и ЛОРу в частности, нужно пройти какую-никакую дополнительную авторизацию на веб-страничке, third-party так сказать.

Такой подход я считаю более секурным, потому как, доступ каждого клиента по Wi-Fi регулируется лично через iptables, а не тупо форвардится всё подряд. Какой простор для творчества! Во-вторых, авторизация происходит через веб-страничку, а не WPA и прочие нативные механизмы wireless-сетей, которые как и всё в нашем мире, не вечны и надёжность их хромает.

После вступления, приступим.

hostapd? checked!

iptables? checked!

nginx? checked!

Рассказывать о настройке NAT лишний раз не буду, думаю, у вас уже должна быть настроена раздача Wi-Fi, и всё, что вам ненужно, это только Captive Portal.

wlan0 — имя интерфейса Wi-Fi
eth0 — имя интерфейса с интернетами
192.168.0.0/24 — локалка

# создаём кольцо
iptables -t mangle -N captive

# все пакеты из ви-фи отправляем в это кольцо
iptables -t mangle -A PREROUTING -i wlan0 -j captive

# доверенные клиенты из кольца выходят сразу же (адреса инсертим в начало списка)
# фильтр хоть по MAC, хоть по IP
# этот список должен редактироваться через сайт (Captive Portal)
# iptables -t mangle -I captive -m mac --mac-source 00:00:00:00:00:00 -j RETURN
# iptables -t mangle -I captive -s 192.168.0.137 -j RETURN

# если ты всё ещё в кольце, тогда ставим метку
iptables -t mangle -A captive -j MARK --set-mark 1

# всех с меткой перенаправляем к себе, когда они открывают сайты 80
# про 443 забудьте
iptables -t nat -A PREROUTING -i wlan0 -m mark --mark 1 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.1

# всех с меткой при прочем трафике просто дропаем
iptables -t filter -A FORWARD -i wlan0 -m mark --mark 1 -j DROP

# успешно натим оставшихся доверенных
iptables -t filter -A FORWARD -i wlan0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE

Вот и всё. Здесь включена проверка через -i wlan0, таким образом это не вызовет никаких конфликтов с другими сетями, т.к. у меня в продакшене под кроватью очень много правил iptables и я знаю, о чём говорю.

Подводные камни, на которые я наткнулся и спешу поделиться с вами. В соседнем треде мне научно-популярно объяснили, что тщетно пытаться настроить редирект по HTTPS на свой Captive Portal, это просто не сработает, это уже MitM атака. Не очень-то и хотелось! ;p

Если у вас используются личные DNS, то наверняка у вас есть правило, разрешающее локальные запросы к серверу (tcp/53 udp/53). Не забудьте разрешить запросы и к локальному веб-серверу (tcp/80). Но а если вы сообщаете Wi-Fi клиентам какие-то публичные NS, то не забудьте разрешить доступ клиентам к ним: iptables -t filter -I FORWARD -i wlan0 -s 192.168.0.0/24 -d 8.8.8.8/32 -j ACCEPT. А суть такова. Когда клиент подключается к Wi-Fi, он проверяет доступность интернета в целом, для этого смартфоны качают со своих серверов файлы и проверяют корректность полученных данных. Если оно не сможет резолвить хост запрашиваемого сайта, то на этом и споткнётся и проверка на наличие Captive Portal в сети не пройдёт.

Собственно, теперь к механизму Captive Portal.

Как уже замечено, это личная прерогатива каждого клиента, проверять доступность интернета, и если в результате проверки что-то пошло не так, — значит либо интернета нет, либо Captive Portal.

Мы перенаправили все запросы на 80 порт к себе, на свой локальный сервер. Теперь nginx должен в ответ на все HTTP запросы отвечать кодом 302. Не 200, не 301, не 511, а именно 302, а затем перенаправлять вас на страничку с third-party авторизацией, и только таким макаром например мой Андрюша-9 смог обнаружить, что у меня таки Captive Portal, а не какой-то сломанный интернет. В результате сразу после подключения к Wi-Fi сети должно появиться Push-уведомление: Скриншот #1, при нажатии которого откроется страничка, куда редиректит nginx Скриншот #2.

Сам скрипт странички я оставляю вам на откуп: думаю, вам не составит никакого труда наслюнявить однострочник на php добавляющий $_SERVER['REMOTE_ADDR'] в iptables через shell_exec(); или типа того. Да? Да. Ваш Captive Portal полностью в ваших руках.

Вот и весь механизм работы Captive Portal. Спрашивайте ответы.

★★★★★

Ответ на: комментарий от vodz

Щас браузеры и ОС, если инет не работает, сами обращаются на некоторый адрес на 80 порт, и выводят окошко типа перейдите на страничку авторизации

TheAnonymous ★★★★★
()

однострочник на php добавляющий $_SERVER['REMOTE_ADDR'] в iptables через shell_exec(); или типа того. Да?

А iptables вестимо от рута

TheAnonymous ★★★★★
()

Эх захотелось вспомнить админскую деятельность. Автор, лучше размещай такие заметки на каком-нибудь уютном блоге. А тут потеряется тема через пару месяцев.

rumgot ★★★★★
()
Последнее исправление: rumgot (всего исправлений: 1)
Ответ на: комментарий от TheAnonymous

Щас браузеры и ОС, если инет не работает, сами обращаются на некоторый адрес на 80 порт

На счёт браузеров надо бы уточнить какие, мои так не делают, а уж про ОС — так это вы про винду что ли?

vodz ★★★★★
()
Ответ на: комментарий от vodz

Дефолтный firefox.

ОС — так это вы про винду что ли?

Не только, ведроид же (скриншот 1 в ОП), подозреваю что на гейоси так же

TheAnonymous ★★★★★
()
Ответ на: комментарий от vodz

Камрад TheAnonymous верно всё сказал. Когда вы подключились к интернету, все, повторяю, _все_ устройства проверяют подключение к интернету. Все они делают это плюс-минус одинаково: запрашивают данные со своих серверов через 80 порт, а значит запрос в любом случае будет и правило iptables отработает. И когда оно отработает, устройство на это отреагирует, т.к. получает не то, что оно запросило, а... Captive Portal.

Это не стандарт де-факто, но это личная хотелка, если хотите, всех современных ОС и/или приложений. Windows? Да.

При включении в сеть все Apple-устройства запрашивают из интернетов этот докУмент: http://captive.apple.com/hotspot-detect.html, да, через HTTP, и при неполучении того, что они ждут (Success!), они сообщают о наличии Captive Portal.

Все Google-устройства запрашивают этот докУмент: http://connectivitycheck.gstatic.com/generate_204 и при неполучении корректного ответа (HTTP/1.1 204) сообщают о Captive Portal.

Все Windows-устройства запрашивают этот докУмент: http://www.msftncsi.com/ncsi.txt

Все Amazon-устройства...

Ещё раз повторюсь. Это не какой-то официальный стандарт, это личная хотелка всех девайсов показывать вам Push-уведомление, чтобы быть в теме. Не более того. Поэтому вы со 100% успехом можете спокойно внедрять Captive Portal в свою сеть и быть уверенным в его корректной обработке всеми клиентами.

В своём ОП-посте я пытался изложить все нюансы, как например, необходимость отвечать 302, чтобы Captive Portal был обнаружен.

Спрашивайте ответы.

Spoofing ★★★★★
() автор топика
Ответ на: комментарий от TheAnonymous

Уж как реализуете. Могёте записывать в БД, а внешним shell-скриптом от рута дёргать данные.

Я по этому поводу не заморачиваюсь, прямо так и сказал, делайте сами, чтобы меня не хаяли за shell_exec(); от рута в качестве эталонного примера реализации. :D

Spoofing ★★★★★
() автор топика
Ответ на: комментарий от Spoofing

все, повторяю, _все_

Не надо повторять, мой линукс никуда без спроса на никакие «свои» серверы не лезет.

vodz ★★★★★
()

ОП-пост не читал, либо читал но не понял

IP-over-DNS режется?

utf8nowhere ★★★
()

iptables в 2020 году - это не интересно, и протухленько.
Тема самого портала и ААА не раскрыта.
Пограмировать на пхп с shell_exec - колхозненько.

В итоге, по прочтению ОП от владельца крупнейшего погребного датацентра - одно разочарование. Новизны нет.

system-root ★★★★★
()

Придираюсь по мелочам

Но а если вы сообщаете Wi-Fi клиентам какие-то публичные NS, то не забудьте разрешить доступ клиентам к ним

А как же ip over dns..
В идеале для неавторизованных юзеров надо делать редирект днс на свой днс сервер, который возвращает на все запросы 1 ип, который и редиректится потом на nginx. Вот только особо хитрые клиенты могут чекать dnssec. Так что вопрос открыт.

Bers666 ★★★★★
()
15 февраля 2020 г.
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.