Waarom leidt een hotspot DNS om voordat de VPN verbindt?
Een hotspot herschrijft opzoekingen in zijn eigen netwerk, en een hostnaam-eindpunt wordt opgelost voordat er ooit een tunnel bestaat. Volg welke resolver elk verzoek heeft beantwoord.
Verbinden met een hotelnetwerk plaatst twee DNS-beslissingen op verschillende momenten voor je: de opzoekingen die het apparaat doet tijdens het inloggen, en de opzoekingen die worden gedaan zodra de tunnel staat. Een hotspot kan de eerste beïnvloeden via het netwerk dat hij beheert. De tweede hangen af van het beleid van de client zelf, wat iets aparts is om te onderzoeken.
Loop de verbinding op volgorde door, van de eerste DHCP-lease tot de query die een privénaam oploste. Dan scheiden twee storingen die er in een supportticket identiek uitzien zich netjes: de ene gebeurde voordat de tunnel bestond, de andere erbinnen.
Wat de hotspot wel en niet kan aanraken
Het toegangsnetwerk deelt via DHCP een resolveradres uit en kan poort 53 naar dat adres onderscheppen. Dat is genoeg om elk onbeschermd verzoek te beantwoorden met een portaaladres of een blokkeerpagina. Het is ook genoeg om een VPN-client te breken waarvan het eindpunt als hostnaam is geschreven.
Wat de hotspot niet kan, is een query lezen of herschrijven zodra die binnen een gevestigde tunnel reist, ervan uitgaande dat de tunnel hem echt draagt. Onderschepping hangt af van het zien van de vraag in platte tekst.
Verzoeken verlaten de tunnel toch om redenen die niets met de hotspot te maken hebben: de beveiligde DNS-instelling van de browser, een split-DNS-regel die een bedrijfssuffix bij de lokale resolver houdt, of een client die is geconfigureerd om DNS van de tunnel uit te sluiten. Elk is een keuze aan de clientkant, en elk ziet er van buitenaf uit als storing door de hotspot.
| 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 |
De eerste opzoeking gebeurt voordat de tunnel bestaat
Een client die een hostnaam krijgt, moet die eerst oplossen, en op dat moment beschermt geen enkele tunnel het verzoek. Antwoordt de hotspot met een portaaladres, dan mislukt de onderhandeling of blijft die hangen. Antwoordt hij met niets, dan meldt de client een naamfout en de tunnel start nooit. Elk van beide uitkomsten verklaart een leeg tunnellog dat er anders onschuldig uitziet.
Besturingssystemen voeren ook hun eigen connectiviteitscontroles en portaalontdekking uit, beschreven in RFC 8910 en RFC 8952, en die verzoeken vertrekken voordat enige VPN staat. Ze in een proxylog zien is verwacht gedrag en geen bewijs van een lek.
De praktische oplossing is de client een eindpunt te geven dat geen opzoeking nodig heeft. Als dat onmogelijk is, rond dan eerst de aanmelding af en verbind daarna.
Zoek uit welke resolver antwoordde
Vraag het systeem en niet de browser, en voer de query twee keer uit: één keer via welke resolver het apparaat nu ook gebruikt, één keer tegen een vast adres.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Een antwoord van de eerste opdracht dat afwijkt van het derde, vertelt je dat de lokale resolver iets anders teruggeeft, wat een omleidende hotspot precies doet. Een fout van het derde samen met een succes van het eerste wijst op het portaal: de lokale resolver serveerde een inlogadres terwijl de uitgaande poort 53 werd weggegooid. Time-outs op beide betekenen dat het netwerk DNS weggooit tot de authenticatie is voltooid.
Herhaal het na het verbinden en vergelijk. Een gecachet antwoord overleeft de overgang, dus leeg de cache of vraag een nieuwe naam voor de tweede waarneming.
Houd latere opzoekingen op het pad dat je bedoelde
Een volledige-tunnelprofiel dat ook DNS opvangt, is de eenvoudigste opzet: elk verzoek van elke toepassing gaat naar de resolver die de tunnel opdringt, en het lokale netwerk ziet alleen versleuteld verkeer. Bewijs het door na het verbinden een interne en een openbare naam op te lossen en dan beide antwoorden te vergelijken met wat de tunnelresolver op zichzelf teruggeeft.
Split-DNS heeft een met opzet geschreven domeinlijst nodig: bedrijfssuffixen via de tunnel, al het overige lokaal, en geen overlap tussen beide.
Beveiligde DNS van de browser staat buiten dat beleid, dus als het uit moet om het profiel voorspelbaar te laten werken, schakel het dan voor dat profiel uit en niet voor de machine. Doe dat in de browserinstellingen, niet door de systeemresolver te bewerken, zodat de wijziging de volgende keer zichtbaar is. Noteer het antwoord, de resolver en de verbindingsfase op één regel per test. Een rapport dat zegt dat DNS faalde op hotel-Wi-Fi, beschrijft een symptoom met minstens drie verschillende oorzaken.