Clienții hotspot de pe un Pi nu ajung în LAN-ul de acasă printr-un VPN TUN

Clienții locali Wi-Fi și Ethernet se conectează la hotspotul Pi-ului, iau o adresă din intervalul DHCP al acestuia și încarcă pagini de internet fără reclamații. Aceiași clienți ajung apoi în timeout când deschid o partajare de fișiere sau o interfață web în LAN-ul de acasă, în timp ce Pi-ul însuși ajunge în acel LAN prin tunel. Nimic din stratul wireless nu este stricat. Ce lipsește este un contract rutat: prefixul hotspotului trebuie dus în interfața TUN, iar ceva din partea casei trebuie să știe cum să trimită răspunsurile înapoi. Ambele jumătăți trebuie să existe înainte ca un singur pachet să poată încheia drumul dus-întors.

Trei atașamente cu trei sarcini diferite

Un bridge Ethernet Linux transmite cadrele după adresa MAC de destinație. OpenVPN în modul TUN transportă pachete IP și nu are deloc strat MAC, așa că adăugarea unui bridge local nu înregistrează niciodată tunelul ca port. documentația kernelului despre TUN/TAP explică această separare: un dispozitiv TAP arată ca o interfață Ethernet, un dispozitiv TUN nu. Un design care puntează două porturi locale și apoi rutează este un router, orice ar spune numele interfețelor.

Această distincție decide proprietatea. Subrețeaua clienților, gateway-ul lor implicit și autoritatea DHCP pentru acel interval aparțin planului local al Pi-ului. Difuziunile DHCP de acasă nu traversează un tunel rutat, iar nicio setare de bridge nu schimbă asta; direcționarea clienților către un server DHCP de acasă este un design de relay separat și deliberat, cu propriile moduri de eșec.

Ține și modemul în afara bridge-ului clienților. O conexiune PPP nu este un dispozitiv Ethernet cu altă etichetă, iar logica documentată de rută implicită a pppd rulează după negocierea IPCP și își retrage ruta când acel link cade. Copierea unui șablon DHCP și redenumirea fiecărui usb0 în ppp0 nu demonstrează nimic despre gateway, metrică sau ciclu de viață.

Alege prefixele înainte de a edita orice configurație

Prefixele suprapuse pierd mai multe seri decât regulile de firewall, pentru că o suprapunere trimite căutarea rutei către interfața greșită chiar și când tunelul este sănătos. Începe prin a lista ce există deja pe Pi, apoi citește rezultatul ca patru bazine separate.

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

Primul bazin este adresa underlay pe care operatorul a dat-o modemului; trebuie să rămână în afara oricărui plan orientat spre clienți. Al doilea este subrețeaua tunelului aleasă de server, adesea un /24 privat al său. Al treilea este bridge-ul hotspotului, iar al patrulea este prefixul de acasă pe care vrei să-l atingi. În acest parcurs hotspotul primește 172.28.90.0/24 cu bridge-ul pe 172.28.90.1, iar LAN-ul de servicii de acasă păstrează 192.168.77.0/24, ceea ce evită valorile implicite 192.168.1.0/24 și 10.0.0.0/24 livrate de routerele de consum și intervalul de operator 100.64.0.0/10.

Anunță adresa bridge-ului ca gateway în intervalul DHCP al hotspotului și nimic altceva. Nu da niciodată clienților hotspot o adresă de acasă ca gateway; nu au cale la nivel de legătură către acel segment.

Rutează fiecare direcție pe partea care o deține

Pi-ul are nevoie de o rută către prefixul de acasă prin tunel. Serverele în modul server împing de obicei acea rută, așa că mai întâi confirmă că forwardingul este pornit și că kernelul rezolvă o adresă de acasă din tun0.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

Dacă ip route get încă raportează interfața underlay, oprește-te acolo; nimic mai departe pe cale nu poate repara o căutare greșită.

