Hotspot-Clients auf einem Pi erreichen das Heim-LAN über ein TUN-VPN nicht

Lokale Wi-Fi- und Ethernet-Clients verbinden sich mit dem Hotspot des Pi, beziehen eine Adresse aus dessen DHCP-Bereich und laden Internetseiten ohne Beschwerden. Dieselben Clients laufen dann in einen Timeout, wenn sie eine Dateifreigabe oder eine Weboberfläche im Heim-LAN öffnen, während der Pi selbst dieses LAN über den Tunnel erreicht. In der WLAN-Schicht ist nichts defekt. Es fehlt ein gerouteter Vertrag: Das Hotspot-Präfix muss in die TUN-Schnittstelle getragen werden, und etwas auf der Heimseite muss wissen, wie Antworten dorthin zurückgehen. Beide Hälften müssen existieren, bevor ein einzelnes Paket die Rundreise beenden kann.

Drei Anbindungen mit drei verschiedenen Aufgaben

Eine Linux-Ethernet-Bridge leitet Frames nach der Ziel-MAC-Adresse weiter. OpenVPN im TUN-Modus trägt IP-Pakete und hat überhaupt keine MAC-Schicht, sodass das Hinzufügen einer lokalen Bridge den Tunnel nie als Port einträgt. Die Kernel-Dokumentation zu TUN/TAP erklärt diese Trennung: Ein TAP-Gerät sieht wie eine Ethernet-Schnittstelle aus, ein TUN-Gerät nicht. Ein Entwurf, der zwei lokale Ports überbrückt und dann routet, ist ein Router, egal was die Schnittstellennamen sagen.

Diese Unterscheidung entscheidet die Zuständigkeit. Das Subnetz der Clients, ihr Standardgateway und die DHCP-Autorität für diesen Bereich gehören zum lokalen Plan des Pi. Heim-DHCP-Broadcasts überqueren keinen gerouteten Tunnel, und keine Bridge-Einstellung ändert das; die Clients auf einen Heim-DHCP-Server zu zeigen, ist ein separates, bewusstes Relay-Design mit eigenen Fehlermodi.

Halte auch das Modem außerhalb der Client-Bridge. Eine PPP-Anbindung ist kein Ethernet-Gerät mit einem anderen Etikett, und die dokumentierte Standardrouten-Logik von pppd läuft nach der IPCP-Aushandlung und zieht ihre Route zurück, wenn diese Verbindung wegfällt. Eine DHCP-Vorlage zu kopieren und jedes usb0 in ppp0 umzubenennen, beweist nichts über Gateway, Metrik oder Lebenszyklus.

Wähle die Präfixe, bevor du irgendeine Konfiguration bearbeitest

Überlappende Präfixe kosten mehr Abende als Firewall-Regeln, weil eine Überlappung die Routensuche auf die falsche Schnittstelle schickt, selbst wenn der Tunnel gesund ist. Beginne damit, aufzulisten, was auf dem Pi bereits existiert, und lies das Ergebnis dann als vier getrennte Pools.

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

Der erste Pool ist die Underlay-Adresse, die der Provider dem Modem gegeben hat; sie muss aus jedem clientseitigen Plan herausbleiben. Der zweite ist das Tunnel-Subnetz, das der Server gewählt hat, oft ein eigenes privates /24-Netz. Der dritte ist die Hotspot-Bridge, und der vierte ist das Heimprofix, das du erreichen willst. In diesem Durchlauf bekommt der Hotspot 172.28.90.0/24 mit der Bridge auf 172.28.90.1, und das Heimprofi-LAN behält 192.168.77.0/24, was die Standardbereiche 192.168.1.0/24 und 10.0.0.0/24 umgeht, mit denen Consumer-Router ausgeliefert werden, sowie den Provider-Bereich 100.64.0.0/10.

Kündige die Bridge-Adresse als Gateway im DHCP-Bereich des Hotspots an und sonst nichts. Gib Hotspot-Clients niemals eine Heimadresse als Gateway; sie haben keinen Pfad auf Sicherungsschicht zu diesem Segment.

Route jede Richtung auf der Seite, die sie besitzt

Der Pi braucht eine Route für das Heimprofix durch den Tunnel. Server im Servermodus schieben diese Route normalerweise, also bestätige zuerst, dass Forwarding an ist und dass der Kernel eine Heimadresse aus tun0 auflöst.

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

Wenn ip route get immer noch die Underlay-Schnittstelle meldet, höre dort auf; nichts weiter unten auf dem Pfad kann eine falsche Suche reparieren.

