hostapd și OpenVPN pe un singur Pi: al cui este traseul implicit?

hostapd și un client OpenVPN pot partaja un Pi când bridge-ul își păstrează propriul traseu implicit, iar tunelul păstrează o cale către serverul său. Comenzi și revenire.

Telefoanele se asociază cu punctul de acces, primesc o adresă și apoi nu mai ajung nicăieri de îndată ce tunelul urcă. hostapd este de obicei sănătos în acea stare, și OpenVPN la fel; ceea ce se rupe este traseul implicit, care fie nu a existat niciodată pe bridge, fie a fost înlocuit de tunel fără a lăsa o cale către serverul VPN însuși. Acest ghid pune traseul înapoi la locul lui și dovedește rezultatul dintr-un client, nu din Pi. Fiecare pas este reversibil, și nimic aici nu schimbă configurația tunelului până când nu știți ce trafic vreți în interiorul lui.

Inventariați interfețele înainte de a edita ceva

Aspectul familiar pune radioul wireless și portul cu fir în br0, pornește hostapd împotriva bridge-ului și distribuie închirieri din dnsmasq, în timp ce un client OpenVPN creează tun0. Atunci trei cerințe separate par una singură: clienții punctului de acces au nevoie de Pi ca gateway al lor, Pi are nevoie de o rută către internet pentru a-și atinge serverul, iar bridge-ul are nevoie de o adresă de gateway pe care acei clienți o pot folosi.

Citiți starea actuală înainte de a o schimba, pentru că aceste patru comenzi separă o problemă de interfață de o problemă de rutare.

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

Dacă br0 are o adresă dar niciun traseu implicit, clienții ajung la Pi și la nimic dincolo de el. Dacă traseul implicit indică spre tun0 în timp ce tunelul este jos, Pi nu are nicio cale funcțională, iar simptomul clientului arată exact la fel. Ambele cazuri arată identic de pe un telefon, de aceea tabelul de rutare trebuie citit direct.

Dați bridge-ului un traseu implicit care îi aparține

Raspberry Pi OS lasă adesea bridge-ul fără traseu implicit atunci când bridge-ul a apărut după ce fișierul de interfață a fost scris. Blocul aparține în /etc/dhcpcd.conf și ar trebui să numească routerul din amonte, nu 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

În acel exemplu 192.168.50.1 este routerul existent, iar 192.168.50.2 este adresa de bridge a Pi în aceeași subrețea, așa că înlocuiți cu propriul plan în loc să copiați numerele. Membrii bridge-ului nu trebuie nici ei să ceară routere, altfel Pi rămâne cu trasee implicite concurente al căror câștigător depinde de metrică și de moment, nu de intenție.

După systemctl restart dhcpcd, ip route show default ar trebui să listeze br0 o dată și niciun duplicat de la portul cu fir. Confirmați căutarea, nu tabelul, pentru că o intrare veche poate sta lângă una câștigătoare: ip -4 route get 203.0.113.10 trebuie să numească br0. Acea adresă provine din intervalul de documentare TEST-NET-3, așa că nu poate intra în conflict cu un server real cât timp citiți asta.

Opriți tunelul să răpească calea către propriul server

Un client OpenVPN care acceptă redirect-gateway preia traseul implicit și îl îndreaptă în tunel. Asta este corect când fiecare client al punctului de acces ar trebui să folosească VPN-ul, și greșit când doar unele destinații ar trebui. În orice caz, conexiunea proprie a Pi la server nu trebuie să călătorească în interiorul tunelului pe care încă îl construiește. OpenVPN adaugă o rută de host către cel îndepărtat prin gateway-ul original când redirecționează traseul implicit, și exact acesta este comportamentul care ține transportul viu; dacă acea rută lipsește, tunelul se prăbușește de îndată ce se stabilește.

O comparație rapidă a acelei căi de transport înainte și după conectare merită acele zece secunde. ip -4 route get 203.0.113.10 ar trebui să numească dispozitivul de sub nivel în ambele stări, doar metrica se schimbă. Dacă numește tun0 după ce tunelul urcă, ruta de host nu a fost niciodată instalată și următoarea reconectare va eșua.

Când doar prefixe selectate ar trebui să traverseze tunelul, folosiți route-nopull și adăugați manual rutele dorite, sau trimiteți un set mai îngust de la server. Bridge-ul păstrează traseul implicit în acel design, iar DNS devine următoarea decizie: forwardarea dnsmasq către un resolver de acasă are sens doar pentru numele care chiar locuiesc acolo.

Decideți povestea forwardării și a NAT-ului

Un tunel complet necesită forwardare activată pe Pi și un gateway în partea cealaltă dispus să ruteze subrețeaua punctului de acces. Verificați forwardarea înainte de orice altceva, pentru că un zero face orice schimbare de rută irelevantă.

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

Regula NAT este scurtătura care funcționează când serverul nu va accepta prefixul punctului de acces, cu prețul ca fiecare client să apară ca adresa de tunel a Pi în jurnalele din partea cealaltă. Rutarea prefixului fără NAT păstrează adresele vizibile și depinde de o rută de întoarcere pentru 192.168.50.0/24 în partea de acasă.

Notați alegerea lângă regulile de firewall, pentru că o regulă NAT invizibilă în proiect devine inexplicabilă șase luni mai târziu. Țineți IPv6 în aceeași decizie; o cale IPv4 funcțională lângă o cale IPv6 stricată se citește în continuare ca pe jumătate stricată într-un browser.

Verificați dintr-un client, apoi reveniți curat

Testați în această ordine de pe un telefon sau laptop la punctul de acces: o închiriere de la dnsmasq, un ping către adresa bridge-ului, apoi o destinație în partea cealaltă a tunelului. Fiecare pas izolează un strat în loc să producă o singură defecțiune inutilă.

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

Apoi confirmați că Pi are încă propria ieșire: ip route get 203.0.113.10 ar trebui să numească dispozitivul de sub nivel, iar ping -c 3 -I br0 203.0.113.10 ar trebui să răspundă dacă serverul permite ICMP. Dacă primele două pasuri ale clientului trec și al treilea eșuează, defecțiunea este în forwardare sau în NAT. Dacă al doilea pas eșuează, bridge-ul sau DHCP sunt încă incomplete.

Revenirea este o editare de fișier și două comenzi: eliminați blocul, reporniți dhcpcd și înlocuiți traseul implicit explicit cu ip route replace default via 192.168.50.1 dev br0. Faceți asta înainte de închiderea ferestrei de mentenanță și nu după, pentru că un Pi care a pierdut traseul implicit este inaccesibil din rețeaua pe care ați folosi-o pentru a-l repara.

Articole similare