Hotspot-kliënte op 'n Pi bereik nie die tuis-LAN oor 'n TUN-VPN nie

Plaaslike Wi-Fi- en Ethernet-kliënte koppel aan die Pi se hotspot, trek 'n adres uit sy DHCP-omvang en laai internetblaaie sonder klagte. Dieselfde kliënte hou dan uit wanneer hulle 'n lêerdeling of 'n webkoppelvlak op die tuis-LAN oopmaak, terwyl die Pi self daardie LAN deur die tonnel bereik. Niks in die draadlose laag is stukkend nie. Wat ontbreek, is 'n gerouteerde kontrak: die hotspot-voorvoegsel moet in die TUN-koppelvlak gedra word, en iets aan die tuiskant moet weet hoe om antwoorde daarheen te stuur. Albei helftes moet bestaan voordat 'n enkele pakket die rondrit kan voltooi.

Drie aanhegsels met drie verskillende take

'n Linux Ethernet-brug stuur rame volgens bestemming-MAC-adres. OpenVPN in TUN-modus dra IP-pakkette en het glad geen MAC-laag nie, so om 'n plaaslike brug by te voeg, sluit die tonnel nooit as 'n poort in nie. Die kern-TUN/TAP-dokumentasie verduidelik daardie skeiding: 'n TAP-toestel lyk soos 'n Ethernet-koppelvlak, 'n TUN-toestel nie. 'n Ontwerp wat twee plaaslike poorte brug en dan routeer, is 'n routeerder, wat die koppelvlakname ook al sê.

Daardie onderskeid bepaal eienaarskap. Die kliënte se subnet, hul verstekpoort en die DHCP-gesag vir daardie omvang hoort by die Pi se plaaslike plan. Tuis-DHCP-uitsendings steek nie 'n gerouteerde tonnel oor nie, en geen bruginstelling verander dit nie; om die kliënte na 'n tuis-DHCP-bediener te wys, is 'n aparte, doelbewuste aflosontwerp met sy eie foutmodusse.

Hou die modem ook buite die kliëntebrug. 'n PPP-aanhegsel is nie 'n Ethernet-toestel met 'n ander etiket nie, en pppd se gedokumenteerde verstekroete-logika loop ná IPCP-onderhandeling en onttrek sy roete wanneer daardie skakel val. Om 'n DHCP-sjabloon te kopieer en elke usb0 na ppp0 te hernoem, bewys niks oor poort, metriek of lewensiklus nie.

Kies die voorvoegsels voordat jy enige konfigurasie wysig

Oorvleuelende voorvoegsels mors meer aande as firewall-reëls, want 'n oorvleueling stuur die roetesoektog na die verkeerde koppelvlak selfs wanneer die tonnel gesond is. Begin deur te lys wat reeds op die Pi bestaan en lees dan die resultaat as vier aparte poele.

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

Die eerste poel is die underlay-adres wat die draer aan die modem gegee het; dit moet uit elke kliëntgerigte plan bly. Die tweede is die tonnel-subnet wat die bediener gekies het, dikwels 'n privaat /24 van sy eie. Die derde is die hotspot-brug, en die vierde is die tuis-voorvoegsel wat jy wil bereik. In hierdie deurloop kry die hotspot 172.28.90.0/24 met die brug by 172.28.90.1, en die tuisdiens-LAN hou 192.168.77.0/24, wat die 192.168.1.0/24- en 10.0.0.0/24-verstekke wat verbruikersroeteerders saambring en die 100.64.0.0/10-draerreeks vermy.

Adverteer die brugadres as poort in die hotspot se DHCP-omvang en niks anders nie. Moet nooit aan hotspot-kliënte 'n tuisadres as poort gee nie; hulle het geen skakellaag-pad na daardie segment nie.

Roeteer elke rigting aan die kant wat dit besit

Die Pi het 'n roete vir die tuis-voorvoegsel deur die tonnel nodig. Bedieners in bediener-modus stoot gewoonlik daardie roete, so bevestig eers dat aanstuur aan is en dat die kern 'n tuisadres uit tun0 oplos.

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

As ip route get steeds die underlay-koppelvlak rapporteer, stop daar; niks verder in die pad kan 'n verkeerde opsoektog herstel nie.