Heimgeräte haben keine Route zu 172.28.90.0/24, also folgen ihre Antworten dem Standardgateway und sterben am Router. Es gibt zwei unterstützte Reparaturen. Entweder fügst du eine statische Route auf dem Heimprofi-Router hinzu, die das Hotspot-Präfix auf die LAN-Adresse des VPN-Servers zeigt, oder, wenn der Server selbst das Gateway ist, registrierst du das Client-Präfix in der eigenen Routing-Tabelle des Servers. Im Multi-Client-Modus von OpenVPN trägt das client-spezifische Verzeichnis diese Zuordnung: eine Datei, benannt nach dem Common Name des Client-Zertifikats, die iroute 172.28.90.0 255.255.255.0 plus die passende route-Zeile enthält, welche sie im Server-Kernel installiert. Eine geratene Kernel-Route auf dem Server ist nicht dieselbe Aussage, wie dem Server zu sagen, welcher Client das Präfix besitzt.

Verschiebe den DHCP-Dienst des Heimnetzes nicht auf den VPN-Server, damit das funktioniert. Das Standardgateway für ein ganzes Haus zu ersetzen, ist eine weit größere Änderung als das Hinzufügen einer privaten Rückroute, und es zieht DNS, Adressreservierungen und jedes Gerät, das den neuen Lease ignoriert, in den Fehler hinein.

Öffne das Forwarding, ohne bei der Firewall zu raten

Aktiviertes Forwarding heißt nicht, dass das Paket durchgelassen wird. Verkehr von der Bridge zum Tunnel trifft weiterhin die Filterregeln, und eine Standard-Drop-Forward-Policy verwirft Hotspot-Verkehr, während der eigene Verkehr des Pi weiterläuft, was genau das gespaltene Symptom oben erzeugt.

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

Suche nach einer Accept-Regel von br0 nach tun0 und der passenden Antwortrichtung sowie nach einer Postrouting-Regel, die die Quelle umschreiben kann. Wenn die Chain-Policy drop ist und keine Regel passt, füge die engen Accepts hinzu und teste erneut, statt die Policy auf accept zu drehen.

Übersetzung ist eine Richtlinienwahl, keine Voraussetzung. Source-NAT zum Heim-LAN lässt jeden Hotspot-Client wie die Tunneladresse des Pi aussehen, was die Zuordnung pro Client in Heimprofi-Protokollen verliert und Dienste bricht, die die ursprüngliche Quelle erwarten. Routing ohne NAT hält Client-Adressen sichtbar, hängt aber von der Rückroute oben ab. Wähle eines und behandle DNS und IPv6 genauso, denn ein funktionierender IPv4-Pfad neben einem defekten IPv6-Pfad liest sich im Browser weiterhin als halb defekt.

Prüfe die Rundreise und brich sie dann absichtlich

Teste von einem Hotspot-Client, niemals vom Pi, denn der eigene Verkehr des Pi umgeht sowohl den Hin- als auch den Rückweg. Beobachte beide Schnittstellen, während ein Client einen Heimprofi-Dienst erreichen will.

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

Lies die beiden Mitschnitte zusammen. Anfragen auf br0, die nie auf tun0 erscheinen, bedeuten, dass der Pi nicht weiterleitet oder die Route woanders hinzeigt. Anfragen auf tun0 ohne Antworten bedeuten, dass die Heimseite keine Rückroute hat oder der Server das Paket gefiltert hat. Antworten auf tun0, die nie wieder auf br0 auftauchen, bedeuten, dass die umgekehrte Filterregel fehlt, wo der Tunnel perfekt aussieht und der Client trotzdem nichts sieht.

Brich den Pfad dann absichtlich. Nimm die Modemverbindung herunter und wieder hoch und führe die Routen- und Mitschnittprüfungen erneut aus; eine Route, die den Tunnel überlebt, aber beim Wiederverbinden verschwindet, gehört ins Verbindungsprofil, nicht in einen einmaligen Befehl. Bestätige, dass der Transport des Tunnels weiterhin über das Underlay und nicht durch sich selbst verlässt, die klassische Schleife, wenn eine geschobene Standardroute ohne Host-Route zum Peer akzeptiert wird.

Akzeptiere das Design nur, wenn ein Hotspot-Client einen Heimnamen auflösen, einen TCP-Dienst öffnen und eine Sitzung über eine Modem-Wiederverbindung hinweg am Leben halten kann. Wenn eine Anwendung wirklich Ethernet-Erkennung auf dem Heimsegment benötigt, wähle ein unterstütztes Layer-2-Design, statt die lokale Bridge als gebrückt zu beschreiben und auf Broadcast zu warten.