Öffentliches WLAN und VPN: Was der Tunnel nicht abdeckt

Grünes Badge, zufriedenes Portal, funktionierender Browser: Das ist die ganze sichtbare Geschichte. Das Badge verschweigt, dass die verschlüsselte Verbindung von genau der Funkstrecke getragen wird, vor der sie Sie schützen soll. Diese Strecke liefert weiterhin jedes Paket, sieht weiterhin die Endpunktadresse und entscheidet weiterhin, ob überhaupt etwas ankommt. Die Laptop-Seite einer Hotelverbindung zu betrachten zeigt, welche Teile der Tunnel abdeckt und welche er Ihnen überlässt.

Die Zugangsstrecke trägt alles

Ein IPsec-ESP-Tunnel verpackt ein geschütztes inneres Paket in einen äußeren Header, den das Netz routen kann, und RFC 4303 Abschnitt 3.1.2 legt diese Trennung dar. Das innere Paket ist das, was der Tunnel schützt. Der äußere Header ist das, was der Hotspot liest, um es weiterzuleiten. Andere Entwürfe kapseln anders, doch die Planungsfrage ist dieselbe: Welcher Zugangspfad trägt diese Verbindung?

Ein Gateway-Fehler oder eine Strecke, die Pakete verwirft, stoppt die Zustellung, ohne Inhalte zu offenbaren. Zu einer stärkeren Verschlüsselung zu wechseln hilft dabei nicht, weil das fehlende Stück Transport ist und nicht Kryptografie. Eine erfolgreiche Zustellung beweist in der anderen Richtung ebenso wenig, denn ein funktionierender Pfad sagt nichts über den Zustand beider Rechner.

Ihr Laptop hat weiterhin seine eigenen Türen

Der Beitritt zu einem nicht vertrauenswürdigen Segment ändert, wer die Ports erreichen kann, auf denen Ihr Rechner lauscht. Ein Dateifreigabedienst, ein Fernverwaltungsagent oder ein Entwicklungsserver, der an alle Schnittstellen gebunden ist, ist für jeden in diesem Segment erreichbar, sofern nichts ihn stoppt. Verkehr, der nie in den Tunnel gelangt, wird von ihm nicht geschützt. Ein Listener, der antwortet, bevor der Tunnel steht, ist genau für dieses Fenster exponiert.

Die Anforderung ist eng und sollte genau formuliert werden: Der Laptop muss den VPN-Endpunkt erreichen, und fremde Geräte im Hotspot dürfen lokale Dienste nicht erreichen. Host-Firewall-Regeln bringen diese Grenze zum Ausdruck, und die eigenen Freigabeeinstellungen der Plattform bringen einen Teil davon ebenfalls zum Ausdruck. Ein Drucker oder ein Portalschritt ist eine begrenzte Ausnahme, die Sie bewusst hinzufügen, kein Beweis dafür, dass der ganze Hotspot das Vertrauen eines Büro-LAN verdient.

Manche Organisationen beschränken außerdem den lokalen Zugriff, solange eine Arbeitsverbindung aktiv ist, was Politik und nicht Technik ist. Lesen Sie diese Politik, bevor Sie eine Firewall deaktivieren, damit ein Peripheriegerät funktioniert.

Prüfen Sie, was tatsächlich lauscht

Sehen Sie sich die Sockets an statt die Einstellungsseite, denn die Seite beschreibt die Absicht und die Socket-Tabelle beschreibt den Rechner. Die beiden Auflistungen unten trennen jeden lauschenden Socket von denen, die ein Nachbar erreichen könnte. Führen Sie sie im nicht vertrauenswürdigen Segment aus, bevor Sie den Tunnel verbinden.

ss -lntu
ss -lntup | grep -v 127.0.0.1
resolvectl query vpn.example.net

Der erste Befehl zeigt jeden Socket, und der zweite filtert auf diejenigen, die über Loopback hinaus gebunden sind. Ein Dienst auf 0.0.0.0 oder :: ist auf jeder Schnittstelle verfügbar, einschließlich der Funkstrecke, während derselbe Dienst auf 127.0.0.1 aus dem Segment überhaupt nicht erreichbar ist. Die Resolver-Abfrage bestätigt, welchen Pfad der Name nimmt, bevor der Tunnel existiert, und dort stören Captive Portale. Wiederholen Sie die Auflistung nach dem Verbinden, weil manche Clients Schnittstellen hochfahren, die die Antwort ändern.

Ein Port, der nur erscheint, während der Tunnel steht, ist weniger exponiert, obwohl es sich lohnt, ihn zu kennen. Halten Sie die Differenz fest statt der absoluten Liste, denn das Delta ist das, was der Tunnel hinzugefügt hat.

Akzeptieren Sie keine neue Identität mitten in der Sitzung

Eine unerwartete Routenänderung, ein Wiederverbinden oder eine Portal-Weiterleitung ist keine Erlaubnis, eine andere Serveridentität zu akzeptieren. Wenn der Client eine Zertifikats- oder Schlüsselabweichung meldet, behandeln Sie das als Identitätsbefund und nicht als Konnektivität, die umgangen werden muss. Ein unerklärtes Root-Zertifikat zu installieren, damit ein Portal funktioniert, verwandelt ein Zustellungsproblem in ein Vertrauensproblem. Das Vertrauensproblem überlebt dann die Reise, die es geschaffen hat.

Nutzen Sie den eigenen Browserablauf des Portals, verbinden Sie dann den Tunnel erneut und lesen Sie im Client-Protokoll, welche Identität er geprüft hat. Identitätsfehler bedeutet, dass die Gegenseite nicht die erwartete ist, während Zustellungsfehler bedeutet, dass die Gegenseite nie geantwortet hat. Das erste ist ein Grund anzuhalten, das zweite ein Grund, einen anderen Pfad zu versuchen.

Entscheiden Sie zuerst das Ausfallverhalten

Hier werden zwei verschiedene Funktionen verwechselt. Wiederverbinden versucht, den Dienst wiederherzustellen, während eine Blockierungsrichtlinie steuert, welcher Verkehr erlaubt ist, solange der Tunnel unten ist. Keines von beiden liefert eine funktionierende Funkstrecke, und keines beweist, dass der Endpunkt sauber ist. Entscheiden Sie ausdrücklich: geschlossen scheitern für Anwendungen, die nie den lokalen Pfad nutzen dürfen, und gewöhnliches Surfen außerhalb des Tunnels zulassen, wenn das akzeptabel ist.

Schreiben Sie die Wahl auf, denn der Standard in den meisten Clients ist keines von beiden, und er variiert je nach Version. Richten Sie dann einen alternativen Zugangspfad ein, wenn Verfügbarkeit zählt, etwa einen Telefon-Hotspot mit eigenem Datentarif. Ein brauchbarer Abnahmetest hat drei getrennte Ergebnisse: Beabsichtigter Verkehr nutzt den geprüften Tunnel, fremde lokale Listener sind unerreichbar, und ein Ausfall erzeugt das gewählte Verhalten.