Dispozitivele de acasă nu au rută către 172.28.90.0/24, așa că răspunsurile lor urmează gateway-ul implicit și mor la router. Există două reparații acceptate. Fie adaugi o rută statică pe routerul de acasă care îndreaptă prefixul hotspotului către adresa LAN a serverului VPN, fie, când serverul este el însuși gateway-ul, înregistrezi prefixul clientului în tabela de rutare proprie a serverului. În modul multi-client al OpenVPN directorul specific clientului poartă acea asociere: un fișier numit după numele comun al certificatului clientului, care conține iroute 172.28.90.0 255.255.255.0 plus linia route corespunzătoare care îl instalează în kernelul serverului. O rută de kernel ghicită pe server nu este aceeași afirmație ca a spune serverului care client deține prefixul.

Nu muta serviciul DHCP al rețelei de acasă pe serverul VPN pentru ca asta să funcționeze. Înlocuirea gateway-ului implicit pentru o casă întreagă este o schimbare mult mai mare decât adăugarea unei rute de întoarcere private, iar asta târăște DNS, rezervările de adrese și fiecare dispozitiv care ignoră noul lease în eșec.

Deschide forwardingul fără să ghicești firewallul

Forwardingul pornit nu înseamnă că pachetul are voie să treacă. Traficul de la bridge la tunel lovește în continuare regulile de filtrare, iar o politică implicită de forwarding drop aruncă traficul hotspotului în timp ce traficul propriu al Pi-ului continuă să funcționeze, ceea ce produce exact simptomul divizat de mai sus.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

Caută o regulă de acceptare de la br0 la tun0 și direcția de răspuns corespunzătoare, și o regulă postrouting care poate rescrie sursa. Dacă politica lanțului este drop și nicio regulă nu se potrivește, adaugă acceptările înguste și testează din nou în loc să întorci politica în accept.

Traducerea este o alegere de politică, nu o cerință. NAT-ul de sursă spre LAN-ul de acasă face fiecare client hotspot să arate ca adresa tunelului Pi-ului, ceea ce pierde atribuirea pe client în jurnalele de acasă și rupe serviciile care așteaptă sursa originală. Rutarea fără NAT ține adresele clienților vizibile dar depinde de ruta de întoarcere de mai sus. Alege una și tratează DNS și IPv6 la fel, pentru că o cale IPv4 funcțională lângă o cale IPv6 stricată se citește în continuare ca pe jumătate stricată în browser.

Verifică drumul dus-întors, apoi strică-l intenționat

Testează de pe un client hotspot, niciodată de pe Pi, pentru că traficul propriu al Pi-ului ocolește atât calea înainte, cât și calea de întoarcere. Observă ambele interfețe în timp ce un client încearcă să atingă un serviciu de acasă.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

Citește cele două capturi împreună. Cererile pe br0 care nu apar niciodată pe tun0 înseamnă că Pi-ul nu face forwarding sau că ruta indică în altă parte. Cererile pe tun0 fără răspunsuri înseamnă că partea de acasă nu are rută de întoarcere sau că serverul a filtrat pachetul. Răspunsurile pe tun0 care nu reapar niciodată pe br0 înseamnă că lipsește regula de filtrare inversă, unde tunelul pare perfect și clientul tot nu vede nimic.

Apoi strică calea deliberat. Oprește conexiunea modemului și pornește-o din nou și rulează din nou verificările de rută și captură; o rută care supraviețuiește tunelului dar dispare la reconectare aparține profilului de conexiune, nu unei comenzi unice. Confirmă că transportul tunelului iese în continuare prin underlay și nu prin el însuși, bucla clasică atunci când o rută implicită împinsă este acceptată fără o rută de host către peer.

Acceptă designul doar când un client hotspot poate rezolva un nume de acasă, deschide un serviciu TCP și ține o sesiune vie pe parcursul unei reconectări a modemului. Dacă o aplicație chiar are nevoie de descoperire la nivel Ethernet în segmentul de acasă, alege un design Layer 2 acceptat în loc să descrii bridge-ul local ca punte și să aștepți să apară difuziunea.