Hotspotklientar på ein Pi når ikkje heime-LAN-et over ein TUN-VPN

Lokale Wi-Fi- og Ethernet-klientar koplar seg til hotspoten på Pi-en, hentar ei adresse frå DHCP-området hans og lastar nettsider utan klager. Dei same klientane får deretter tidsavbrot når dei opnar ei fildeling eller eit webgrensesnitt på heime-LAN-et, medan Pi-en sjølv når det LAN-et gjennom tunnelen. Ingenting i det trådlause laget er øydelagt. Det som manglar, er ein ruta kontrakt: hotspot-prefikset må berast inn i TUN-grensesnittet, og noko på heimesida må vita korleis svar skal sendast tilbake dit. Begge halvdelane må finnast før ein einaste pakke kan fullføre rundturen.

Tre tilkoplingar med tre ulike jobbar

Ei Linux Ethernet-bru videresender rammer etter mål-MAC-adresse. OpenVPN i TUN-modus ber IP-pakkar og har ikkje noko MAC-lag i det heile, så å leggje til ei lokal bru registrerer aldri tunnelen som port. kjernedokumentasjonen for TUN/TAP forklarar den delinga: ei TAP-eining ser ut som eit Ethernet-grensesnitt, ei TUN-eining gjer det ikkje. Eit design som bruar to lokale portar og deretter rutar, er ein ruttar, kva grensesnittnamna enn seier.

Den skilnaden avgjer eigarskapet. Subnettet til klientane, standardgatewayen deira og DHCP-myndet for det området høyrer til den lokale planen til Pi-en. Heime-DHCP-kringkastingar kryssar ikkje ein ruta tunnel, og ingen bruinnstilling endrar det; å peike klientane mot ein heime-DHCP-tenar er eit separat, medvite relaydesign med sine eigne feilmodus.

Hald òg modemet utanfor klientbrua. Ei PPP-tilkopling er ikkje ei Ethernet-eining med ei anna etikett, og den dokumenterte standardruttelogikken til pppd køyrer etter IPCP-forhandlinga og dreg ruta si tilbake når den lenkja fell. Å kopiere ein DHCP-mal og gje kvar usb0 nytt namn til ppp0 provar ingenting om gateway, metrikk eller livssyklus.

Vel prefiksa før du redigerer noko konfigurasjon

Overlappande prefiks kostar fleire kveldar enn brannmurreglar, fordi ein overlapping sender ruteoppslaget til feil grensesnitt sjølv når tunnelen er sunn. Byrja med å liste opp det som allereie finst på Pi-en, og les deretter resultatet som fire separate basseng.

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-adressa operatøren gav modemet; ho må haldast utanfor kvar klientvend plan. Det andre er subnettet til tunnelen som tenaren valde, ofte eit eige privat /24-nett. Det tredje er hotspot-brua, og det fjerde er heimeprefikset du vil nå. I denne gjennomgangen får hotspoten 172.28.90.0/24 med brua på 172.28.90.1, og heimeteneste-LAN-et held på 192.168.77.0/24, noko som unngår standardane 192.168.1.0/24 og 10.0.0.0/24 som forbrukarruttarar kjem med, og operatørområdet 100.64.0.0/10.

Annonser adressa til brua som gateway i DHCP-området til hotspoten og ingenting anna. Gje aldri hotspotklientar ei heimeadresse som gateway; dei har ingen sti på lenkjelaget til det segmentet.

Rut kvar retning på sida som eig henne

Pi-en treng ei rute til heimeprefikset gjennom tunnelen. Tenarar i tenarmodus skyv vanlegvis den ruta, så stadfest først at videresending er på og at kjernen løyser ei heimeadresse 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

Viss ip route get framleis rapporterer underlay-grensesnittet, stopp der; ingenting lenger framme på stien kan reparere eit feil oppslag.

