Bakit nire-redirect ng hotspot ang DNS bago kumonekta ang VPN?
Kini-redirect ng hotspot ang mga paghahanap sa sarili nitong network, at ang hostname endpoint ay niresolba bago pa man umiral ang anumang tunnel. Subaybayan kung aling resolver ang sumagot sa bawat query.
Ang pagsali sa network ng hotel ay naglalagay ng dalawang desisyon sa DNS sa harap mo sa magkaibang sandali: ang mga paghahanap na ginagawa ng device habang nag-sign in, at ang mga paghahanap na ginagawa kapag nakatayo na ang tunnel. Maaaring impluwensyahan ng hotspot ang una sa pamamagitan ng network na kinokontrol nito. Ang pangalawa ay nakadepende sa patakaran ng kliyente mismo, na isang hiwalay na bagay na dapat siyasatin.
Sundan ang koneksyon sa pagkakasunod-sunod, mula sa unang DHCP lease hanggang sa query na nagresolba ng pribadong pangalan. Pagkatapos ay malinaw na naghihiwalay ang dalawang pagkabigo na magkapareho ang itsura sa isang support ticket: ang isa ay nangyari bago umiral ang tunnel, at ang isa ay nangyari sa loob nito.
Ano ang maaari at hindi maaaring hawakan ng hotspot
Namamahagi ang access network ng address ng resolver sa DHCP at maaari nitong harangin ang port 53 papunta sa address na iyon. Sapat na iyon upang sagutin ang bawat hindi protektadong paghahanap ng portal address o block page. Sapat din iyon upang sirain ang kliyente ng VPN na ang endpoint ay nakasulat bilang hostname.
Ang hindi kaya ng hotspot ay basahin o muling isulat ang isang query kapag naglalakbay na ito sa loob ng establisadong tunnel, kung ipagpalagay na talagang dinadala ito ng tunnel. Ang pagharang ay nakadepende sa pagtingin sa tanong sa plain text.
Lumalabas pa rin ang mga query sa tunnel dahil sa mga dahilang walang kaugnayan sa hotspot: ang secure DNS setting ng browser, isang split-DNS rule na nagpapanatili ng corporate suffix sa lokal na resolver, o isang kliyenteng naka-configure na ibukod ang DNS sa tunnel. Bawat isa ay pagpili sa panig ng kliyente, at bawat isa ay mukhang panghihimasok ng hotspot kapag tiningnan mula sa labas.
| 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 |
Ang unang paghahanap ay nangyayari bago umiral ang tunnel
Ang kliyenteng binigyan ng hostname ay dapat munang iresolba iyon, at sa sandaling iyon walang tunnel na nagpoprotekta sa query. Kung sasagot ang hotspot ng portal address, nabibigo o bumabitin ang negosasyon. Kung walang isasagot, nag-uulat ang kliyente ng error sa pangalan at hindi kailanman magsisimula ang tunnel. Alinman sa dalawang resulta ang nagpapaliwanag ng walang laman na tunnel log na kung hindi ay mukhang inosente.
Nagsasagawa rin ang mga operating system ng sarili nilang pagsusuri sa konektibidad at pagtuklas ng portal, na inilarawan sa RFC 8910 at RFC 8952, at lumalabas ang mga kahilingang iyon bago pa man tumayo ang anumang VPN. Ang makita ang mga iyon sa proxy log ay inaasahang pag-uugali at hindi patunay ng pagtagas.
Ang praktikal na solusyon ay bigyan ang kliyente ng endpoint na hindi nangangailangan ng paghahanap. Kapag imposible iyon, tapusin muna ang pag-sign in at kumonekta pagkatapos.
Alamin kung aling resolver ang sumagot
Tanungin ang system at hindi ang browser, at patakbuhin ang query nang dalawang beses: isang beses sa pamamagitan ng alinmang resolver na ginagamit ng device ngayon, isang beses laban sa isang fixed address.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Ang sagot mula sa unang command na naiiba sa pangatlo ay nagsasabi sa iyo na ang lokal na resolver ay nagbabalik ng iba, at iyon mismo ang ginagawa ng hotspot na nagre-redirect. Ang pagkabigo mula sa pangatlo kasama ng tagumpay mula sa una ay tumuturo sa portal: ang lokal na resolver ay nagbigay ng sign-in address habang ang palabas na port 53 ay itinapon. Ang pag-time out sa pareho ay nangangahulugan na itinatapon ng network ang DNS hanggang sa matapos ang authentication.
Ulitin pagkatapos kumonekta at ihambing. Ang naka-cache na sagot ay nakakalampas sa transisyon, kaya i-flush ang cache o magtanong ng bagong pangalan para sa ikalawang obserbasyon.
Panatilihin ang mga susunod na paghahanap sa landas na nilayon mo
Ang full-tunnel profile na humuhuli rin ng DNS ay ang pinakasimpleng kaayusan: bawat query mula sa bawat application ay pumupunta sa resolver na itinutulak ng tunnel, at ang lokal na network ay nakakakita lamang ng naka-encrypt na trapiko. Patunayan ito sa pamamagitan ng pagresolba ng panloob at pampublikong pangalan pagkatapos kumonekta, at paghahambing ng dalawang sagot sa ibinabalik ng tunnel resolver nang mag-isa.
Ang split-DNS ay nangangailangan ng listahan ng domain na isinulat nang may layunin: mga corporate suffix sa pamamagitan ng tunnel, lahat ng iba pa ay lokal, at walang overlap sa pagitan ng dalawa.
Ang secure DNS ng browser ay nasa labas ng patakarang iyon, kaya kung kailangan itong patayin para kumilos nang predictable ang profile, patayin ito para sa profile na iyon at hindi para sa makina. Gawin ito sa mga setting ng browser, hindi sa pag-edit ng system resolver, upang makita ang pagbabago sa susunod. Itala ang sagot, ang resolver at ang yugto ng koneksyon sa isang linya bawat pagsubok. Ang ulat na nagsasabing nabigo ang DNS sa Wi-Fi ng hotel ay naglalarawan ng sintomas na may hindi bababa sa tatlong magkaibang dahilan.