Wi-Fi funktioniert durch das VPN des Routers. Und die Kabelports?

Das Wi-Fi-Notebook zeigt die Exit-Adresse des VPN, der kabelgebundene Rechner im Nebenraum zeigt die des Providers. Beide hängen am selben Router, der Unterschied liegt also nicht in der VPN-Konfiguration. Er liegt darin, über welche Schnittstelle, welches VLAN oder welche Richtlinie der Verkehr tatsächlich lief. Abdeckung ist eine Eigenschaft pro Pfad, keine Eigenschaft der Box.

Der direkte Vergleich beider Clients findet den Unterschied schneller als das Lesen der Routerregeln.

Zwei Wege in denselben Router

Ein Router mit VPN-Client kann den Verkehr aus einer Bridge, einem VLAN oder einer Portliste umleiten und den Rest im WAN lassen. Das ist ein normales Design, und deshalb beweist ein erfolgreicher Funk-Test nur den Funkpfad. Ein Managed Switch kann einen Wandport auch in ein anderes Segment legen als das, welches der Access Point nutzt, ohne dass jemand den Router anfasst. Portbasierte Richtlinien übersieht man am leichtesten, weil der Port wie ein Teil desselben LAN aussieht.

Gleiche Hardware, andere Richtlinie. Die physische Box ist nicht die Grenze, für die du sie hältst.

Vergleiche das Gateway, das jeder Client tatsächlich nutzt

Lies am kabelgebundenen Gerät die aktive Schnittstelle, ihre Adresse und ihr Standardgateway aus. Auf einem Rechner mit gleichzeitig aktivem Wi-Fi und Ethernet entscheidet die Routing-Metrik, wer gewinnt, und oft ist es nicht der erwartete Weg. Vergleiche dieses Gateway mit dem, das der Funk-Client genutzt hat, und prüfe, zu welchem Routernetz der Switchport gehört. Das WireGuard-Client-Rezept in pfSense zeigt, wie ein einzelner Router einen Tunnel besitzen und andere Schnittstellen in Ruhe lassen kann.

Unterscheiden sich die beiden Gateways, hast du die Antwort, bevor du eine einzige Firewall-Regel anfasst.

Vergleiche DNS und IPv6 getrennt

Ein kabelgebundener Client mit manuell konfiguriertem Resolver kann die DNS-Richtlinie des Routers völlig umgehen, selbst wenn sein Verkehr korrekt gelenkt wird. IPv6 ist die andere Hälfte: Ein Tunnel, der nur IPv4 verarbeitet, kann IPv6-Verkehr auf dem nativen Pfad lassen. Teste eine Namensabfrage und ein IPv6-Ziel vom kabelgebundenen Gerät aus, nicht nur eine IPv4-Adressprüfung. Nutze eine Abfrage, die nur der Resolver des Routers beantworten könnte, etwa einen internen Hostnamen.

Jedes davon ist ein eigener Vergleich, und jedes kann für sich fehlschlagen.

Vergleiche, was passiert, wenn der Tunnel ausfällt

Wenn das Design reinen VPN-Zugang verlangt, stoppe den Tunnel und teste den kabelgebundenen Client mit harmlosem Verkehr. Ein kabelgebundenes Gerät, das auf das normale WAN zurückfällt, bleibt online, verfehlt aber die beabsichtigte Route, was für jeden, der nur Konnektivität prüft, wie Erfolg aussieht. Der Funk-Client kann sich anders verhalten, und genau dieser Unterschied ist den Vergleich wert.

Fehlerverhalten gehört zur Abdeckung und ist kein Sonderfall danach.

Ordne das Ergebnis der richtigen Schicht zu

Ein VPN-Client auf Geräteebene oder ein Browser-Proxy auf dem kabelgebundenen Rechner kann die gemessene Exit-Adresse unabhängig vom Router ändern. Halte fest, welche Schichten während des Tests aktiv waren, sonst wird eine erfolgreiche Adressänderung dem falschen Gateway gutgeschrieben. Dieselbe Vorsicht gilt für ein zwischengespeichertes Ergebnis von vor der Änderung.

Teste frischen Verkehr, notiere die Schichten und schreibe Segment und Schnittstelle auf. Genau diese Aufzeichnung macht den nächsten Vergleich aussagekräftig statt zu einer weiteren Vermutung.