Я пытаюсь создать точку доступа Wi-Fi на адаптивном портале.
Цель установки:
Пользователи, подключающиеся к точке доступа через wlan0, никогда не должны иметь доступа к Интернету через eth1.
Чтобы «Войти в сеть Wi-Fi» отображалось на android, iphone и любом устройстве, которое будет подключаться, я пытаюсь маршрутизировать запросы, которые идут на
http://clients1.google.com/generate_204 и другой URL-адрес для других операционных систем, я еще не понял, на мой локальный сервер и возвращать то, что вернут реальные серверы.
Для этого я использую dnsmasq и hostapd.
Проблема: когда я использую address = / # / 127.24.2.1 в dnsmasq.conf, интернет-запросы, поступающие из внутренних скриптов, также не работают. Я думаю, что слежу за страницей руководства по настройке dnsmasq, в которой говорится, как использовать dnsmasq для фильтрации только трафика интерфейса wlan0.
что мне делать дальше.
У машины есть эти интерфейсы
eth1 Link encap:Ethernet HWaddr 00:1e:06:30:5b:03
inet addr:192.168.0.107 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::21e:6ff:fe30:5b03/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:37047 errors:0 dropped:0 overruns:0 frame:0
TX packets:1752 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3351437 (3.1 MiB) TX bytes:176100 (171.9 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:796 errors:0 dropped:0 overruns:0 frame:0
TX packets:796 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:284838 (278.1 KiB) TX bytes:284838 (278.1 KiB)
wlan0 Link encap:Ethernet HWaddr 98:de:d0:1b:95:5a
inet addr:172.24.1.1 Bcast:172.24.1.255 Mask:255.255.255.0
inet6 addr: fe80::9ade:d0ff:fe1b:955a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:576 (576.0 B)
DNSMASQ выглядит так
interface=wlan0 # Use interface wlan0
listen-address=172.24.1.1 # Explicitly specify the address to listen on
#bind-interfaces # Bind to the interface to make sure we aren't sending things elsewher$
server=8.8.8.8 # Forward DNS requests to Google DNS
domain-needed # Don't forward short names
bogus-priv # Never forward addresses in the non-routed address spaces.
dhcp-range=172.24.1.50,172.24.1.150,12h # Assign IP addresses between 172.24.1.50 and 172.24$
address=/#/172.24.1.1
except-interface=eth1
Я использую экспресс-сервер nodejs и делаю это
app.get('/generate_204', function(req, res) {
console.log('generate 204 hit');
res.statusCode = 302;
res.setHeader("Location", "/");
res.end();
});
Я создал точку доступа с помощью hostapd, конфигурация
# This is the name of the WiFi interface we configured above
interface=wlan0
# Use the nl80211 driver with the brcmfmac driver
driver=nl80211
# This is the name of the network
ssid=Pi3-AP
# Use the 2.4GHz band
hw_mode=g
# Use channel 6
channel=6
# Enable 802.11n
ieee80211n=1
# Enable WMM
wmm_enabled=1
# Enable 40MHz channels with 20ns guard interval
ht_capab=[HT40][SHORT-GI-20][DSSS_CCK-40]
# Accept all MAC addresses
macaddr_acl=0
# Use WPA authentication
auth_algs=1
# Require clients to know the network name
ignore_broadcast_ssid=0
# Use WPA2
wpa=2
# Use a pre-shared key
wpa_key_mgmt=WPA-PSK
# The network passphrase
wpa_passphrase=raspberry
# Use AES, instead of TKIP
rsn_pairwise=CCMP
Я попытался объяснить требование, но не уверен, что хорошо выполнил поясняющую часть. Есть еще один вопрос, который я поднял здесь по поводу сбоя сервера для той же проблемы, которая была помечена как не по теме. Прочитав его, вы четко поймете требование. https://serverfault.com/questions/823139/iptables-for-linux-captive-portal-wifi-hotspot
когда я использую address = / # / 127.24.2.1, интернет-запросы, поступающие из внутренних скриптов, также не работают
Кажется, что ваши внутренние сценарии используют для разрешения DNS-имен тот же локальный сервер dnsmasq, что и ваши клиенты Wi-Fi.
Проверьте свои /etc/resolv.conf
конфигурация и, если присутствует ваш адрес сервера dnsmasq (127.24.2.1
или 127.0.0.1
или другое) - удалите. Вместо этого используйте DNS-серверы вашего интернет-провайдера, или Google DNS, или любые другие, которые вы предпочитаете, которые не заменяют адреса на 127.24.2.1
.
Заметка. Если вы используете систему resolvconf генерировать /etc/resolv.conf
(в resolv.conf настоящее предупреждение как # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
), то вам нужно отредактировать конфиги в /etc/resolvconf/resolv.conf.d/
вместо этого, а после регенерировать /etc/resolv.conf
(перезапустите сеть или лучше - перезапустите всю систему)
Другая возможность: удалить пакет resolvconf и редактировать /etc/resolv.conf
Если кому-то интересно обновление (в 2017 году) по этому вопросу ... Я смог воссоздать проблему и нашел решение.
Отключить dnsmasq от разрешения для интерфейса обратной связи (в /etc/dnsmasq.conf
):
except-interface=lo
Добавить в хвостовой файл resolvconf (в /etc/resolvconf/resolvconf.conf.d/tail
)
nameserver 8.8.8.8
Перезапустить службы
sudo systemctl restart dnsmasq
sudo resolvconf -u
Что это делает
dnsmasq
теперь будет отклонять любой запрос DNS на локальном хосте, и тогда локальный хост должен будет прибегнуть к использованию второго сервера имен в строке (который теперь 8.8.8.8)
Что делать, если нет /etc/resolvconf/resolvconf.conf.d/
каталог?
Вместо этого у вас может быть установлен openresolv ... Я удалил openresolv и установил resolvconf. Вы столкнетесь с другими проблемами, но это, вероятно, не имеет отношения к этому ответу.