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

Lokale Wi-Fi- og Ethernet-klienter kobler seg til Pi-ens hotspot, henter en adresse fra DHCP-området og laster nettsider uten klager. De samme klientene får deretter tidsavbrudd når de åpner en fildeling eller et webgrensesnitt på hjemme-LAN-et, mens Pi-en selv når det LAN-et gjennom tunnelen. Ingenting i det trådløse laget er ødelagt. Det som mangler, er en rutet kontrakt: hotspot-prefikset må bæres inn i TUN-grensesnittet, og noe på hjemmesiden må vite hvordan svar sendes tilbake dit. Begge halvdeler må finnes før én enkelt pakke kan fullføre rundturen.

Tre tilkoblinger med tre forskjellige jobber

En Linux Ethernet-bro videresender rammer etter mål-MAC-adresse. OpenVPN i TUN-modus bærer IP-pakker og har ikke noe MAC-lag i det hele tatt, så å legge til en lokal bro registrerer aldri tunnelen som port. kjernens TUN/TAP-dokumentasjon forklarer den delingen: en TAP-enhet ser ut som et Ethernet-grensesnitt, en TUN-enhet gjør ikke. Et design som broer to lokale porter og deretter ruter, er en ruter, uansett hva grensesnittnavnene sier.

Den forskjellen avgjør eierskapet. Klientenes subnett, standardgatewayen deres og DHCP-autoriteten for det området tilhører Pi-ens lokale plan. Hjemme-DHCP-kringkastinger krysser ikke en rutet tunnel, og ingen broinnstilling endrer det; å peke klientene mot en hjemme-DHCP-server er et separat, bevisst relaydesign med sine egne feilmoduser.

Hold også modemet utenfor klientbroen. En PPP-tilkobling er ikke en Ethernet-enhet med en annen etikett, og pppd sin dokumenterte standardrute-logikk kjører etter IPCP-forhandlingen og trekker ruten tilbake når den lenken faller. Å kopiere en DHCP-mal og gi hver usb0 nytt navn til ppp0 beviser ingenting om gateway, metrikk eller livssyklus.

Velg prefiksene før du redigerer noen konfigurasjon

Overlappende prefikser koster flere kvelder enn brannmurregler, fordi en overlapping sender ruteoppslaget til feil grensesnitt selv når tunnelen er sunn. Start med å liste opp hva som allerede finnes på Pi-en, og les deretter resultatet som fire separate bassenger.

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

Det første bassenget er underlay-adressen operatøren ga modemet; den må holdes utenfor enhver klientvendt plan. Det andre er tunnelens subnett som serveren valgte, ofte et eget privat /24-nett. Det tredje er hotspot-broen, og det fjerde er hjemmeprefikset du vil nå. I denne gjennomgangen får hotspottet 172.28.90.0/24 med broen på 172.28.90.1, og hjemmetjeneste-LAN-et beholder 192.168.77.0/24, noe som unngår standardene 192.168.1.0/24 og 10.0.0.0/24 som forbrukerrutere leveres med, og operatørområdet 100.64.0.0/10.

Annonser broens adresse som gateway i hotspotens DHCP-område og ingenting annet. Gi aldri hotspotklienter en hjemmeadresse som gateway; de har ingen sti på lenkelaget til det segmentet.

Rut hver retning på siden som eier den

Pi-en trenger en rute til hjemmeprefikset gjennom tunnelen. Servere i servermodus skyver vanligvis den ruten, så bekreft først at videresending er på og at kjernen løser en hjemmeadresse ut av 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 fortsatt rapporterer underlay-grensesnittet, stopp der; ingenting lenger fremme på stien kan reparere et feil oppslag.

Hjemmeenheter har ingen rute til 172.28.90.0/24, så svarene deres følger standardgatewayen og dør ved ruteren. Det finnes to støttede reparasjoner. Enten legg til en statisk rute på hjemmeruteren som peker hotspot-prefikset mot VPN-serverens LAN-adresse, eller, når serveren selv er gatewayen, registrer klientprefikset i serverens egen rutetabell. I OpenVPN sin flerklientmodus bærer den klientspesifikke mappen den assosiasjonen: en fil oppkalt etter klientcertifikatets common name, som inneholder iroute 172.28.90.0 255.255.255.0 pluss den samsvarende route-linjen som installerer den i serverkjernen. En gjettet kjernerute på serveren er ikke samme utsagn som å fortelle serveren hvilken klient som eier prefikset.

Ikke flytt DHCP-tjenesten for hjemmenettet over til VPN-serveren for å få dette til å virke. Å erstatte standardgatewayen for et helt hus er en langt større endring enn å legge til én privat returrute, og det drar DNS, adressereservasjoner og hver enhet som ignorerer den nye leien, inn i feilen.

Åpne videresending uten å gjette på brannmuren

At videresending er slått på betyr ikke at pakken får passere. Trafikk fra broen til tunnelen treffer fortsatt filterreglene, og en standard-drop-videresendingspolicy slipper hotspot-trafikk mens Pi-ens egen trafikk fortsetter å virke, noe som gir nøyaktig det delte symptomet ovenfor.

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

Se etter en accept-regel fra br0 til tun0 og den samsvarende svarretningen, og en postrouting-regel som kan skrive om kilden. Hvis kjedepolicyen er drop og ingen regel passer, legg til de smale acceptene og test på nytt i stedet for å snu policyen til accept.

Oversettelse er et policyvalg, ikke et krav. Source-NAT mot hjemme-LAN-et får hver hotspotklient til å se ut som Pi-ens tunneladresse, noe som mister per-klient-attribusjon i hjemmelogger og bryter tjenester som forventer den opprinnelige kilden. Ruting uten NAT holder klientadresser synlige, men avhenger av returruten ovenfor. Velg én, og håndter DNS og IPv6 på samme måte, fordi en fungerende IPv4-sti ved siden av en ødelagt IPv6-sti fortsatt leses som halvt ødelagt i en nettleser.

Bekreft rundturen, og bryt den deretter med vilje

Test fra en hotspotklient, aldri fra Pi-en, fordi Pi-ens egen trafikk omgår både frem- og returveien. Overvåk begge grensesnittene mens én klient prøver å 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

Les de to opptakene sammen. Forespørsler på br0 som aldri dukker opp på tun0, betyr at Pi-en ikke videresender, eller at ruten peker et annet sted. Forespørsler på tun0 uten svar betyr at hjemmesiden ikke har noen returrute, eller at serveren filtrerte pakken. Svar på tun0 som aldri dukker opp igjen på br0, betyr at den omvendte filterregelen mangler, der tunnelen ser perfekt ut og klienten fortsatt ikke ser noe.

Bryt deretter stien med vilje. Ta modemforbindelsen ned og opp igjen, og kjør rute- og opptakskontrollene på nytt; en rute som overlever tunnelen, men forsvinner ved gjenoppkobling, hører i tilkoblingsprofilen, ikke i en engangskommando. Bekreft at tunnelens transport fortsatt går ut gjennom underlay og ikke gjennom seg selv, den klassiske løkken når en skjøvet standardrute godtas uten en vertsrute til peeren.

Godta designet bare når en hotspotklient kan slå opp et hjemmenavn, åpne en TCP-tjeneste og holde en økt i live gjennom én modempålogging. Hvis en applikasjon virkelig krever Ethernet-nivå-oppdagelse på hjemmesegmentet, velg et støttet Layer 2-design i stedet for å beskrive den lokale broen som broet og vente på at kringkasting skal dukke opp.