hostapd a OpenVPN na jednom Pi: komu patří výchozí trasa?

hostapd a klient OpenVPN mohou sdílet jeden Pi, když si most ponechá vlastní výchozí trasu a tunel si ponechá cestu ke svému serveru. Příkazy a vrácení zpět.

Telefony se připojí k přístupovému bodu, dostanou adresu a pak nekam nesáhnou, jakmile se tunel zvedne. hostapd je v takovém stavu obvykle zdravý, a OpenVPN také; láme se výchozí trasa, která na mostě buď nikdy nebyla, nebo ji tunel nahradil, aniž by nechal cestu k samotnému serveru VPN. Tato příručka vrátí trasu tam, kam patří, a výsledek doloží z klienta, ne z Pi. Každý krok je vratný a nic zde nemění konfiguraci tunelu, dokud nevíte, který provoz v něm chcete.

Než něco upravíte, zmapujte rozhraní

Známé uspořádání staví bezdrátové rádio a kabelový port do br0, spouští hostapd proti mostu a rozdává lease z dnsmasq, zatímco klient OpenVPN vytváří tun0. Pak tři oddělené požadavky vypadají jako jeden: klienti přístupového bodu potřebují Pi jako svou bránu, Pi potřebuje trasu do internetu, aby dosáhl svého serveru, a most potřebuje adresu brány, kterou tito klienti mohou použít.

Přečtěte si aktuální stav, než ho změníte, protože tyto čtyři příkazy oddělují problém rozhraní od problému směrování.

ip -br addr
ip route show
ip link show master br0
bridge link show

Pokud br0 nese adresu, ale nemá výchozí trasu, klienti dosáhnou Pi a nic za ním. Pokud výchozí trasa ukazuje na tun0, zatímco je tunel vypnutý, Pi nemá vůbec žádnou funkční cestu a symptom klienta vypadá naprosto stejně. Oba případy vypadají z telefonu identicky, proto je třeba číst směrovací tabulku přímo.

Dejte mostu výchozí trasu, která mu patří

Raspberry Pi OS často nechává most bez výchozí trasy, když most vznikl až po zapsání souboru rozhraní. Blok patří do /etc/dhcpcd.conf a měl by jmenovat nadřazený router, nikoli Pi.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

V tomto příkladu je 192.168.50.1 stávající router a 192.168.50.2 je adresa mostu Pi ve stejné podsíti, takže dosaďte svůj vlastní plán místo kopírování čísel. Členové mostu také nesmějí žádat routery, jinak Pi skončí s konkurujícími výchozími trasami, jejichž vítěz závisí na metrice a čase, ne na záměru.

Po systemctl restart dhcpcd má ip route show default uvést br0 jednou a bez duplikátu z kabelového portu. Potvrďte vyhledání, ne tabulku, protože zastaralý záznam může sedět vedle vítězného: ip -4 route get 203.0.113.10 musí jmenovat br0. Ta adresa pochází z dokumentačního rozsahu TEST-NET-3, takže se nemůže srazit se skutečným serverem, dokud to čtete.

Zabraňte tunelu, aby unášel cestu k vlastnímu serveru

Klient OpenVPN, který přijme redirect-gateway, převezme výchozí trasu a pošle ji do tunelu. To je správné, když má VPN používat každý klient přístupového bodu, a špatné, když jen některé cíle. Ať tak či onak, vlastní spojení Pi se serverem nesmí cestovat uvnitř tunelu, který se ještě staví. OpenVPN přidá hostitelskou trasu k vzdálenému bodu přes původní bránu, když přesměruje výchozí trasu, a to je přesně to chování, které drží transport naživu; pokud tato trasa chybí, tunel se zhroutí, jakmile se naváže.

Rychlé srovnání této transportní cesty před připojením a po něm stojí za těch deset sekund. ip -4 route get 203.0.113.10 má v obou stavech uvést zařízení spodní vrstvy, mění se jen metrika. Pokud po zvednutí tunelu uvádí tun0, hostitelská trasa nebyla nikdy nainstalována a příští opětovné připojení selže.

Když má tunelem projít jen vybrané prefixy, použijte route-nopull a přidejte požadované trasy ručně, nebo ze serveru pošlete užší sadu. Most si v takovém návrhu ponechá výchozí trasu a DNS se stává dalším rozhodnutím: předávání dnsmasq do domácího resolveru má smysl jen pro jména, která tam skutečně žijí.

Rozhodněte o předávání a NAT

Plný tunel potřebuje zapnuté předávání na Pi a bránu na vzdálené straně ochotnou směrovat podsíť přístupového bodu. Zkontrolujte předávání dřív než cokoli jiného, protože nula dělá každou změnu trasy nepodstatnou.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Pravidlo NAT je zkratka, která funguje, když server nepřijme prefix přístupového bodu, za cenu toho, že každý klient bude v protokolech vzdálené strany vypadat jako tunelová adresa Pi. Směrování prefixu bez NAT udržuje adresy viditelné a závisí na zpětné trase pro 192.168.50.0/24 na domácí straně.

Zapište volbu vedle pravidel firewallu, protože pravidlo NAT neviditelné v návrhu se po šesti měsících stane nevysvětlitelným. Držte IPv6 ve stejném rozhodnutí; funkční cesta IPv4 vedle rozbité cesty IPv6 se v prohlížeči stále čte jako napůl rozbitá.

Ověřte z klienta a poté se čistě vraťte

Testujte v tomto pořadí z telefonu nebo notebooku na přístupovém bodu: lease z dnsmasq, ping na adresu mostu, poté cíl na vzdálené straně tunelu. Každý krok izoluje jednu vrstvu místo toho, aby vytvořil jedinou ne užitečnou chybu.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

Poté potvrďte, že Pi má stále vlastní cestu ven: ip route get 203.0.113.10 má uvést zařízení spodní vrstvy a ping -c 3 -I br0 203.0.113.10 má odpovědět, pokud server povoluje ICMP. Pokud první dva kroky klienta projdou a třetí selže, chyba je v předávání nebo NAT. Pokud selže druhý krok, most nebo DHCP stále nejsou úplné.

Vrácení je jedna úprava souboru a dva příkazy: odstraňte blok, restartujte dhcpcd a nahraďte výchozí trasu výslovně pomocí ip route replace default via 192.168.50.1 dev br0. Udělejte to dřív, než se zavře okno údržby, ne potom, protože Pi, který ztratil výchozí trasu, je nedostupný ze sítě, kterou byste použili k jeho opravě.

Související články