Telefonul din hotspotul dumneavoastră punte își primește adresa și gateway-ul de undeva, iar aceasta nu este ruta implicită a Pi. Schimbarea rutei implicite a Pi schimbă unde trimite Pi propriul trafic. Telefonul continuă să folosească gateway-ul care i-a fost comunicat, iar când acel gateway se află în LAN-ul îndepărtat, cadrele sale traversează pur și simplu puntea. Doi consumatori, două decizii. Separarea lor explică majoritatea rapoartelor despre un hotspot fără internet în timp ce Pi însuși este în regulă.

Două dispozitive, două decizii diferite privind gateway-ul

Pi are propriul stivă IP și propria rută implicită. Telefonul are propriul stivă IP și propria rută implicită.

ConsumerWho chooses its gatewayWhat carries the traffic
Phone on the bridged APThe remote LAN router, delivered in its client configurationAn Ethernet frame toward that router crosses the AP and TAP bridge
Pi's encrypted connectionThe travel uplink's route toward the VPN peerThe Pi sends its own outer transport packets over the underlay

Acest tabel este întregul model. Gateway-ul telefonului este o adresă din LAN-ul îndepărtat, iar cadrele sale sunt transmise la nivelul 2 către acel router. Ruta implicită a Pi privește transportul său exterior propriu, care trebuie să ajungă la partenerul VPN prin uplink-ul de călătorie.

O punte transmite cadre, nu rutează pachete

O punte Linux transmite cadre Ethernet după MAC-ul destinației, și este tot ce face între porturile sale. Cadrul telefonului adresat MAC-ului routerului îndepărtat este comutat pe portul TAP și traversează tunelul fără să atingă tabela de rutare a Pi. De aceea o rută implicită defectă a Pi poate lăsa telefonul funcțional, și de aceea una corectă nu poate repara un telefon căruia i s-a dat gateway-ul greșit.

TAP transportă cadre Ethernet și poate fi port de punte. TUN transportă pachete IP și nu poate. Dacă designul dumneavoastră a înlocuit unul cu celălalt, puntea nu este o punte și restul nu se aplică.

Decideți cine distribuie lease-ul telefonului

Opțiunea 3 DHCP este opțiunea de router și îi spune clientului ce gateway să folosească pentru subrețeaua sa. Când serverul DHCP din LAN-ul îndepărtat este singurul distribuitor, telefonul primește un gateway îndepărtat și designul este consecvent. Când altceva din partea de călătorie răspunde primul, telefonul primește un gateway local, traficul său de internet iese prin uplink-ul de călătorie, iar traficul său către LAN-ul îndepărtat nu are niciun drum.

Rulați un singur distribuitor pentru acel domeniu de difuzare și notați ce distribuie.

Pi este un caz separat chiar și când ia o adresă din același lease. Decideți deliberat dacă trebuie să instaleze rutele oferite de lease, deoarece o rută implicită îndepărtată importată poate trage transportul VPN propriu al Pi în tunelul pe care încearcă să îl țină în viață. Cu systemd-networkd acea decizie este UseRoutes= în secțiunea DHCP; cu dhclient este opțiunea routers din lista de cereri.

Țineți uplink-ul în afara LAN-ului punte

Interfața care transportă conexiunea VPN exterioară a Pi nu trebuie să devină port de punte. Dacă devine, transportul criptat este comutat în LAN-ul extins și tunelul ajunge să transporte propriile pachete exterioare, ceea ce eșuează într-un mod care arată ca pierdere de pachete, nu ca o buclă. Păstrați explicite și capacitatea AP și suportul de punte. O interfață wireless în modul station nu poate fi de obicei port de punte, deoarece antetul 802.11 nu are loc pentru a doua adresă MAC de care are nevoie o punte.

Definiți domeniul de difuzare extins, un plan de adrese și filtrarea cadrelor pe care o doriți cu adevărat. Permiterea ascultătorului VPN pe Pi nu acordă fiecărui client punte acces la serviciile de administrare ale Pi. Acestea sunt reguli separate, iar tratarea lor ca una singură este modul în care un hotspot devine în liniște o ușă deschisă.

Testați cele patru separat când se strică

Când telefonul nu poate ajunge la LAN-ul îndepărtat, patru observații separă cauzele. Rulați-le în această ordine și opriți-vă la prima care eșuează.

ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmp

Începeți cu lease-ul: are telefonul o adresă și un gateway în subrețeaua îndepărtată? Apoi priviți puntea și confirmați că portul AP și portul TAP ambele transmit. Apoi citiți tabela de vecini, deoarece o intrare nerezolvată pentru routerul îndepărtat înseamnă că cadrele pleacă și nimic nu răspunde. În final observați cadrele pe punte în timp ce telefonul face ping, ceea ce vă spune dacă defectul este sub IP sau nu.

Notați ce dispozitiv deține fiecare rută implicită când terminați. O linie de documentație transformă ieșirea locală versus cea îndepărtată într-o decizie conștientă a clientului, iar referința punții merită păstrată alături.

Articole similare