Wi-Fi-Portal- und VPN-Anmeldungen auseinanderhalten

Zwei verschiedene Systeme verlangen Ihre Anmeldung, bevor Sie in einem öffentlichen Netz etwas Nützliches erreichen: das Wi-Fi des Ortes und Ihr VPN-Gateway. Auf dem Bildschirm sehen sie gleich aus und autorisieren völlig verschiedene Dinge. Das Portal entscheidet, ob dieses Gerät das lokale Netz nutzen darf; das VPN entscheidet, ob Sie ein privates Netz anderswo erreichen dürfen. Ich halte sie auseinander, indem ich jedem Fenster eine Frage stelle: Wer kann dieses Geheimnis tatsächlich prüfen? Was folgt, ist die Checkliste, die ich in Hotels, Flughäfen und Konferenzzentren durchgehe, einschließlich der Punkte, an denen ich aufhöre zu tippen.

Ordnen Sie jede Anmeldung dem prüfenden Dienst zu

Eine einzelne Hotelverbindung kann vier getrennte Prüfungen umfassen, und nur einige wollen eine Eingabe von Ihnen. Bringen Sie sie zuerst in eine Reihenfolge, denn der Bildschirm sagt selten, zu welcher Stufe er gehört.

802.1X-Netze, verbreitet in Büros und Universitäten, verwischen die ersten beiden Zeilen. Dort ist die Wi-Fi-Anmeldung selbst eine Identitätsprüfung gegen einen RADIUS-Server, und der Client kann eine Routing-Identität vorlegen, während das eigentliche Konto innerhalb des verschlüsselten Austauschs reist. Selbst dann geht es um den Beitritt zum Netz; sie autorisiert nicht den Tunnel, und das VPN-Gateway akzeptiert sie nicht als Beweis für irgendetwas.

Die Reihenfolge zählt mehr als die Bezeichnungen. Captive Portale gibt es, weil Zugang nach dem Verbinden gewährt werden kann, weshalb ein Ort die Seite an einen spezialisierten Anbieter übergeben kann. RFC 8952 der IETF behandelt das Portal als eigene Komponente, daher ist eine unbekannte Domain ein Grund zu prüfen, nicht schon ein Beweis für Betrug. Prüfen Sie die Domain gegen die schriftlichen Anweisungen des Ortes und die Felder gegen die Tabelle.

Prüfen Sie, wonach ein Portal fragen darf

Portalfelder betreffen den Anspruch, nicht die Identität: Zimmernummer, Buchungsnachname, Gutscheincode, der auf der Schlüsselhülle gedruckte Code, eine E-Mail für einen zeitlich begrenzten Pass, Zustimmung zu Bedingungen. Der Ort weiß bereits, wer das Zimmer gebucht hat, und kann diese Angaben abgleichen, ohne etwas zu erfahren, das ihm erlauben würde, anderswo als Sie zu handeln.

Alles über diese Liste hinaus verdient eine Pause. Eine Hotspot-Seite kann Ihr Domänenpasswort nicht prüfen, und sie kann auch Ihren Einmalcode für das VPN, einen Wiederherstellungscode oder einen privaten Schlüssel nicht prüfen, und sie hat keinen Grund, sie zu wollen. Die einzige legitime Ausnahme ist ein organisationsbetriebenes Netz: ein Gäste-SSID im Büro oder ein Konferenz-Wi-Fi kann Sie an den Identitätsanbieter weiterreichen, den Sie bereits für die Arbeit nutzen. Es bleibt unterscheidbar: der Anmeldehost ist Ihr täglicher, der Zustimmungsbildschirm nennt Ihren Tenant, und der Ablauf öffnet sich in einem sichtbaren Browser-Tab.

Marketing-E-Mail ist etwas anderes: ein Reise-Alias erfüllt das Feld, ohne Ihre Arbeitsidentität herauszugeben.

Prüfen Sie, ob der VPN-Client eigene Zugangsdaten will

Der Client fragt genau das ab, wofür sein Profil konfiguriert ist, daher ist das erwartete Fenster eine Eigenschaft des Profils und nicht des Netzes, in dem Sie sich gerade befinden. Zertifikatsprofile zeigen meist eine Profilauswahl und verbinden dann still. Benutzername-und-Passwort-Profile fragen beides ab, oft mit Einmalcode. SSO-Profile öffnen Ihren Browser beim Identitätsanbieter und kehren mit einem Token zurück. WireGuard ist wieder anders: es authentifiziert Geräte per öffentlichem Schlüssel und hat keine Benutzeranmeldung, ein Fenster mit WireGuard-Benutzername und -Passwort beschreibt also nicht WireGuard.

