Hotel-WLAN: Das VPN scheitert, bevor es den Server überhaupt erreicht

Der VPN-Client dreht sich, meldet dann, dass er den Server nicht erreichen kann, und alle schließen daraus, das Hotel blockiere VPNs. Meist ist nichts so Dramatisches passiert: Das Netz hat Sie noch nicht hinausgelassen. Ein Captive Portal hält jede Verbindung zurück, bis Sie sich anmelden, und ein Tunnel kann nicht zustande kommen, solange eine Anmeldeseite seine Pakete abfängt. Gehen Sie die Anmeldung durch, bevor Sie den Tunnel beschuldigen.

Der Mythos: Das Hotel blockiert VPNs

Die meisten Hotelnetze filtern Tunnel nicht gezielt. Sie fangen Webverkehr ab, bis der Gast sich authentifiziert, und sie können außerdem Geräte begrenzen, Sitzungen ablaufen lassen oder den Durchsatz drosseln. Jedes davon erzeugt einen Fehler, der aus dem Inneren eines VPN-Clients wie eine Blockade aussieht.

Der Tunnel ist hier ein schlechtes Diagnosewerkzeug, denn er ist die eine Anwendung, die garantiert scheitert, solange das Portal nicht freigegeben ist. Gewöhnlicher Webzugriff ist der bessere Indikator, weil er Ihnen die Anmeldeseite selbst zeigen kann.

Diese Reihenfolge ist aus einem weiteren Grund wichtig: Ein Client mit Kill Switch oder Always-on-Modus wird das Laden des Portals verweigern, und der Nutzer schließt daraus, das Netz sei defekt statt die Einstellung. Beide Tatsachen stimmen gleichzeitig, und nur eine davon lässt sich im Hotel ändern. Schalten Sie den Schutz über die eigene Steuerung des Clients aus, melden Sie sich an und schalten Sie ihn wieder ein. Alles andere ist ein Umweg, der die echte Abfolge verdeckt.

Schließen Sie zuerst das Portal ab, dann testen Sie gewöhnliches HTTPS

Fragen Sie das Personal nach dem offiziellen Netznamen und der Anmeldemethode. Eine überzeugende SSID ist kein Eigentumsnachweis, und ein zweites Netz mit ähnlichem Namen ist an öffentlichen Orten ein üblicher Trick. Nutzen Sie die eigene Anmeldeabfrage des Betriebssystems, wo sie angeboten wird, oder die dokumentierte Seite des Hotels.

curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://captive.apple.com/hotspot-detect.html
curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/

Die erste Anfrage fragt einen bekannten Erkennungsendpunkt für Captive Portale über einfaches HTTP ab; eine Weiterleitung oder ein unerwarteter Inhalt bedeutet, dass Sie noch hinter dem Portal stehen. Die zweite testet eine normale HTTPS-Seite. Zeigt die erste eine Abfangung und scheitert die zweite, ist die Anmeldung unvollständig und das VPN hat nichts damit zu tun.

Auf einem persönlichen Gerät muss der Kill Switch oder das Always-on-VPN möglicherweise über die unterstützte Steuerung des Clients ausgeschaltet werden, damit das Portal laden kann. Schließen Sie in diesem Zeitfenster sensible Anwendungen und schalten Sie den Schutz unmittelbar danach wieder ein. Auf einem verwalteten Gerät verwenden Sie das vom Administrator freigegebene Verfahren, statt selbst eine Richtlinie zu entfernen.

Umgehen Sie niemals eine Zertifikatswarnung und installieren Sie kein unbekanntes Zertifikat und kein Hilfsprogramm, um online zu kommen. Verlangt das Portal etwas Unerwartetes, bestätigen Sie es mit dem Personal und mit dem Administrator, wenn das Gerät einem Arbeitgeber gehört.

Bewahren Sie das ursprüngliche Profil und seinen Fehler auf

Sobald der gewöhnliche Zugriff funktioniert, verbinden Sie das ursprüngliche Profil und notieren Sie den genauen Fehler. Eine Authentifizierungsablehnung ist ein Kontoproblem, eine Zeitüberschreitung während der Aushandlung ein Pfadproblem, und ein Tunnel, der aufgebaut wird, aber nichts überträgt, ein Routing- oder Richtlinienproblem.

Diese drei brauchen unterschiedliche nächste Schritte, und ein Screenshot des Fehlers ist mehr wert als eine Beschreibung. Notieren Sie auch die Uhrzeit, denn Hotelsitzungslimits können innerhalb einer Stunde ablaufen und einen Fehler erzeugen, der zufällig wirkt. Bietet der Client ein Protokoll, behalten Sie den Abschnitt um den ersten Fehler statt der ganzen Datei. Dieser Auszug genügt meist dem, der das Profil besitzt, um die Phase zu bestimmen.

Wenn gewöhnlicher Zugriff funktioniert und die Aushandlung weiterhin abläuft, fragen Sie das Hotel, ob es den Verkehr unterstützt, und vergleichen Sie mit einem vertrauenswürdigen Hotspot, wobei Gerät und Profil unverändert bleiben. Die Arbeit am Hotspot lenkt den Blick auf den Hotelpfad, ohne etwas über das Profil zu beweisen.

Verwenden Sie nur Alternativen, die der Betreiber bereitstellt

Ein passendes TCP-Profil kann dort gelingen, wo der angebotene UDP-Pfad scheitert, aber nur wenn der Server tatsächlich auf diesem Transport und Port lauscht. TCP-Port 443 wird nicht automatisch als gewöhnliches HTTPS behandelt, und er ist keine Garantie für die Passage durch ein restriktives Netz.

sudo openvpn --config /etc/openvpn/client/office-tcp.conf --verb 4

Das bereitgestellte Profil mit höherer Ausführlichkeit zu starten hält den ersten brauchbaren Fehler sichtbar, statt ihn in einem allgemeinen Fehlerdialog verschwinden zu lassen. Verwenden Sie die Datei des Betreibers, statt Ports oder Protokolle selbst zu ändern, denn eine lokale Änderung kann auf der Gegenseite keinen passenden Listener erzeugen.

Wenn der Tunnel wiederholt zurückgesetzt wird, notieren Sie, ob das Portal wieder erscheint oder das lokale Signal abfällt, und folgen Sie den Stabilitätsprüfungen, statt mehrere Protokolle gleichzeitig zu wechseln. Testen Sie dann die Anwendung, die Sie wirklich brauchen, und stellen Sie die normalen Datenschutzkontrollen wieder her. Eine Verbindung, die eine Seite trägt, aber eine andere nicht, ist eine Routing- oder Richtlinienfrage, keine Portalfrage.

Prüfen Sie schließlich die Wiederherstellung nach dem Ruhezustand des Laptops. Die Portalautorisierung kann unabhängig vom Tunnel ablaufen, sodass ein Gerät, das sich automatisch neu verbindet, zu einem Netz zurückkehren kann, das es bereits vergessen hat. Die Portalseite erneut zu öffnen ist ein normaler Schritt, kein Zeichen dafür, dass das VPN defekt ist.