Hotspotklienter på en Pi når inte hemma-LAN-et över en TUN-VPN

Lokala Wi-Fi- och Ethernet-klienter ansluter till Pi:ns hotspot, hämtar en adress från dess DHCP-område och laddar internetsidor utan klagomål. Samma klienter får sedan tidsgräns när de öppnar en fildelning eller ett webbgränssnitt på hemma-LAN-et, medan Pi:et självt når det LAN-et genom tunneln. Inget i det trådlösa lagret är trasigt. Det som saknas är ett routat kontrakt: hotspot-prefixet måste bäras in i TUN-gränssnittet, och något på hemsidan måste veta hur svar skickas tillbaka dit. Båda halvorna måste finnas innan ett enda paket kan fullborda rundresan.

Tre anslutningar med tre olika jobb

En Linux Ethernet-brygga vidarebefordrar ramar efter mål-MAC-adress. OpenVPN i TUN-läge bär IP-paket och har inget MAC-lager alls, så att lägga till en lokal brygga registrerar aldrig tunneln som port. kärnans TUN/TAP-dokumentation förklarar den uppdelningen: en TAP-enhet ser ut som ett Ethernet-gränssnitt, en TUN-enhet gör det inte. En design som bryggar två lokala portar och sedan routar är en router, vad gränssnittsnamnen än säger.

Den skillnaden avgör ägandet. Klienternas subnät, deras standardgateway och DHCP-myndigheten för det området tillhör Pi:ns lokala plan. Hemmets DHCP-sändningar korsar inte en routad tunnel, och ingen brygginställning ändrar det; att peka klienterna mot en DHCP-server i hemmet är en separat, avsiktlig relaydesign med egna fellägen.

Håll också modemet utanför klientbryggan. En PPP-anslutning är inte en Ethernet-enhet med annan etikett, och pppd:s dokumenterade standardruttlogik körs efter IPCP-förhandlingen och drar tillbaka sin rutt när den länken faller. Att kopiera en DHCP-mall och byta namn på varje usb0 till ppp0 bevisar ingenting om gateway, metrik eller livscykel.

Välj prefixen innan du redigerar någon konfiguration

Överlappande prefix kostar fler kvällar än brandväggsregler, eftersom en överlappning skickar ruttuppslaget till fel gränssnitt även när tunneln är frisk. Börja med att lista vad som redan finns på Pi:et och läs sedan resultatet som fyra separata pooler.

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

Den första poolen är den underlay-adress som operatören gav modemet; den måste hållas utanför varje klientvänd plan. Den andra är tunnelns subnät som servern valde, ofta ett eget privat /24-nät. Den tredje är hotspot-bryggan, och den fjärde är det hemprefix du vill nå. I den här genomgången får hotspotten 172.28.90.0/24 med bryggan på 172.28.90.1, och hemmets tjänste-LAN behåller 192.168.77.0/24, vilket undviker standarderna 192.168.1.0/24 och 10.0.0.0/24 som konsumentroutrar levereras med samt operatörsintervallet 100.64.0.0/10.

Annonsera bryggans adress som gateway i hotspotens DHCP-område och inget annat. Ge aldrig hotspotklienter en hemadress som gateway; de har ingen väg på länklagret till det segmentet.

Routa varje riktning på den sida som äger den

Pi:et behöver en rutt till hemprefixet genom tunneln. Servrar i serverläge skjuter vanligtvis den rutten, så bekräfta först att vidarebefordran är på och att kärnan löser en hemadress ur tun0.

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

Om ip route get fortfarande rapporterar underlay-gränssnittet, stanna där; inget längre fram på vägen kan reparera ett felaktigt uppslag.

Hemmets enheter har ingen rutt till 172.28.90.0/24, så deras svar följer standardgatewayen och dör vid routern. Det finns två stödda reparationer. Antingen lägg till en statisk rutt på hemroutern som pekar hotspot-prefixet mot VPN-serverns LAN-adress, eller, när servern själv är gatewayen, registrera klientprefixet i serverns egen routingtabell. I OpenVPN:s flerklientläge bär den klientspecifika katalogen den associationen: en fil uppkallad efter klientcertifikatets common name, som innehåller iroute 172.28.90.0 255.255.255.0 plus den matchande route-raden som installerar den i serverkärnan. En gissad kärnrutt på servern är inte samma påstående som att berätta för servern vilken klient som äger prefixet.

Flytta inte hemnätets DHCP-tjänst till VPN-servern för att få detta att fungera. Att byta ut standardgatewayen för ett helt hus är en mycket större ändring än att lägga till en privat returväg, och det drar in DNS, adressreservationer och varje enhet som ignorerar det nya lånet i felet.

Öppna vidarebefordran utan att gissa på brandväggen

Att vidarebefordran är på betyder inte att paketet får passera. Trafik från bryggan till tunneln träffar fortfarande filterreglerna, och en standard-drop-vidarebefordringspolicy släpper hotspot-trafik medan Pi:ets egen trafik fortsätter att fungera, vilket ger exakt det delade symptomet ovan.

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

Leta efter en accept-regel från br0 till tun0 och den matchande svarsriktningen, och en postrouting-regel som kan skriva om källan. Om kedjepolicyn är drop och ingen regel matchar, lägg till de smala acceptarna och testa igen i stället för att vända policyn till accept.

Översättning är ett policyval, inte ett krav. Source-NAT mot hemma-LAN-et får varje hotspotklient att se ut som Pi:ets tunneladress, vilket tappar per-klient-attribuering i hemmets loggar och bryter tjänster som förväntar sig den ursprungliga källan. Routing utan NAT håller klientadresser synliga men beror på returvägen ovan. Välj en och hantera DNS och IPv6 på samma sätt, eftersom en fungerande IPv4-väg bredvid en trasig IPv6-väg fortfarande läses som halvt trasig i en webbläsare.

Verifiera rundresan och bryt den sedan med avsikt

Testa från en hotspotklient, aldrig från Pi:et, eftersom Pi:ets egen trafik kringgår både fram- och returvägen. Observera båda gränssnitten medan en klient försöker nå en hemmatjänst.

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 två fångsterna tillsammans. Förfrågningar på br0 som aldrig dyker upp på tun0 betyder att Pi:et inte vidarebefordrar eller att rutten pekar någon annanstans. Förfrågningar på tun0 utan svar betyder att hemsidan inte har någon returväg eller att servern filtrerade paketet. Svar på tun0 som aldrig dyker upp igen på br0 betyder att den omvända filterregeln saknas, där tunneln ser perfekt ut och klienten fortfarande inte ser något.

Bryt sedan vägen med avsikt. Ta ner modemanslutningen och upp igen och kör rutt- och fångstkontrollerna på nytt; en rutt som överlever tunneln men försvinner vid återanslutning hör i anslutningsprofilen, inte i ett engångskommando. Bekräfta att tunnelns transport fortfarande går ut genom underlay och inte genom sig själv, den klassiska slingan när en påskjuten standardrutt accepteras utan en värdrutt till peeren.

Acceptera designen först när en hotspotklient kan slå upp ett hemnamn, öppna en TCP-tjänst och hålla en session vid liv genom en modemåteranslutning. Om en applikation verkligen kräver Ethernet-nivå-upptäckt på hemsegmentet, välj en stödd Layer 2-design i stället för att beskriva den lokala bryggan som bryggad och vänta på att sändning ska dyka upp.