Wi-Fi-Client-Isolation gegen lokalen VPN-Zugriff: Was Sie blockiert

Setzen Sie zwei Telefone in dasselbe Gast-SSID, und keines sieht das andere, doch beide erreichen das Internet. Fügen Sie auf einem davon einen VPN-Client hinzu, und der Drucker drei Meter entfernt bleibt unsichtbar, während ein Server auf einem anderen Kontinent auf Pings antwortet. Am Tunnel ist nichts defekt; es sind zwei getrennte Zugriffsentscheidungen im Spiel, und nur eine davon betrifft das Routing. Der Access Point entscheidet, ob WLAN-Clients miteinander sprechen dürfen, und der VPN-Client entscheidet, welche Ziele durch den Tunnel verlassen. Wer beides verwechselt, produziert stundenlange sinnlose Konfigurationsänderungen.

Die beiden Tore sind unabhängig

Client-Isolation ist eine Switching-Entscheidung. Der Access Point nimmt einen Frame von einer assoziierten Station an, schaut auf das Ziel, bemerkt, dass das Ziel eine andere Station an derselben Bridge ist, und verwirft ihn. Die IP-Adresse der Station spielt für diese Entscheidung keine Rolle, das VPN ebenso wenig.

Routing ist eine andere Entscheidung, die auf dem Client fällt. Die Routing-Tabelle des VPN entscheidet, ob ein Paket für 192.168.1.50 in den Tunnel geht oder über die Wi-Fi-Schnittstelle hinausläuft. Verlässt das Paket den Weg über Wi-Fi und isoliert der Access Point die Clients, stirbt es am Access Point. Geht das Paket in den Tunnel, sieht der Access Point das ursprüngliche Ziel nie und kann nichts isolieren.

Was Isolation an einem typischen Access Point blockiert

Hersteller liefern das unter mehreren Namen: Client-Isolation, AP-Isolation, Station-Isolation oder ein Gastnetz, das sie impliziert. In OpenWrt ist die Option pro Schnittstelle isolate innerhalb der WLAN-Konfiguration, wie in der WLAN-Dokumentation beschrieben, und ein Gast-SSID bekommt meist eine eigene Bridge und Firewall-Zone. Der Effekt ist, dass Unicast-Frames zwischen Clients nicht gebrückt werden, sodass ein Ping, eine SMB-Verbindung oder ein Druckauftrag zum Nachbarn scheitert, obwohl beide Geräte volles Signal zeigen.

Erkennungsprotokolle leiden zuerst und am sichtbarsten. mDNS für Drucker und Mediengeräte läuft per Multicast zu 224.0.0.251, SSDP nutzt 239.255.255.250, und ob diese Frames die Bridge überqueren, hängt vom Hersteller ab und davon, ob Multicast-zu-Unicast-Konvertierung aktiv ist. Ein Gerät, das in einer Liste fehlt, ist schwächere Evidenz als eine gescheiterte direkte Verbindung zu einer bekannten Adresse.

Was das VPN ändert und was es nicht ändern kann

Ein voller Tunnel übernimmt die Standardroute, also sind lokale Subnetze nur erreichbar, wenn der Client eine spezifischere Route dafür behält. Split-Tunnel tun das Gegenteil und erhalten den lokalen Zugriff konstruktionsbedingt. Keine der beiden Einstellungen kann einen isolierenden Access Point dazu bringen, einen Frame zwischen zwei seiner Clients weiterzuleiten, deshalb ist das Erlauben lokalen Verkehrs im VPN-Client nötig, aber nicht ausreichend.

Der umgekehrte Fall ist ebenso häufig. Der Access Point erlaubt Peer-Verkehr, der VPN-Client schließt das lokale Subnetz aus dem Tunnel aus, und der Drucker antwortet trotzdem nicht, weil die Host-Firewall das WLAN als öffentlich behandelt. Drei Schichten, drei verschiedene Standardwerte, und nur die Route ist in den meisten VPN-Protokollen sichtbar.

Finden Sie heraus, welches Tor geschlossen ist

Beginnen Sie mit einem Test, der das VPN aus dem Bild nimmt: Verbinden Sie zwei gewöhnliche Geräte mit demselben SSID und versuchen Sie, das eine vom anderen über die Adresse zu erreichen. Scheitert das, isoliert der Access Point, und keine VPN-Einstellung wird das beheben. Gelingt es, gehen Sie zum Client und führen Sie ip route get 192.168.1.50 unter Linux oder Find-NetRoute -RemoteIPAddress 192.168.1.50 unter Windows aus; die Ausgabe nennt die Schnittstelle, die das Paket nutzen wird.

Zeigt die Route auf die Wi-Fi-Schnittstelle, verlässt das Paket unverschlüsselt, und die Frage wird, ob Access Point und Host-Firewall das erlauben. Zeigt die Route auf den Tunnel, wird das Ziel zum VPN-Server geschickt, was für ein Gerät im selben LAN falsch ist und meist bedeutet, dass die Erlaubnisliste des Tunnels zu breit ist.

Eine direkte Verbindung zum Port des Druckers ist ein besserer Test als eine Erkennungsliste. nc -vz 192.168.1.50 9100 unter Linux oder Test-NetConnection 192.168.1.50 -Port 9100 in PowerShell sagt Ihnen, ob die Adresse überhaupt erreichbar ist, bevor irgendein Pairing auf Anwendungsebene in die Diskussion kommt.

Wählen Sie die Lösung für das Netz, in dem Sie sind

In einem Hotel- oder Gastnetz ist Isolation beabsichtigt, und Sie sollten nicht versuchen, sie zu umgehen. Behandeln Sie das lokale Gerät als unerreichbar, nutzen Sie das VPN, um einen Host zu erreichen, der drucken oder teilen kann, und hören Sie auf, das SSID als LAN zu behandeln.

Zu Hause ist es sinnvoll, die Isolation im Haupt-SSID abzuschalten, wenn die Geräte Ihre eigenen sind, während das Gast-SSID isoliert bleibt. Die Einstellung liegt in der WLAN-Konfiguration des Access Points und gehört dorthin, nicht in Firewall-Ausnahmen auf jedem Client.

Im Büro sollten Sie annehmen, dass Access Point, VLAN und Host-Firewall alle beabsichtigt sind. Eskalieren Sie mit den Testergebnissen, statt darum zu bitten, die Isolation abzuschalten, denn ein Netz, das Clients trennt, schützt meist etwas.

Prüfen Sie die Anwendung, nicht nur den Ping

Ein erfolgreicher Ping beweist den Pfad, nicht den Dienst. Drucker akzeptieren oft rohes 9100 oder IPP auf 631, verweigern aber die Erkennung, und eine Dateifreigabe braucht 445 plus funktionierende Namensauflösung. Bestätigen Sie den Port, den die Anwendung nutzt, und wiederholen Sie dann die eigentliche Aufgabe auf dem Gerät.

Halten Sie die beiden Schichten in Ihren Notizen getrennt: was das WLAN erlaubt und was das VPN weiterleitet. Wenn das nächste Mal ein Gerät aus einer Liste verschwindet, sagt Ihnen diese Trennung, wo Sie zuerst nachsehen.