Tuis-toestelle het geen roete na 172.28.90.0/24 nie, so hul antwoorde volg die verstekpoort en sterf by die roeteerder. Twee ondersteunde herstellings bestaan. Voeg óf 'n statiese roete op die tuisroeteerder by wat die hotspot-voorvoegsel na die VPN-bediener se LAN-adres wys, óf, wanneer die bediener self die poort is, registreer die kliëntvoorvoegsel in die bediener se eie roeteblad. In OpenVPN se multi-kliënt-modus dra die kliëntspesifieke gids daardie assosiasie: 'n lêer vernoem na die kliëntsertifikaat se algemene naam, wat iroute 172.28.90.0 255.255.255.0 plus die ooreenstemmende route-reël bevat wat dit in die bedienerkern installeer. 'n Gerade kernroete op die bediener is nie dieselfde verklaring as om die bediener te vertel watter kliënt die voorvoegsel besit nie.

Moenie die tuisnetwerk se DHCP-diens na die VPN-bediener skuif om dit te laat werk nie. Om die verstekpoort vir 'n hele huis te vervang is 'n veel groter verandering as om een privaat terugroete by te voeg, en dit sleep DNS, adresbesprekings en elke toestel wat die nuwe huurkontrak ignoreer in die faling in.

Maak aansturing oop sonder om aan die firewall te raai

Aansturing wat aangeskakel is, beteken nie die pakket word deurgelaat nie. Verkeer van die brug na die tonnel tref steeds die filterreëls, en 'n verstek-drop-aanstuurbeleid laat hotspot-verkeer val terwyl die Pi se eie verkeer aanhou werk, wat presies die gesplete simptoom hierbo lewer.

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

Soek na 'n aanvaardingsreël van br0 na tun0 en die ooreenstemmende antwoordrigting, en na 'n postrouting-reël wat die bron kan herskryf. As die kettingbeleid drop is en geen reël pas nie, voeg die smal aanvaardings by en hertoets eerder as om die beleid na aanvaarding om te skakel.

Vertaling is 'n beleidskeuse eerder as 'n vereiste. Bron-NAT na die tuis-LAN laat elke hotspot-kliënt soos die Pi se tonneladres lyk, wat per-kliënt-toeskrywing in tuislogboeke verloor en dienste breek wat die oorspronklike bron verwag. Roetering sonder NAT hou kliëntadresse sigbaar maar hang van die terugroete hierbo af. Kies een en hanteer DNS en IPv6 op dieselfde manier, want 'n werkende IPv4-pad langs 'n stukkende IPv6-pad lees steeds as half-stukkend in 'n blaaier.

Verifieer die rondrit en breek dit dan doelbewus

Toets vanaf 'n hotspot-kliënt, nooit vanaf die Pi, want die Pi se eie verkeer omseil beide die heen- en die terugpad. Kyk na beide koppelvlakke terwyl een kliënt 'n tuisdiens probeer bereik.

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

Lees die twee opnames saam. Versoeke op br0 wat nooit op tun0 verskyn nie, beteken die Pi stuur nie aan nie of die roete wys elders. Versoeke op tun0 sonder antwoorde beteken die tuiskant het geen terugroete nie of die bediener het die pakket gefiltreer. Antwoorde op tun0 wat nooit weer op br0 verskyn nie, beteken die omgekeerde filterreël ontbreek, waar die tonnel perfek lyk en die kliënt steeds niks sien nie.

Breek die pad dan doelbewus. Bring die modemverbinding af en weer op en herhardloop die roete- en opnamekontroles; 'n roete wat die tonnel oorleef maar by herverbinding verdwyn, hoort in die verbindingsprofiel, nie in 'n eenmalige opdrag nie. Bevestig dat die tonnel se vervoer steeds deur die underlay vertrek en nie deur homself nie, die klassieke lus wanneer 'n gestote verstekroete aanvaar word sonder 'n gasheerroete na die eweknie.

Aanvaar die ontwerp eers wanneer 'n hotspot-kliënt 'n tuisnaam kan oplos, 'n TCP-diens kan oopmaak en 'n sessie oor een modemherverbinding lewendig kan hou. As 'n toepassing werklik Ethernet-vlak-ontdekking op die tuissegment vereis, kies 'n ondersteunde Laag 2-ontwerp eerder as om die plaaslike brug as gebrug te beskryf en te wag vir uitsending om te verskyn.