Pse një hotspot e ridrejton DNS-në përpara se VPN të lidhet?
Një hotspot rishkruan kërkimet në rrjetin e vet, dhe një pikë fundore me emër hosti zgjidhet para se të ekzistojë çdo tunel. Gjurmoni cili zgjidhës u përgjigj për çdo pyetje.
Të bashkohesh me një rrjet hoteli të vë përballë dy vendimeve DNS në momente të ndryshme: kërkimet që pajisja bën gjatë hyrjes dhe kërkimet që bëhen pasi tuneli është ngritur. Një hotspot mund të ndikojë në të parat përmes rrjetit që kontrollon. Të dytat varen nga politika e vetë klientit, që është një gjë më vete për t'u shqyrtuar.
Kaloni nëpër lidhjen me radhë, nga qiraja e parë DHCP deri te pyetja që zgjidhi një emër privat. Atëherë dy dështime që në një ticket suporti duken njësoj ndahen pastër: njëri ndodhi përpara se tuneli të ekzistonte, tjetri ndodhi brenda tij.
Çfarë mund dhe çfarë nuk mund të prekë hotspot-i
Rrjeti i aksesit shpërndan një adresë zgjidhësi në DHCP dhe mund të përvetësojë portën 53 drejt asaj adrese. Kjo mjafton për t'iu përgjigjur çdo kërkimi të pambrojtur me një adresë portali ose një faqe bllokimi. Mjafton gjithashtu për të thyer një klient VPN pika fundore e të cilit është shkruar si emër hosti.
Ajo që hotspot-i nuk mund të bëjë është të lexojë ose të rishkruajë një pyetje pasi ajo udhëton brenda një tuneli të vendosur, duke supozuar se tuneli vërtet e mbart atë. Përvetësimi varet nga të parit e pyetjes në tekst të thjeshtë.
Pyetjet megjithatë e lënë tunelin për arsye që nuk lidhen me hotspot-in: cilësimi i DNS-së së sigurt të shfletuesit, një rregull split-DNS që mban një prapashtesë korporative te zgjidhësi lokal, ose një klient i konfiguruar për të përjashtuar DNS-në nga tuneli. Secili është një zgjedhje nga ana e klientit dhe secili duket si ndërhyrje e hotspot-it kur shihet nga jashtë.
| 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 |
Kërkimi fillestar ndodh përpara se të ekzistojë tuneli
Një klient që merr një emër hosti duhet ta zgjidhë atë së pari, dhe në atë çast asnjë tunel nuk e mbron pyetjen. Nëse hotspot-i përgjigjet me një adresë portali, negocimi dështon ose ngec. Nëse përgjigjet me asgjë, klienti raporton një gabim emri dhe tuneli nuk fillon kurrë. Secili prej dy rezultateve shpjegon një regjistër tuneli bosh që përndryshe duket i pafajshëm.
Sistemet operative kryejnë gjithashtu kontrollet e tyre të lidhshmërisë dhe zbulimin e portalit, të përshkruara në RFC 8910 dhe RFC 8952, dhe ato kërkesa dalin përpara se të ngrihet çdo VPN. T'i shohësh në një regjistër proxy është sjellje e pritur dhe jo provë e një rrjedhjeje.
Zgjidhja praktike është t'i japësh klientit një pikë fundore që nuk kërkon asnjë kërkim. Kur kjo është e pamundur, përfundoni së pari hyrjen dhe lidhuni më pas.
Zbuloni cili zgjidhës u përgjigj
Pyetni sistemin dhe jo shfletuesin, dhe ekzekutoni kërkimin dy herë: një herë përmes çdo zgjidhësi që pajisja përdor tani, një herë kundër një adrese fikse.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Një përgjigje nga komanda e parë që ndryshon nga e treta ju tregon se zgjidhësi lokal kthen diçka tjetër, dhe kjo është pikërisht ajo që bën një hotspot që ridrejton. Një dështim nga e treta bashkë me një sukses nga e para tregon portalin: zgjidhësi lokal shërbeu një adresë hyrjeje, ndërsa porta 53 dalëse u hodh. Afatet e skadimit në të dyja nënkuptojnë që rrjeti e hedh DNS-në derisa të përfundojë vërtetimi.
Përsëriteni pas lidhjes dhe krahasoni. Një përgjigje e ruajtur në cache i mbijeton tranzicionit, prandaj zbrazni cache-in ose pyesni një emër të ri për vëzhgimin e dytë.
Mbani kërkimet e mëvonshme në rrugën që kishit ndërmend
Një profil tuneli të plotë që kap edhe DNS-në është rregullimi më i thjeshtë: çdo kërkim nga çdo aplikacion shkon te zgjidhësi që shtyn tuneli, dhe rrjeti lokal sheh vetëm trafik të kriptuar. Vërtetojeni duke zgjidhur një emër të brendshëm dhe një publik pas lidhjes, dhe më pas duke krahasuar të dyja përgjigjet me atë që zgjidhësi i tunelit kthen vetë.
Split-DNS kërkon një listë domenesh të shkruar me qëllim: prapashtesa korporative përmes tunelit, gjithçka tjetër lokalisht, dhe pa mbivendosje mes të dyjave.
DNS-ja e sigurt e shfletuesit qëndron jashtë asaj politike, prandaj nëse duhet të jetë e fikur që profili të sillet në mënyrë të parashikueshme, fikeni për atë profil dhe jo për makinën. Bëjeni në cilësimet e shfletuesit, jo duke redaktuar zgjidhësin e sistemit, që ndryshimi të jetë i dukshëm herën tjetër. Shënoni përgjigjen, zgjidhësin dhe fazën e lidhjes në një rresht për çdo test. Një raport që thotë se DNS dështoi në Wi-Fi-n e hotelit përshkruan një simptom me të paktën tri shkaqe të ndryshme.