Heimeeiningar har inga rute til 172.28.90.0/24, så svara deira følgjer standardgatewayen og døyr ved ruttaren. Det finst to støtta reparasjonar. Anten legg til ei statisk rute på heimeruttaren som peikar hotspot-prefikset mot LAN-adressa til VPN-tenaren, eller, når tenaren sjølv er gatewayen, registrer klientprefikset i rutetabellen til tenaren sjølv. I fleirklientmodusen til OpenVPN ber den klientspesifikke mappa den assosiasjonen: ei fil kalla opp etter common name til klientcertifikatet, som inneheld iroute 172.28.90.0 255.255.255.0 pluss den samsvarande route-linja som installerar henne i tenarkjernen. Ei gissa kjernerute på tenaren er ikkje same utsegn som å fortelje tenaren kva klient som eig prefikset.

Ikkje flytt DHCP-tenesta for heimenettet over til VPN-tenaren for å få dette til å verke. Å byte ut standardgatewayen for eit heilt hus er ei langt større endring enn å leggje til éi privat returrute, og det dreg DNS, adressereservasjonar og kvar eining som ignorerer den nye leiga inn i feilen.

Opne videresending utan å gisse på brannmuren

At videresending er slått på tyder ikkje at pakken får passere. Trafikk frå brua til tunnelen treffer framleis filterreglane, og ein standard-drop-videresendingspolicy slepper hotspot-trafikk medan eigen trafikk frå Pi-en held fram med å verke, noko som gjev nøyaktig det delte symptomet ovanfor.

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

Sjå etter ein accept-regel frå br0 til tun0 og den samsvarande svarretninga, og ein postrouting-regel som kan skrive om kjelda. Viss kjernepolicyen er drop og ingen regel passar, legg til dei smale acceptane og test på nytt i staden for å snu policyen til accept.

Omsetjing er eit policyval, ikkje eit krav. Source-NAT mot heime-LAN-et får kvar hotspotklient til å sjå ut som tunneladressa til Pi-en, noko som mistar per-klient-tilskriving i heimeloggar og bryt tenester som ventar den opphavlege kjelda. Ruting utan NAT held klientadresser synlege, men er avhengig av returruta ovanfor. Vel éin, og handsam DNS og IPv6 på same måte, fordi ein fungerande IPv4-sti ved sida av ein øydelagd IPv6-sti framleis blir lesen som halvt øydelagd i ein nettlesar.

Stadfest rundturen, og bryt han deretter med vilje

Test frå ein hotspotklient, aldri frå Pi-en, fordi eigen trafikk frå Pi-en går utanom både fram- og returvegen. Følg med på begge grensesnitta medan éin klient prøver å nå ei heimeteneste.

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

Les dei to opptaka saman. Førespurnader på br0 som aldri dukkar opp på tun0, tyder at Pi-en ikkje videresender, eller at ruta peikar ein annan stad. Førespurnader på tun0 utan svar tyder at heimesida ikkje har noka returrute, eller at tenaren filtrerte pakken. Svar på tun0 som aldri dukkar opp att på br0, tyder at den omvende filterregelen manglar, der tunnelen ser perfekt ut og klienten framleis ikkje ser noko.

Bryt deretter stien med vilje. Ta modemtilkoplinga ned og opp att, og køyr rute- og opptakskontrollane på nytt; ei rute som overlever tunnelen, men forsvinn ved gjenoppkopling, høyrer i tilkoplingsprofilen, ikkje i ein eingongskommando. Stadfest at transporten til tunnelen framleis går ut gjennom underlay og ikkje gjennom seg sjølv, den klassiske løkka når ei påskuve rute utan vertsrute til peeren blir godteken.

Godta designet berre når ein hotspotklient kan slå opp eit heimenamn, opne ei TCP-teneste og halde ein økt i live gjennom éi modempålogging. Viss ein applikasjon verkeleg krev Ethernet-nivå-oppdaging på heimesegmentet, vel eit støtta Layer 2-design i staden for å skildre den lokale brua som brua og vente på at kringkasting skal dukke opp.