Warum leitet ein Hotspot DNS um, bevor die VPN-Verbindung steht?
Ein Hotspot schreibt Namensauflösungen in seinem eigenen Netz um, und ein Endpunkt als Hostname wird aufgelöst, bevor irgendein Tunnel existiert. Verfolgen Sie, welcher Resolver welche Anfrage beantwortet hat.
Der Beitritt zu einem Hotelnetz stellt Sie zu verschiedenen Zeitpunkten vor zwei DNS-Entscheidungen: die Auflösungen, die das Gerät beim Anmelden ausführt, und die Auflösungen, die erfolgen, sobald der Tunnel steht. Ein Hotspot kann die ersten über das Netz beeinflussen, das er kontrolliert. Die zweiten hängen von der eigenen Richtlinie des Clients ab, was separat zu prüfen ist.
Gehen Sie die Verbindung der Reihe nach durch, vom ersten DHCP-Lease bis zur Abfrage, die einen privaten Namen aufgelöst hat. Dann trennen sich zwei Fehler sauber, die in einem Support-Ticket identisch aussehen: Der eine geschah, bevor der Tunnel existierte, der andere in ihm.
Was der Hotspot anfassen kann und was nicht
Das Zugangsnetz verteilt per DHCP eine Resolver-Adresse und kann Port 53 in Richtung dieser Adresse abfangen. Das genügt, um jede ungeschützte Abfrage mit einer Portaladresse oder einer Sperrseite zu beantworten. Es genügt auch, um einen VPN-Client zu brechen, dessen Endpunkt als Hostname geschrieben ist.
Was der Hotspot nicht kann, ist eine Abfrage zu lesen oder umzuschreiben, sobald sie in einem etablierten Tunnel unterwegs ist, vorausgesetzt, der Tunnel trägt sie wirklich. Abfangen setzt voraus, die Frage im Klartext zu sehen.
Abfragen verlassen den Tunnel dennoch aus Gründen, die nichts mit dem Hotspot zu tun haben: die sichere DNS-Einstellung des Browsers, eine Split-DNS-Regel, die eine Unternehmensendung beim lokalen Resolver belässt, oder ein Client, der so konfiguriert ist, DNS vom Tunnel auszunehmen. Jede ist eine Entscheidung auf Clientseite, und jede sieht von außen wie eine Störung durch den Hotspot aus.
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
Die erste Auflösung geschieht, bevor der Tunnel existiert
Ein Client, der einen Hostnamen erhält, muss ihn zuerst auflösen, und in diesem Moment schützt kein Tunnel die Abfrage. Antwortet der Hotspot mit einer Portaladresse, scheitert die Verhandlung oder hängt. Antwortet er mit nichts, meldet der Client einen Namensfehler und der Tunnel startet nie. Beide Ausgänge erklären ein leeres Tunnelprotokoll, das sonst harmlos aussieht.
Betriebssysteme führen auch eigene Konnektivitätsprüfungen und Portalererkennung aus, beschrieben in RFC 8910 und RFC 8952, und diese Anfragen gehen hinaus, bevor irgendein VPN steht. Sie im Proxy-Protokoll zu sehen ist erwartetes Verhalten und kein Beweis für ein Leck.
Die praktische Lösung ist, dem Client einen Endpunkt zu geben, der keine Auflösung braucht. Wenn das unmöglich ist, schließen Sie zuerst die Anmeldung ab und verbinden Sie danach.
Finden Sie heraus, welcher Resolver geantwortet hat
Fragen Sie das System und nicht den Browser, und führen Sie die Abfrage zweimal aus: einmal über den Resolver, den das Gerät gerade nutzt, einmal gegen eine feste Adresse.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Eine Antwort des ersten Befehls, die sich vom dritten unterscheidet, sagt Ihnen, dass der lokale Resolver etwas anderes zurückgibt, was ein umleitender Hotspot gerade tut. Ein Fehler des dritten zusammen mit einem Erfolg des ersten deutet auf das Portal hin: Der lokale Resolver lieferte eine Anmeldeadresse, während ausgehender Port 53 verworfen wurde. Zeitüberschreitungen bei beiden bedeuten, dass das Netz DNS verwirft, bis die Authentifizierung abgeschlossen ist.
Wiederholen Sie es nach dem Verbinden und vergleichen Sie. Eine zwischengespeicherte Antwort überlebt den Übergang, also leeren Sie den Cache oder fragen Sie für die zweite Beobachtung einen neuen Namen ab.
Halten Sie spätere Auflösungen auf dem beabsichtigten Weg
Ein Volltunnel-Profil, das auch DNS erfasst, ist die einfachste Anordnung: Jede Abfrage jeder Anwendung geht an den Resolver, den der Tunnel vorgibt, und das lokale Netz sieht nur verschlüsselten Verkehr. Beweisen Sie es, indem Sie nach dem Verbinden einen internen und einen öffentlichen Namen auflösen und dann beide Antworten mit dem vergleichen, was der Resolver des Tunnels allein zurückgibt.
Split-DNS braucht eine mit Absicht geschriebene Domänenliste: Unternehmensendungen durch den Tunnel, alles andere lokal, und keine Überschneidung zwischen beidem.
Sicheres DNS im Browser steht außerhalb dieser Richtlinie, wenn es also aus sein muss, damit sich das Profil vorhersagbar verhält, schalten Sie es für dieses Profil ab und nicht für den Rechner. Tun Sie das in den Browsereinstellungen und nicht durch Bearbeiten des System-Resolvers, damit die Änderung beim nächsten Mal sichtbar ist. Notieren Sie Antwort, Resolver und Verbindungsphase in einer Zeile pro Test. Ein Bericht, dass DNS im Hotel-WLAN versagt habe, beschreibt ein Symptom mit mindestens drei verschiedenen Ursachen.