Testen Sie einen Hotspot, bevor Arbeitszugangsdaten in seine Nähe kommen

Der Hotspot vergibt eine Adresse, bevor er das Internet vergibt, und das Vertrauen entscheidet sich genau in dieser Lücke. Das Gerät assoziiert, fragt nach einer Adresse, und dann wird jede ausgehende Anfrage abgefangen, bis ein Portal meldet, die Sitzung sei autorisiert. Dieser Mechanismus erklärt, warum eine Seite scheinbar lädt, obwohl keine echte Verbindung besteht. Prüfen Sie die Lücke mit etwas Harmlosem, bevor ihr irgendein Arbeitszugangsdatum nahekommt.

Was der Hotspot mit Ihrer ersten Anfrage macht

Die Assoziation gibt dem Gerät eine Verbindung, und DHCP gibt ihm eine Adresse, ein Gateway und meist einen DNS-Server, der dem Ort gehört. Bis die Autorisierung abgeschlossen ist, verwirft oder leitet das Gateway ausgehenden Verkehr um, und viele Portale beantworten DNS für jeden Namen mit ihrer eigenen Adresse. Deshalb scheint eine Auflösung zu gelingen: Die Antwort ist das Portal, nicht die angefragte Seite. Das Netz verhält sich wie entworfen; es ist nur noch nicht das Internet.

Die erste HTTP-Anfrage erhält normalerweise eine Weiterleitung zum Portal, die das Betriebssystem für Sie öffnen kann. HTTPS lässt sich so nicht umleiten, also scheitert es oder hängt, und der Browser zeigt einen Zertifikatsfehler oder eine Zeitüberschreitung. Der Unterschied ist diagnostisch: Eine HTTP-Weiterleitung ist das Portal, das spricht, während ein TLS-Fehler zu einem fremden Host etwas anderes ist. Ein ummauerter Garten, in dem einige wenige Domains für Zahlung oder Anmeldung durchgelassen werden, erzeugt ein drittes Muster.

Bestätigen Sie das Netz, bevor Sie sich anmelden

Bestätigen Sie SSID und Anmeldeverfahren beim Ort über einen Kanal, der nicht das Netz selbst ist. Ein Portal, das ein Firmenpasswort, eine Kartennummer und eine E-Mail-Adresse verlangt tut drei verschiedene Dinge, und nur die letzten beiden sind für Gästezugang üblich. Bevorzugen Sie die Hinweismeldung des Betriebssystems zum Captive Portal, die die Weiterleitung über einen bekannten Endpunkt erkennt, statt einer beliebigen erscheinenden Seite zu vertrauen. Kann der Ort sein eigenes Portal nicht beschreiben, ist das ein Grund zu warten statt zu improvisieren.

Eine Zertifikatswarnung bei der Portalanmeldung ist kein Schritt, den man wegklickt. Das Portal muss keinen fremden Host nachahmen, um Sie zu authentifizieren.

Führen Sie die kleinste Prüfung durch, die Zugang beweist

Schließen Sie die legitime Autorisierung ab, fordern Sie dann eine gewöhnliche öffentliche HTTPS-Seite an, die Sie noch nicht geladen haben, damit die Antwort nicht aus dem Cache kommen kann. Notieren Sie, was tatsächlich fehlgeschlagen ist, falls es fehlschlägt: eine Namensauflösung, ein Verbindungs-Timeout, ein Zertifikatsfehler oder eine Dienstverweigerung. Diese vier gehören zu verschiedenen Schichten, und sie aufzuschreiben hindert die nächste Person daran, nach Gefühl erneut zu testen. Verbinden Sie dann das vorgesehene VPN und fordern Sie eine Ressource an, die es erfordert.

Halten Sie den Test klein. Ein Speedtest-Download über getakteten Zugang beantwortet eine Frage, die niemand gestellt hat, und kann den Nutzer Geld kosten. Eine Antwort mit Headern reicht aus, um Erreichbarkeit zu belegen, und sie zieht keine Megabytes durch eine Leitung, die pro Gigabyte abrechnet.

Wenn gewöhnlicher Zugang funktioniert und der Tunnel nicht, ist das eine andere Untersuchung als bei einem Netz, das nie autorisiert hat. Halten Sie die beiden Ergebnisse getrennt, statt mehrere Datenschutzeinstellungen auf einmal zu ändern.

Halten Sie private Arbeit aus dem Vergleich heraus

Jede App auf dem Gerät ist ein möglicher Beobachter, und ein Captive Portal ist der Moment, in dem alle ihre Server zu erreichen versuchen. Schließen Sie die, die Sie können, und behandeln Sie ein verwaltetes, ständig aktives Gerät als Richtlinienfrage statt als technische: Nutzen Sie die freigegebene Methode für den Vergleich, statt den Schutz zu entfernen, der es verwaltet macht. Wenn das Gerät Verkehr außerhalb des Tunnels ganz verbietet, führen Sie die Prüfung auf einem anderen, unkritischen Gerät durch. Der Sinn der Übung ist, das Netz kennenzulernen, ohne ihm Zugangsdaten auszusetzen.

Erfassen Sie nicht den Verkehr anderer Leute, um den Ort zu diagnostizieren, und halten Sie jede diagnostische Aufzeichnung im Rahmen Ihres eigenen Geräts und Ihrer Sitzung. Prüfen Sie Adress- und Kennungsfelder, bevor Sie eine Aufzeichnung an ein Ticket hängen, denn das Netz des Ortes ist kein Beweismittelschrank.

Entscheiden Sie, was das Ergebnis Ihnen erlaubt

Drei Ergebnisse sind möglich: voller Zugang mit funktionierendem Tunnel, Zugang nur zum Portal mit scheiterndem Tunnel oder gar kein Zugang. Jedes hat einen anderen nächsten Schritt, und der Wert des Tests liegt darin, zu wissen, in welchem Sie sind, bevor Sie Einstellungen ändern. Voller Zugang bedeutet, dass Arbeit durch den Tunnel weitergehen kann; Zugang nur zum Portal deutet darauf hin, dass Port oder Protokoll des Tunnels blockiert sind, also ist ein anderer Transport oder ein anderes Netz die Antwort; kein Zugang bedeutet, dass der Ort die Aufgabe heute nicht unterstützen kann. Ein Gerät, das immer nur ein Protokoll versucht, kann diese nicht unterscheiden.

Notieren Sie SSID, Ergebnis und Uhrzeit, damit die nächste Person am selben Ort mit Belegen beginnt. Apples Leitfaden zu Captive Networks beschreibt das Erkennungsverhalten hinter der Meldung, und das ist der Teil, den man verstehen sollte, bevor man das VPN beschuldigt.