Warum das WLAN-Portal Ihr VPN blockiert und wie Sie sich erneut anmelden

In einem offenen Netz übergibt Ihr Zugangspunkt Pakete nicht einfach an das Internet. Ein vorgelagerter Policy-Punkt prüft, ob Ihr Gerät schon autorisiert ist, und bis dahin wird fast alles verworfen. Ihr VPN-Client deutet diese Stille als toten Server. Er sagt es selten: WireGuard wiederholt einen Handshake ins Leere, OpenVPN meldet eine Verbindungszeitüberschreitung, und IKEv2 kommt als Fehler 809 über einen entfernten Server zurück, der nicht antwortet.

Was das Portal tatsächlich steuert

Ein Captive Portal sind zwei zusammengeheftete Dinge: ein Policy-Entscheidungspunkt und ein Umleiter. Wenn sich Ihr Gerät assoziiert und ein DHCP-Lease bezieht, versetzt Sie das Netzwerk in einen Zustand vor der Autorisierung.

Dieser Zustand ist ein Firewall-Regelsatz. Er erlaubt meist DNS und erlaubt HTTP oder HTTPS zu einer kurzen Liste von Portal-Hosts, und er verwirft alles andere. Die erlaubte Liste ist der ummauerte Garten, und sie enthält fast nie einen VPN-Endpunkt.

Keines dieser Verwerfen ist höflich. Pakete an einen VPN-Server werden verworfen statt abgelehnt, sodass der Client weder ICMP unreachable noch TCP reset erhält, nur die Abwesenheit einer Antwort. Je nach Hersteller kann der Umleiter Port 80 mit einer Weiterleitung zur Anmeldeseite beantworten, während Port 443 verworfen oder abgefangen wird. Weiterleitungen sind leicht zu erkennen, weil sie eine einfache HTTP-Antwort tragen; das Abfangen auf 443 braucht ein Zertifikat, dem Ihr Browser nicht vertrauen wird.

Die Autorisierung selbst ist meist an die MAC-Adresse des Geräts gebunden, manchmal an die geleaste IP, und sie lebt in einer Sitzungstabelle mit einem Timer. Die Anmeldung legt einen Eintrag an. Die Firewall-Regel, die Ihren Verkehr durchlässt, existiert nur, solange dieser Eintrag existiert, und deshalb kehrt das ganze Problem später zurück, ohne dass sich auf Ihrer Seite etwas ändert.

Warum der VPN-Handshake stirbt, bevor er beginnt

Jedes Protokoll hat seinen eigenen Transport, und die Firewall vor der Autorisierung bricht jedes anders. IKEv2 unter Windows und iOS läuft über UDP 500 und UDP 4500; ein Verwerfen auf diesen Ports erscheint als 809 oder als namensauflösungsartiger Fehler bei Clients, die Phasen getrennt melden. OpenVPN über UDP 1194 bleibt im Verbindungszustand, bis sein Timeout abläuft. OpenVPN über TCP 443 ist der interessante Fall, weil das Portal den TCP-Handshake abschließen und dann mit seiner Weiterleitungsseite antworten kann, sodass Sie einen TLS-Fehler statt einer Zeitüberschreitung sehen.

WireGuard zeigt den Mechanismus am klarsten. Es ist konstruktiv nur UDP, ohne TCP-Rückfall, sodass eine Firewall, die unbekanntes UDP verwirft, den Transport vollständig entfernt. Der Client sendet weiterhin Handshake-Initiationen mit wachsendem Backoff und meldet einen Handshake, der nie abgeschlossen wird. Nichts in dieser Meldung erwähnt WLAN, und nichts darin legt nahe, dass Sie einen Browser öffnen sollten.

Plattformen versuchen den Zustand zu bemerken, bevor es Ihr VPN tut. Windows ruft eine bekannte URL ab, um zu entscheiden, ob es seine Anmeldebenachrichtigung zeigt, Android fragt einen Endpunkt an, der 204 No Content antworten sollte, und Apple-Geräte öffnen ein kleines Fenster für das Captive-Netz. Diese Sonden funktionieren, weil das Portal mit einer Weiterleitung statt dem erwarteten Inhalt antwortet. Dasselbe Verhalten erklärt, wie ein Portal völlig gesund aussehen kann, während Ihr Tunnel tot ist: Sonde und Tunnel werden nach verschiedenen Regeln beurteilt.

Was ein Sitzungsablauf wirklich zurücksetzt

Orte lassen Sitzungen aus Gründen ablaufen, die nichts mit Ihrem VPN-Konto zu tun haben: eine Leerlaufzeitüberschreitung, eine maximale Sitzungslänge, ein neues DHCP-Lease oder eine erneute Assoziierung an einem anderen Zugangspunkt. Wenn der Timer auslöst, verschwindet der Eintrag in der Sitzungstabelle, und der Regelsatz vor der Autorisierung kehrt genau so zurück, wie er beim Check-in war.

Ein etablierter Tunnel überlebt oft lange genug, um gesund zu wirken. Keepalives gehen weiter hinaus, und ob der Client es bemerkt, hängt davon ab, wie er unbeantworteten Verkehr behandelt, sodass die Statusanzeige noch eine Weile grün bleiben kann, nachdem der Pfad weg ist. Dann fällt der Tunnel, und jeder Wiederverbindungsversuch scheitert an denselben blockierten Ports.

An diesem Punkt sagt Ihnen der Client-Fehler, in welcher Phase Sie stecken, wenn Sie ihn genau lesen:

Ein Detail bringt Leute durcheinander: Wenn die Sitzung an eine MAC-Adresse gebunden ist, hilft ein Neuladen der Anmeldeseite möglicherweise nicht. Sie müssen die Assoziierung trennen und erneut beitreten, damit das Portal einen neuen Autorisierungsversuch sieht statt eines abgelaufenen.

Erst anmelden, dann den Tunnel aufbauen

Die Reihenfolge, die funktioniert, ist: Gerät autorisieren, Pfad nachweisen, VPN starten, Tunnel nachweisen, dann Ihre normale Blockierung wiederherstellen. Der letzte Schritt ist wichtig, weil der temporäre Zustand, den Sie brauchen, um das Portal zu erreichen, genau der Zustand ist, den ein Kill Switch verhindern soll.

Ein Desktop-Client mit der Option, außerhalb des Tunnels zu blockieren, muss pausiert werden, damit die Portalseite lädt, und sensible Apps sollten Sie während dieses Fensters außerhalb des Tunnels geschlossen halten; es ist das einzige Intervall, in dem lokaler Verkehr ungeschützt hinausgeht. Ein verwaltetes, immer eingeschaltetes Gerät sollte das Verfahren seines Eigentümers verwenden, statt dass Sie die Richtlinie entfernen. Wenn das Portal eine Zertifikatswarnung zeigt, halten Sie an: Sie anzunehmen leitet Ihre Sitzung durch den Abfang-Proxy des Ortes, und dieser Proxy kann alles lesen, was Sie senden. Unter Android blockiert die Sperre bei immer aktivem VPN Verkehr, bevor der Tunnel steht, und manche Builds können den Portalfluss nicht ausnehmen; wenn Ihres das nicht kann, nutzen Sie den alternativen Zugang des Ortes oder ein anderes Gerät, statt die Sperre ausgeschaltet zu lassen. Apples On-Demand-Regeln lassen sich so schreiben, dass sie den Tunnel verweigern, bis eine Sonde gelingt, und das ist das Verhalten, das Sie in Hotelnetzen wollen.

Prüfen Sie der Reihe nach mit Werkzeugen, die Sie schon haben. Führen Sie vor dem Tunnel die Sonde aus, mit sichtbaren Headern und sichtbarem Body, und beobachten Sie, ob Ihr VPN-Transport überhaupt eine Antwort bekommt:

curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'

Vor der Autorisierung gibt ein normales Portal eine von zwei Antworten: ein 302, dessen Location auf die Anmeldeseite zeigt, oder ein 200 mit einem HTML-Body, der die Portalseite ist. Notieren Sie, welche Sie bekommen haben. Eine Weiterleitung ist vor der Anmeldung kein Fehler; sie sagt Ihnen, wohin Sie gehen sollen. Nachdem das Portal Erfolg meldet, wiederholen Sie den Befehl und erwarten ein 200, dessen Body das wörtliche Wort Success ist. Diese Zeichenkette macht die Sonde aussagekräftig. Wenn der Host normal antwortet, bevor Sie sich je angemeldet haben, gibt es in diesem Netz kein abfangendes Portal. Im Mitschnitt ist ein Verwerfen vor der Autorisierung ausgehender Verkehr, von dem nichts zurückkommt, während ein funktionierender Pfad eine Antwort auf denselben Fluss innerhalb etwa einer Sekunde zeigt. Verbinden Sie sich, und wiederholen Sie dann den Mitschnitt.

Wenn der Tunnel weiter scheitert, nachdem das Portal ja sagt

Anmeldeerfolg ist nicht dasselbe wie erlaubter Transport. Viele Orte erlauben das Portal und normales Surfen, blockieren aber UDP komplett, was WireGuard und UDP-OpenVPN kaputt lässt und TCP 443 funktionieren lässt. Wenn TCP 443 durchgeht und UDP nicht, ist das die Richtlinie des Ortes und kein Client, den Sie falsch konfiguriert haben, also wechseln Sie den Transport oder akzeptieren Sie die Grenze und machen Sie weiter. Wenn eine Wiederverbindung danach immer noch scheitert, behalten Sie den genauen Fehler; er benennt die Phase, in der Sie feststecken.

Andere Fehler leben auf dem Gerät. Eine Sitzung, die noch an eine alte MAC gebunden ist, ein zweiter WLAN-Adapter mit eigenem Lease oder ein Client, der die Zertifikatsausnahme des Portals zwischengespeichert hat, können nach einer sauberen erneuten Autorisierung jeweils weiter scheitern. Trennen Sie die Assoziierung, autorisieren Sie erneut und versuchen Sie es einmal, bevor Sie Client-Einstellungen anfassen. RFC 8952 lohnt sich zu lesen, wenn Sie die Architektur hinter den Komponenten wollen, die Sie beobachten.

Wenn das Portal selbst die Autorisierung verweigert, liegt das Problem beim Konto oder bei der Gerätezuweisung, und keine VPN-Einstellung wird es beheben. Das Ausgangsland des VPN zu wechseln setzt den lokalen Zugangszustand des Ortes nicht zurück; diese Tabelle ist an Ihr Gerät gebunden, nicht an den Server, den Sie wählen. Fragen Sie den Betreiber des Ortes und geben Sie ihm Zeit, denn die Sitzungstabelle ist das, was er ansehen wird.

Schreiben Sie vor Ihrer nächsten Reise drei Dinge auf: die Portalseite als Schritt null, den Schritt zum Pausieren der Blockierung für jedes Gerät, das Sie mitnehmen, und einen Transport-Rückfall, den Sie tatsächlich getestet haben. Wenn ein Tunnel, der vor zehn Minuten funktionierte, wieder stoppt, behandeln Sie das als abgelaufene Autorisierung und prüfen Sie das Portal erneut, bevor Sie das VPN-Profil anfassen.