Waarom herlei ’n hotspot DNS voordat die VPN verbind?
’n Hotspot herskryf opsoeke op sy eie netwerk, en ’n gasheernaam-eindpunt word opgelos voordat enige tonnel bestaan. Spoor na watter oplosser elke navraag beantwoord het.
Om by ’n hotelnetwerk aan te sluit, plaas twee DNS-besluite op verskillende oomblikke voor jou: die opsoeke wat die toestel maak terwyl jy aanmeld, en die opsoeke wat gedoen word nadat die tonnel op is. ’n Hotspot kan die eerste beïnvloed deur die netwerk wat hy beheer. Die tweede hang van die kliënt se eie beleid af, wat ’n aparte ding is om te ondersoek.
Stap die verbinding in volgorde deur, van die eerste DHCP-toekenning tot die navraag wat ’n private naam opgelos het. Twee foute wat in ’n ondersteuningsversoek identies lyk, skei dan skoon: een het gebeur voordat die tonnel bestaan het, en die ander het binne-in dit gebeur.
Wat die hotspot kan en nie kan raak nie
Die toegangsnetwerk deel ’n oplosseradres in DHCP uit en kan poort 53 na daardie adres onderskep. Dit is genoeg om elke onbeskermde opsoek met ’n portaaladres of ’n blokkeerblad te beantwoord. Dit is ook genoeg om ’n VPN-kliënt te breek wie se eindpunt as ’n gasheernaam geskryf is.
Wat die hotspot nie kan doen nie, is om ’n navraag te lees of te herskryf sodra dit binne ’n gevestigde tonnel beweeg, mits die tonnel dit werklik dra. Onderskepping hang daarvan af om die vraag in gewone teks te sien.
Navrae verlaat nietemin die tonnel om redes wat nie met die hotspot verband hou nie: die blaaier se veilige-DNS-instelling, ’n split-DNS-reël wat ’n korporatiewe agtervoegsel op die plaaslike oplosser hou, of ’n kliënt wat ingestel is om DNS van die tonnel uit te sluit. Elkeen is ’n kliëntkant-keuse, en elkeen lyk soos hotspot-inmenging wanneer dit van buite bekyk word.
| 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 aanvanklike opsoek gebeur voordat die tonnel bestaan
’n Kliënt wat ’n gasheernaam kry, moet dit eers oplos, en op daardie oomblik beskerm geen tonnel die navraag nie. As die hotspot met ’n portaaladres antwoord, misluk die onderhandeling of hang dit. As dit met niks antwoord, rapporteer die kliënt ’n naamfout en die tonnel begin nooit nie. Enige van die uitkomste verduidelik ’n leë tonnellaars wat andersins onskuldig lyk.
Bedryfstelsels voer ook hul eie konnektiwiteitskontroles en portaalontdekking uit, beskryf in RFC 8910 en RFC 8952, en daardie versoeke vertrek voordat enige VPN op is. Om hulle in ’n proxy-log te sien, is verwagte gedrag eerder as bewys van ’n lek.
Die praktiese oplossing is om die kliënt ’n eindpunt te gee wat geen opsoek nodig het nie. Wanneer dit onmoontlik is, voltooi eers die aanmelding en verbind daarna.
Vind uit watter oplosser geantwoord het
Vra die stelsel eerder as die blaaier, en voer die navraag twee keer uit: een keer deur watter oplosser die toestel tans ook al gebruik, een keer teen ’n vaste adres.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
’n Antwoord van die eerste opdrag wat van die derde verskil, sê vir jou die plaaslike oplosser gee iets anders terug, wat is wat ’n herleidende hotspot doen. ’n Fout van die derde saam met ’n sukses van die eerste wys na die portaal: die plaaslike oplosser het ’n aanmeldadres bedien terwyl uitgaande poort 53 laat val is. Timeouts op albei beteken die netwerk verwerp DNS totdat verifikasie voltooi is.
Herhaal nadat jy gekoppel het en vergelyk. ’n Gekasde antwoord oorleef die oorgang, so spoel die kas of vra ’n nuwe naam vir die tweede waarneming.
Hou latere opsoeke op die pad wat jy bedoel het
’n Volledige-tonnel-profiel wat ook DNS vang, is die eenvoudigste reëling: elke navraag van elke toepassing gaan na die oplosser wat die tonnel stoot, en die plaaslike netwerk sien net versleutelde verkeer. Bewys dit deur ná die verbinding ’n interne naam en ’n publieke een op te los en dan albei antwoorde te vergelyk met wat die tonneloplosser op sy eie teruggee.
Split-DNS het ’n domeinlys nodig wat met opset geskryf is: korporatiewe agtervoegsels deur die tonnel, alles anders plaaslik, en geen oorvleueling tussen die twee nie.
Blaaier-veilige DNS staan buite daardie beleid, so as dit af moet wees sodat die profiel voorspelbaar werk, skakel dit vir daardie profiel af eerder as vir die masjien. Doen dit in die blaaier se instellings, nie deur die stelseloplosser te redigeer nie, sodat die verandering volgende keer sigbaar is. Teken die antwoord, die oplosser en die verbindingstadium in een reël per toets aan. ’n Verslag wat sê DNS het op hotel-Wi-Fi gefaal, beskryf ’n simptoom met minstens drie verskillende oorsake.