Hotspotclients op een Pi bereiken het thuis-LAN niet via een TUN-VPN

Lokale Wi-Fi- en Ethernet-clients verbinden met de hotspot van de Pi, halen een adres uit zijn DHCP-scope en laden internetpagina's zonder klachten. Dezelfde clients lopen daarna vast wanneer ze een bestandsaandeel of een webinterface op het thuis-LAN openen, terwijl de Pi zelf dat LAN via de tunnel bereikt. Niets in de draadloze laag is kapot. Wat ontbreekt is een gerouteerd contract: het hotspot-prefix moet in de TUN-interface worden gedragen, en iets aan de thuiszijde moet weten hoe antwoorden daar terug moeten. Beide helften moeten bestaan voordat één pakket de rondreis kan voltooien.

Drie aansluitingen met drie verschillende taken

Een Linux Ethernet-bridge stuurt frames door op het doel-MAC-adres. OpenVPN in TUN-modus draagt IP-pakketten en heeft helemaal geen MAC-laag, dus een lokale bridge toevoegen registreert de tunnel nooit als poort. De kernel-documentatie over TUN/TAP legt die splitsing uit: een TAP-apparaat lijkt op een Ethernet-interface, een TUN-apparaat niet. Een ontwerp dat twee lokale poorten overbrugt en daarna routeert, is een router, wat de interfacenamen ook zeggen.

Dat onderscheid bepaalt het eigendom. Het subnet van de clients, hun standaardgateway en de DHCP-autoriteit voor die scope horen bij het lokale plan van de Pi. Thuis-DHCP-broadcasts steken geen gerouteerde tunnel over, en geen bridge-instelling verandert dat; de clients naar een thuis-DHCP-server wijzen is een apart, bewust relayontwerp met zijn eigen faalmodi.

Houd de modem ook buiten de clientbridge. Een PPP-aansluiting is geen Ethernet-apparaat met een ander label, en de gedocumenteerde standaardroutelogica van pppd draait na de IPCP-onderhandeling en trekt zijn route terug wanneer die link wegvalt. Een DHCP-sjabloon kopiëren en elke usb0 naar ppp0 hernoemen bewijst niets over gateway, metriek of levenscyclus.

Kies de prefixen voordat je enige configuratie bewerkt

Overlappende prefixen kosten meer avonden dan firewallregels, omdat een overlap de routeopzoeking naar de verkeerde interface stuurt, zelfs wanneer de tunnel gezond is. Begin met op te sommen wat al op de Pi bestaat en lees het resultaat dan als vier afzonderlijke poelen.

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

De eerste poel is het underlay-adres dat de provider aan de modem gaf; het moet buiten elk clientgericht plan blijven. De tweede is het tunnelsubnet dat de server koos, vaak een eigen privé /24-net. De derde is de hotspotbridge, en de vierde is het thuisprefix dat je wilt bereiken. In deze wandeling krijgt de hotspot 172.28.90.0/24 met de bridge op 172.28.90.1, en het thuisservice-LAN behoudt 192.168.77.0/24, wat de standaardwaarden 192.168.1.0/24 en 10.0.0.0/24 die consumentenrouters meeleveren en de providerrange 100.64.0.0/10 vermijdt.

Adverteer het bridge-adres als gateway in de DHCP-scope van de hotspot en niets anders. Geef hotspotclients nooit een thuisadres als gateway; ze hebben geen pad op linklaag naar dat segment.

Routeer elke richting aan de kant die hem bezit

De Pi heeft een route naar het thuisprefix via de tunnel nodig. Servers in servermodus duwen die route normaal, dus bevestig eerst dat forwarding aan staat en dat de kernel een thuisadres uit tun0 oplost.

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

Als ip route get nog steeds de underlay-interface meldt, stop daar; niets verderop in het pad kan een verkeerde opzoeking repareren.