Lesen Sie das Profil, bevor Sie reisen. In OpenVPN sagt Ihnen auth-user-pass, dass eine Passwortabfrage erwartet wird, während cert, key oder pkcs12 bedeutet, dass ein Zertifikat die Arbeit tun sollte. Wenn ein Profil, das sich sonst ohne Abfrage verbindet, plötzlich ein Passwort verlangt, vermuten Sie ein Profil, das sein Zertifikat nicht laden konnte oder auf eine andere Methode zurückgefallen ist. Eine Abfrage ist keine Einladung, Ihr Arbeitspasswort in irgendein erschienenes Fenster zu tippen.

Kein legitimer VPN-Client verlangt die Zimmernummer, den Portal-Gutschein oder die Wi-Fi-Passphrase als Eingabe für die Authentifizierung. Wenn das passiert, ist der Client entweder nicht, was er vorgibt zu sein, oder ein Captive Portal fängt den Verkehr ab, bevor der Tunnel entsteht, und Sie lesen eine HTML-Seite, die wie eine Anmeldung gestaltet ist.

Halten Sie bei diesen fünf Bedingungen an

Das sind die Punkte, an denen ich anhalte, statt mit einem plausiblen Workaround weiterzumachen. Jeder ist billig zu prüfen und teuer, wenn er danebengeht.

1. Auf dem Portal oder der SSO-Seite erscheint eine Zertifikats- oder TLS-Warnung. Klicken Sie sich nicht durch, um ins Netz zu gelangen.
2. Die Seite verlangt ein Geheimnis, das nur das VPN-Gateway oder der Identitätsanbieter prüfen kann: Domänenpasswort, Einmalcode, Wiederherstellungscode, privater Schlüssel.
3. Die Domain stimmt weder mit den gedruckten Anweisungen des Ortes noch mit dem Anmeldehost überein, den Ihre Organisation für ihre eigenen Dienste dokumentiert.
4. Sie sollen ein Root-Zertifikat, ein Konfigurationsprofil oder eine Hilfsanwendung installieren, die nicht aus Ihrer Geräteverwaltung stammt.
5. Eine MFA-Bestätigung trifft ein, die Sie nicht gestartet haben, oder der VPN-Client verlangt Hotel-Zugangsdaten.

Der Rückfallweg ist kein anderes Passwort. Nutzen Sie einen Handy-Hotspot, fragen Sie an der Rezeption nach dem genauen Netzwerknamen und der Zugangsmethode und melden Sie die Seite demjenigen, der das Netz betreibt, oder Ihrem IT-Desk. Nichts davon verlangt, einen Zugangsdatensatz gegen eine Seite zu testen, die Sie nicht zuordnen können.

Ordnen Sie einen Fehler der richtigen Stufe zu

Wenn beide Stufen bestanden sind, passieren Fehler trotzdem, und die Fehlermeldung nennt meist die Stufe, wenn man sie in der Reihenfolge liest: Verbindung, Adresszuweisung, Portalautorisierung, Tunnelaufbau, dann die interne Ressource. Ein VPN-Passwort zu ändern, weil ein Portal-Code abgelaufen ist, kostet Zeit und lässt das eigentliche Problem bestehen.

Ein paar Tests trennen die Stufen. Fordern Sie nach der Portalanmeldung eine gewöhnliche öffentliche HTTPS-Seite an. Kommt stattdessen das Portal zurück, wurde die Autorisierung auf dieser Ebene nie abgeschlossen. Meldet der VPN-Client, dass er das Gateway nicht erreicht, sitzt das Problem unter dem Tunnel: die Portalsitzung, die Namensauflösung oder ein Netz, das den Port blockiert. Kommt der Tunnel hoch und scheitert ein interner Hostname, sind Namensauflösung oder Richtlinien im privaten Netz der bessere Verdacht.

Portalsitzungen laufen auch unabhängig vom Tunnel ab. Wenn der Ort den Zugang widerruft, fällt eine bestehende VPN-Verbindung, obwohl ihre Zugangsdaten nie falsch waren. Autorisieren Sie das Portal erneut, verbinden Sie dann das VPN neu und lassen Sie es neu verhandeln. Das VPN-Passwort dann zu wechseln, behebt nichts und kann Sie aussperren.

Geben Sie jedes Geheimnis nur dem System, das es prüfen kann, und behandeln Sie eine Abfrage, die nicht zur Tabelle passt, als Stoppschild statt als Schritt, den man umgeht. Wenn beide Stufen bestehen und der Tunnel trotzdem ablehnt, erfassen Sie den genauen Client-Fehler, bevor Sie einen Zugangsdatensatz ändern.