Hotspotklienter på en Pi kan ikke nå hjemme-LAN'et over en TUN-VPN

Lokale Wi-Fi- og Ethernet-klienter tilslutter sig Pi'ens hotspot, henter en adresse fra dens DHCP-område og indlæser internetsider uden klager. De samme klienter får derefter timeout, når de åbner en fildeling eller en webgrænseflade på hjemme-LAN'et, mens Pi'en selv når det LAN gennem tunnelen. Intet i det trådløse lag er i stykker. Det, der mangler, er en rutet kontrakt: hotspot-præfikset skal bæres ind i TUN-grænsefladen, og noget på hjemmesiden skal vide, hvordan svar sendes tilbage til det. Begge halvdele skal findes, før en enkelt pakke kan fuldføre turen frem og tilbage.

Tre tilslutninger med tre forskellige opgaver

En Linux Ethernet-bro videresender rammer efter destinations-MAC-adresse. OpenVPN i TUN-tilstand bærer IP-pakker og har slet ikke noget MAC-lag, så tilføjelse af en lokal bro registrerer aldrig tunnelen som port. kernens TUN/TAP-dokumentation forklarer den opdeling: en TAP-enhed ligner en Ethernet-grænseflade, en TUN-enhed gør ikke. Et design, der broer to lokale porte og derefter router, er en router, uanset hvad grænsefladenavnene siger.

Den forskel afgør ejerskabet. Klienternes undernet, deres standardgateway og DHCP-autoriteten for det område tilhører Pi'ens lokale plan. Hjemme-DHCP-broadcasts krydser ikke en rutet tunnel, og ingen broindstilling ændrer det; at pege klienterne mod en hjemme-DHCP-server er et separat, bevidst relaydesign med sine egne fejltilstande.

Hold også modemet uden for klientbroen. En PPP-tilslutning er ikke en Ethernet-enhed med en anden etiket, og pppd's dokumenterede standardrute-logik kører efter IPCP-forhandling og trækker sin rute tilbage, når det link falder. At kopiere en DHCP-skabelon og omdøbe hver usb0 til ppp0 beviser intet om gateway, metrik eller livscyklus.

Vælg præfikserne, før du redigerer nogen konfiguration

Overlappende præfikser spilder flere aftener end firewallregler, fordi et overlap sender ruteopslaget til den forkerte grænseflade, selv når tunnelen er sund. Start med at liste, hvad der allerede findes på Pi'en, og læs derefter resultatet som fire separate puljer.

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

Den første pulje er den underlay-adresse, som operatøren gav modemet; den skal holdes ude af enhver klientvendt plan. Den anden er det tunnelundernet, serveren valgte, ofte et eget privat /24-net. Den tredje er hotspot-broen, og den fjerde er det hjemmepræfiks, du vil nå. I denne gennemgang får hotspottet 172.28.90.0/24 med broen på 172.28.90.1, og hjemmeservice-LAN'et beholder 192.168.77.0/24, hvilket undgår standarderne 192.168.1.0/24 og 10.0.0.0/24, som forbrugerroutere leveres med, og operatørintervallet 100.64.0.0/10.

Annoncér broens adresse som gateway i hotspotens DHCP-område og intet andet. Giv aldrig hotspotklienter en hjemmeadresse som gateway; de har ingen forbindelseslagssti til det segment.

Rut hver retning på den side, der ejer den

Pi'en har brug for en rute til hjemmepræfikset gennem tunnelen. Servere i servertilstand skubber normalt den rute, så bekræft først, at videresendelse er slået til, og at kernen opløser en hjemmeadresse ud af tun0.

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

Hvis ip route get stadig rapporterer underlay-grænsefladen, så stop der; intet længere fremme på stien kan reparere et forkert opslag.

Hjemmeenheder har ingen rute til 172.28.90.0/24, så deres svar følger standardgatewayen og dør ved routeren. Der findes to understøttede reparationer. Enten tilføj en statisk rute på hjemmerouteren, der peger hotspot-præfikset mod VPN-serverens LAN-adresse, eller, når serveren selv er gatewayen, registrer klientpræfikset i serverens egen routingtabel. I OpenVPN's multi-client-tilstand bærer den klientspecifikke mappe den association: en fil opkaldt efter klientcertifikatets common name, som indeholder iroute 172.28.90.0 255.255.255.0 plus den matchende route-linje, der installerer den i serverkernen. En gættet kernelrute på serveren er ikke samme udsagn som at fortælle serveren, hvilken klient der ejer præfikset.

Flyt ikke hjemmenetværkets DHCP-tjeneste over på VPN-serveren for at få dette til at virke. At erstatte standardgatewayen for et helt hus er en langt større ændring end at tilføje én privat returrute, og det trækker DNS, adressereservationer og enhver enhed, der ignorerer den nye lease, med i fejlen.

Åbn videresendelse uden at gætte på firewallen

At videresendelse er aktiveret betyder ikke, at pakken får lov at passere. Trafik fra broen til tunnelen rammer stadig filterreglerne, og en standard-drop-videresendelsespolitik dropper hotspot-trafik, mens Pi'ens egen trafik fortsætter med at virke, hvilket giver præcis det opdelte symptom ovenfor.

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

Se efter en accept-regel fra br0 til tun0 og den matchende svarretning, og efter en postrouting-regel, der kan omskrive kilden. Hvis kædepolitikken er drop, og ingen regel matcher, så tilføj de snævre accepts og test igen i stedet for at vende politikken til accept.

Oversættelse er et politikvalg snarere end et krav. Source NAT mod hjemme-LAN'et får hver hotspotklient til at ligne Pi'ens tunneladresse, hvilket mister per-klient-attribution i hjemmelogs og bryder tjenester, der forventer den oprindelige kilde. Routing uden NAT holder klientadresser synlige, men afhænger af returruten ovenfor. Vælg én, og håndtér DNS og IPv6 på samme måde, fordi en fungerende IPv4-sti ved siden af en brudt IPv6-sti stadig læses som halvt brudt i en browser.

Bekræft turen frem og tilbage, og bryd den derefter med vilje

Test fra en hotspotklient, aldrig fra Pi'en, fordi Pi'ens egen trafik omgår både frem- og returvejen. Overvåg begge grænseflader, mens en klient forsøger at nå en hjemmetjeneste.

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

Læs de to optagelser sammen. Forespørgsler på br0, der aldrig vises på tun0, betyder, at Pi'en ikke videresender, eller at ruten peger andre steder. Forespørgsler på tun0 uden svar betyder, at hjemmesiden ikke har nogen returrute, eller at serveren filtrerede pakken. Svar på tun0, der aldrig dukker op igen på br0, betyder, at den omvendte filterregel mangler, hvor tunnelen ser perfekt ud, og klienten stadig intet ser.

Bryd derefter stien med vilje. Tag modemforbindelsen ned og op igen, og kør rute- og optagelseskontrollerne igen; en rute, der overlever tunnelen, men forsvinder ved genopkobling, hører i forbindelsesprofilen, ikke i en engangskommando. Bekræft, at tunnelens transport stadig forlader gennem underlay og ikke gennem sig selv, den klassiske løkke, når en skubbet standardrute accepteres uden en værtsrute til peer'en.

Accepter kun designet, når en hotspotklient kan opløse et hjemmenavn, åbne en TCP-tjeneste og holde en session i live gennem én modemgenopkobling. Hvis en applikation virkelig kræver Ethernet-niveau-opdagelse på hjemmesegmentet, så vælg et understøttet Layer 2-design i stedet for at beskrive den lokale bro som broet og vente på, at broadcast dukker op.