Thuisapparaten hebben geen route naar 172.28.90.0/24, dus hun antwoorden volgen de standaardgateway en sterven bij de router. Er bestaan twee ondersteunde reparaties. Voeg een statische route op de thuisrouter toe die het hotspotprefix naar het LAN-adres van de VPN-server wijst, of, wanneer de server zelf de gateway is, registreer het clientprefix in de eigen routetabel van de server. In de multi-clientmodus van OpenVPN draagt de clientspecifieke map die associatie: een bestand genoemd naar de common name van het clientcertificaat, met iroute 172.28.90.0 255.255.255.0 plus de bijbehorende route-regel die het in de serverkernel installeert. Een geraden kernelroute op de server is niet dezelfde uitspraak als de server vertellen welke client het prefix bezit.

Verplaats de DHCP-dienst van het thuisnetwerk niet naar de VPN-server om dit te laten werken. De standaardgateway van een heel huis vervangen is een veel grotere wijziging dan één privé retourroute toevoegen, en het sleept DNS, adresreserveringen en elk apparaat dat de nieuwe lease negeert de storing in.

Open forwarding zonder aan de firewall te raden

Forwarding aan betekent niet dat het pakket mag passeren. Verkeer van de bridge naar de tunnel raakt nog steeds de filterregels, en een standaard-drop-forwardbeleid laat hotspotverkeer vallen terwijl het eigen verkeer van de Pi blijft werken, wat precies het gesplitste symptoom hierboven oplevert.

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

Zoek een accept-regel van br0 naar tun0 en de bijbehorende antwoordrichting, en een postrouting-regel die de bron kan herschrijven. Als het ketenbeleid drop is en geen regel past, voeg de smalle accepts toe en test opnieuw in plaats van het beleid naar accept te draaien.

Vertaling is een beleidskeuze, geen vereiste. Source-NAT naar het thuis-LAN laat elke hotspotclient op het tunneladres van de Pi lijken, wat de toewijzing per client in thuislogs verliest en diensten breekt die de oorspronkelijke bron verwachten. Routeren zonder NAT houdt clientadressen zichtbaar maar hangt van de retourroute hierboven af. Kies er één en behandel DNS en IPv6 op dezelfde manier, want een werkend IPv4-pad naast een kapot IPv6-pad leest in een browser nog steeds als half kapot.

Verifieer de rondreis en breek hem dan expres

Test vanaf een hotspotclient, nooit vanaf de Pi, want het eigen verkeer van de Pi omzeilt zowel het heen- als het terugpad. Observeer beide interfaces terwijl één client een thuisdienst probeert te bereiken.

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

Lees de twee opnames samen. Verzoeken op br0 die nooit op tun0 verschijnen betekenen dat de Pi niet doorstuurt of dat de route elders heen wijst. Verzoeken op tun0 zonder antwoorden betekenen dat de thuiszijde geen retourroute heeft of dat de server het pakket filterde. Antwoorden op tun0 die nooit terugkeren op br0 betekenen dat de omgekeerde filterregel ontbreekt, waarbij de tunnel perfect lijkt en de client toch niets ziet.

Breek het pad dan bewust. Haal de modemverbinding neer en weer omhoog en voer de route- en opnamecontroles opnieuw uit; een route die de tunnel overleeft maar bij herverbinding verdwijnt, hoort in het verbindingsprofiel, niet in een eenmalige opdracht. Bevestig dat het transport van de tunnel nog steeds via de underlay naar buiten gaat en niet via zichzelf, de klassieke lus wanneer een geduwde standaardroute wordt geaccepteerd zonder hostroute naar de peer.

Accepteer het ontwerp alleen wanneer een hotspotclient een thuissnaam kan oplossen, een TCP-dienst kan openen en een sessie levend kan houden over één modemherverbinding. Als een toepassing echt Ethernet-niveau-ontdekking op het thuissegment vereist, kies een ondersteund Layer 2-ontwerp in plaats van de lokale bridge als overbrugd te beschrijven en op broadcast te wachten.