So prüfen Sie, ob ein Mesh-Wi-Fi-Satellit den VPN-Router nutzt

Ein Satellit, der denselben Wi-Fi-Namen wie der Basisrouter annimmt, sagt fast nichts darüber aus, wohin die Pakete seiner Clients gehen. Der Knoten ist ein Funkmodul und eine Bridge, bis das Gegenteil bewiesen ist. Entscheidend für den Ausgang ist das Standard-Gateway, das jeder Client erhält, und der Weiterleitungsmodus des Knotens davor. Führen Sie die folgenden fünf Prüfungen vom Client aus nach außen durch, und Sie erhalten eine belastbare Antwort statt eines Eindrucks aus einem Speedtest.

Prüfen Sie das Gateway, das der Client tatsächlich erhalten hat

Geben Sie auf dem Client die Routentabelle und die Nachbartabelle aus. Die Standardroute nennt die Adresse, die den Datenverkehr weiterleitet; der Nachbareintrag nennt die MAC, die zu dieser Adresse gehört. Nutzen Sie den Client und nicht die Geräteliste des Routers, denn eine Geräteliste zeigt Zuordnungen statt Pfade.

ip route show default
ip -6 route show default
ip neigh show

Windows gibt dieselben Fakten in anderer Form aus: ipconfig /all liefert das Standard-Gateway und arp -a liefert die MAC. Unter macOS route -n get default und arp -an decken dasselbe ab.

Vergleichen Sie dieses Gateway mit zwei Adressen, die Sie bereits kennen: der LAN-Adresse des Basisrouters und der Verwaltungsadresse des Satelliten. Ist das Gateway die LAN-Adresse des Routers, ist der Client zum Router gebrückt, und die Richtlinie des Routers für dieses LAN gilt unverändert. Ist das Gateway die Adresse des Satelliten, routet der Satellit, und der Router sieht die Pakete des Clients nie als LAN-Verkehr; die Entscheidung muss auf dem Knoten fallen, sonst fällt sie gar nicht.

Klären Sie, in welchem Modus sich der Knoten wirklich befindet

Mesh-Produkte verwenden drei Begriffe für unterschiedliches Verhalten; vertrauen Sie deshalb dem Paketpfad mehr als dem Etikett in der App. Bridge- oder Access-Point-Modus leitet Frames weiter. Der Router-Modus beendet ein Subnetz und betreibt DHCP. Der Gastmodus setzt Clients meist in ein eigenes VLAN mit eigenen Regeln. Ein Knoten im Router-Modus hinter einem anderen Router ist ein doppeltes NAT, und seine Clients erreichen den VPN-Router bereits übersetzt, was eine Richtlinie aushebelt, die auf die Quelladresse abstellt.

Um die MAC zu bestimmen, lesen Sie das Etikett auf dem Knoten und vergleichen es mit ip neigh. Hersteller drucken die Basis-MAC und leiten die MAC-Adressen der einzelnen Funkmodule durch Inkrementieren eines Bytes ab, daher unterscheidet sich die letzte Hexadezimalstelle; vergleichen Sie das Präfix statt der ganzen Adresse. Gehört die Gateway-MAC zur LAN-Schnittstelle des Routers, routet der Knoten für diesen Client nicht.

Beweisen Sie den Ausgang am Router, nicht mit einem Speedtest

Der Zustand auf der Routerseite ist der einzige Ort, der die Übersetzung zeigt. Listen Sie unter OpenWrt die Richtlinienregeln und Routingtabellen auf und bestätigen Sie, dass der Tunnel einen aktuellen Handshake hat:

ip rule show
ip route show table all | grep default
wg show

Unter pfSense oder OPNsense finden sich dieselben Belege in pfctl -sr für Regeln, pfctl -ss für laufende Zustände und die WireGuard-Statusseite für Peer-Zähler, wie in der WireGuard-Client-Dokumentation. Filtern Sie die Zustandstabelle nach der Adresse des Clients. Zeigt der Zustand den Client auf die Tunneladresse übersetzt, ist der Verkehr im Tunnel; zeigt er die WAN-Adresse, ist er es nicht, egal was das Dashboard-Abzeichen sagt.

Ein Traceroute vom Client fügt einen Fakt hinzu, den die Zustandstabelle nicht liefern kann: den ersten Hop. Ist der erste Hop die LAN-Adresse des Routers, hat der Client den Router direkt erreicht. Ist es die Adresse des Knotens mit einem weiteren privaten Hop danach, befinden Sie sich auf einem gerouteten Segment, und dieser zweite Hop ist das Gerät, das die Richtlinie halten muss.

Prüfen Sie, was der Knoten außer einer Adresse noch verteilt

DHCP-Optionen reisen mit dem Lease, ein Knoten mit eigenem DHCP kann also auch eigenes DNS und eigene IPv6-Router-Advertisements ausliefern. Ein Client kann deshalb durch den Tunnel hinausgehen und trotzdem Abfragen an einen Resolver auf dem Knoten schicken oder eine globale IPv6-Adresse beziehen, die die Tunnelrichtlinie nie abdeckt. Geben Sie beides auf dem Client aus:

cat /etc/resolv.conf
ip -6 addr show scope global

Ist der Resolver der Knoten und leitet der Knoten an den Router weiter, folgt DNS dem Tunnel. Löst der Knoten lokal auf oder zeigt er auf den Resolver des ISP, verlassen die Abfragen den Tunnel, auch wenn HTTP das nicht tut. IPv6 verdient denselben Test: eine globale Adresse plus eine Standardroute, die den Tunnel umgeht, ist ein Leck, und Mesh-Firmware lässt IPv6 oft an, während die VPN-Richtlinie nur IPv4 abdeckt.

Brechen Sie den Tunnel absichtlich ab und schreiben Sie das Ergebnis auf

Nehmen Sie den Tunnel herunter und beobachten Sie einen Client, der mit diesem Knoten verbunden ist, nicht einen Client neben dem Router. ping und ein curl mit kurzem Timeout reichen aus; die Frage ist, ob der Verkehr stoppt oder auf das WAN zurückfällt. Stoppen Sie den Tunnel mit dem Dienstbefehl des Routers, etwa wg-quick down wg0 oder dem Dienststopp von OpenVPN, und halten Sie den Test kurz.

Arbeitet der Client weiter, fällt der Knoten oder der Router für dieses Segment offen aus, und das Mesh hat den Kill-Switch stillschweigend rückgängig gemacht. Bringen Sie den Tunnel zurück, bestätigen Sie, dass der Handshake-Zähler sich bewegt hat, und wiederholen Sie die Prüfung der Zustandstabelle aus dem dritten Schritt.

Notieren Sie eine Zeile pro Knoten: Bezeichnung, SSID, Gateway-Adresse, MAC-Präfix, Ausgang bestätigt ja oder nein, IPv6 abgedeckt und Verhalten bei abgeschaltetem Tunnel. Roaming ist der Punkt, an dem sich die Antwort ändert, testen Sie also die Räume, die Sie tatsächlich nutzen. Wenn eine Zeile nicht zu den übrigen passt, ist dieser Knoten der Kandidat für die Untersuchung, und die Korrektur gehört auf das Gerät, dem das Gateway dieser Zeile gehört.