hostapd a OpenVPN na jednom Pi: komu patrí predvolená trasa?

hostapd a klient OpenVPN môžu zdieľať jeden Pi, keď si most ponechá vlastnú predvolenú trasu a tunel si ponechá cestu k svojmu serveru. Príkazy a vrátenie.

Telefóny sa pripoja k prístupovému bodu, dostanú adresu a potom sa nikam nedostanú, len čo sa tunel zdvihne. hostapd je v tom stave zvyčajne zdravý, a OpenVPN tiež; láme sa predvolená trasa, ktorá na moste buď nikdy nebola, alebo ju tunel nahradil bez toho, aby nechal cestu k samotnému serveru VPN. Táto príručka vráti trasu tam, kam patrí, a výsledok dokáže z klienta, nie z Pi. Každý krok je vratný a nič tu nemení konfiguráciu tunela, kým neviete, ktorú prevádzku v ňom chcete.

Pred akoukoľvek úpravou zmapujte rozhrania

Známe usporiadanie stavia bezdrôtové rádio a káblový port do br0, spúšťa hostapd proti mostu a rozdáva prenájmy z dnsmasq, zatiaľ čo klient OpenVPN vytvára tun0. Potom tri oddelené požiadavky vyzerajú ako jedna: klienti prístupového bodu potrebujú Pi ako svoju bránu, Pi potrebuje trasu do internetu, aby dosiahol svoj server, a most potrebuje adresu brány, ktorú títo klienti môžu použiť.

Prečítajte si aktuálny stav, skôr než ho zmeníte, pretože tieto štyri príkazy oddeľujú problém rozhrania od problému smerovania.

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

Ak br0 nesie adresu, ale nemá predvolenú trasu, klienti dosiahnu Pi a nič za ním. Ak predvolená trasa ukazuje na tun0, kým je tunel dole, Pi nemá vôbec žiadnu funkčnú cestu a príznak klienta vyzerá presne rovnako. Oba prípady vyzerajú z telefónu identicky, preto treba smerovaciu tabuľku čítať priamo.

Dajte mostu predvolenú trasu, ktorá mu patrí

Raspberry Pi OS často necháva most bez predvolenej trasy, keď most vznikol až po zapísaní súboru rozhrania. Blok patrí do /etc/dhcpcd.conf a mal by menovať nadradený router, nie 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 príklade je 192.168.50.1 existujúci router a 192.168.50.2 je adresa mosta Pi v tej istej podsieti, preto doplňte vlastný plán namiesto kopírovania čísel. Členovia mosta tiež nesmú žiadať routery, inak Pi skončí s konkurujúcimi predvolenými trasami, ktorých víťaz závisí od metriky a času, nie od zámeru.

Po systemctl restart dhcpcd by ip route show default mal uviesť br0 raz a bez duplikátu z káblového portu. Potvrďte vyhľadanie, nie tabuľku, pretože zastaraný záznam môže sedieť vedľa víťazného: ip -4 route get 203.0.113.10 musí menovať br0. Tá adresa pochádza z dokumentačného rozsahu TEST-NET-3, takže sa nemôže zraziť so skutočným serverom, kým to čítate.

Zabráňte tunelu, aby unášal cestu k vlastnému serveru

Klient OpenVPN, ktorý prijme redirect-gateway, prevezme predvolenú trasu a nasmeruje ju do tunela. To je správne, keď má VPN používať každý klient prístupového bodu, a nesprávne, keď len niektoré ciele. Tak či onak, vlastné spojenie Pi so serverom nesmie cestovať vnútri tunela, ktorý ešte stavia. OpenVPN pridáva hostiteľskú trasu k vzdialenému bodu cez pôvodnú bránu, keď presmeruje predvolenú trasu, a to je presne to správanie, ktoré drží transport nažive; ak tá trasa chýba, tunel sa zrúti, len čo sa nadviaže.

Rýchle porovnanie tej transportnej cesty pred pripojením a po ňom stojí za tých desať sekúnd. ip -4 route get 203.0.113.10 má v oboch stavoch uviesť zariadenie spodnej vrstvy, mení sa len metrika. Ak po zdvihnutí tunela uvádza tun0, hostiteľská trasa nebola nikdy nainštalovaná a ďalšie opätovné pripojenie zlyhá.

Keď majú tunelom prejsť len vybrané prefixy, použite route-nopull a pridajte požadované trasy ručne, alebo zo servera pošlite užší súbor. Most si v takom návrhu ponechá predvolenú trasu a DNS sa stáva ďalším rozhodnutím: preposielanie dnsmasq do domáceho resolvera má zmysel len pre názvy, ktoré tam naozaj žijú.

Rozhodnite o preposielaní a NAT

Plný tunel potrebuje zapnuté preposielanie na Pi a bránu na vzdialenej strane ochotnú smerovať podsieť prístupového bodu. Skontrolujte preposielanie predovšetkým iným, pretože nula robí každú zmenu 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 skratka, ktorá funguje, keď server neprijme prefix prístupového bodu, za cenu toho, že každý klient bude v protokoloch vzdialenej strany vyzerať ako tunelová adresa Pi. Smerovanie prefixu bez NAT udržiava adresy viditeľné a závisí od spätnej trasy pre 192.168.50.0/24 na domácej strane.

Zapíšte voľbu vedľa pravidiel firewallu, pretože pravidlo NAT neviditeľné v návrhu sa po šiestich mesiacoch stane nevysvetliteľným. Držte IPv6 v tom istom rozhodnutí; funkčná cesta IPv4 vedľa pokazenej cesty IPv6 sa v prehliadači stále číta ako napoly pokazená.

Overte z klienta a potom sa čisto vráťte

Testujte v tomto poradí z telefónu alebo notebooku na prístupovom bode: prenájom z dnsmasq, ping na adresu mosta, potom cieľ na vzdialenej strane tunela. Každý krok izoluje jednu vrstvu namiesto toho, aby vytvoril jedinú neužitočnú chybu.

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

Potom potvrďte, že Pi má stále vlastnú cestu von: ip route get 203.0.113.10 má uviesť zariadenie spodnej vrstvy a ping -c 3 -I br0 203.0.113.10 má odpovedať, ak server povoľuje ICMP. Ak prvé dva kroky klienta prejdú a tretí zlyhá, chyba je v preposielaní alebo NAT. Ak zlyhá druhý krok, most alebo DHCP stále nie sú úplné.

Vrátenie je jedna úprava súboru a dva príkazy: odstráňte blok, reštartujte dhcpcd a nahraďte predvolenú trasu výslovne pomocou ip route replace default via 192.168.50.1 dev br0. Urobte to pred zatvorením okna údržby, nie po ňom, pretože Pi, ktorý stratil predvolenú trasu, je nedostupný zo siete, ktorú by ste použili na jeho opravu.

Súvisiace články