Zergatik birbideratzen du hotspot batek DNSa VPNa konektu aurretik?
Hotspot batek bere sarean berridazten ditu bilaketak, eta ostalari-izeneko muturra tunelik existitu aurretik ebazten da. Jarraitu zein ebaztailek erantzun duen kontsulta bakoitzari.
Hotel-sare batera sartzeak bi DNS-erabaki jartzen dizkizu aurrean une ezberdinetan: gailuak saioa hastean egiten dituen bilaketak, eta tunela altxatu ondoren egiten direnak. Hotspot batek lehenengoetan eragin dezake kontrolatzen duen sarearen bidez. Bigarrenak bezeroaren beraren politikan oinarritzen dira, eta hori bereiz aztertu beharreko kontua da.
Ikus ezazu konexioa ordenan, lehen DHCP maiztertzetik izen pribatu bat ebatzi zuen kontsultaraino. Orduan, laguntza-txartel batean berdinak diruditen bi hutsegite garbi bereizten dira: bat tunela existitu aurretik gertatu zen, eta bestea haren barruan.
Zer ukitu dezakeen hotspotak eta zer ez
Sarbide-sareak ebaztailearen helbidea ematen du DHCP bidez eta helbide horretarako 53 portua atzeman dezake. Hori nahikoa da babesik gabeko bilaketa bakoitzari atari-helbide edo blokeo-orri batekin erantzuteko. Halaber, nahikoa da ostalari-izen gisa idatzitako muturra duen VPN bezero bat hausteko.
Hotspotak ezin duena da kontsulta bat irakurri edo berridatzi, tunel ezarri baten barruan bidaiatzen duenean, tunelak benetan garraiatzen duela suposatuz. Atzematea testu lauean galdera ikustean oinarritzen da.
Kontsultei tunela uzten diete, hala ere, hotspotarekin zerikusirik ez duten arrazoiengatik: nabigatzailearen DNS seguruaren ezarpena, enpresaren atzizki bat tokiko ebaztailean mantentzen duen split-DNS araua, edo DNS tuneletik kanpo uzteko konfiguratuta dagoen bezeroa. Bakoitza bezeroaren aldeko aukera da, eta bakoitza kanpotik hotspotaren interferentzia bezala ikusten da.
| 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 |
Hasierako bilaketa tunela existitu aurretik gertatzen da
Ostalari-izen bat jasotzen duen bezeroak lehenengo ebatzi behar du, eta une horretan inongo tunelak ez du kontsulta babesten. Hotspotak atari-helbide batekin erantzuten badu, negoziazioak huts egiten du edo zintzilik geratzen da. Ezer ez badu erantzuten, bezeroak izen-errore bat jakinarazten du eta tunelak ez du inoiz abiarazten. Bi emaitzetatik edozeinek tunel-erregistro huts bat azaltzen du, bestela errugabea dirudiena.
Sistema eragileek beren konektibitate-egiaztapenak eta atariaren aurkikuntza ere egiten dituzte, RFC 8910 eta RFC 8952-n deskribatuak, eta eskaera horiek edozein VPN altxatu aurretik irteten dira. Proxy erregistro batean ikustea espero den jokabidea da, ez filtrazioaren froga.
Konponbide praktikoa bezeroari bilaketarik behar ez duen mutur bat ematea da. Hori ezinezkoa denean, amaitu saioa hastea lehenengo eta konektatu ondoren.
Ezagutu zein ebaztailek erantzun zuen
Galdetu sistemari, ez nabigatzaileari, eta exekutatu kontsulta birritan: behin gailuak une honetan erabiltzen duen ebaztailearen bidez, behin helbide finko baten aurka.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Lehen komandoko erantzunak hirugarrenetik desberdina izateak tokiko ebaztaileak beste zerbait itzultzen duela esaten dizu, eta horixe egiten du birbideratzen duen hotspot batek. Hirugarrenaren hutsegiteak lehenaren arrakastarekin batera atarira garamatza: tokiko ebaztaileak saioa hasteko helbidea eman zuen, irteerako 53 portua baztertuta zegoen bitartean. Bietan denbora-mugak agortzeak sareak DNS baztertzen duela esan nahi du autentifikazioa amaitu arte.
Errepikatu konektatu ondoren eta alderatu. Cachean gordetako erantzunak trantsizioa gainditzen du, beraz hustu cachea edo galdetu izen berri bat bigarren behaketarako.
Eduki itzazu ondorengo bilaketak nahi izan zenuen bidean
DNS ere harrapatzen duen tunel osoko profil bat da antolamendurik sinpleena: aplikazio bakoitzaren kontsulta bakoitza tunelak bultzatutako ebaztailera doa, eta tokiko sareak enkriptatutako trafikoa baino ez du ikusten. Frogatu konektatu ondoren barne-izen bat eta izen publiko bat ebatziz, eta gero bi erantzunak tunelaren ebaztaileak bere kabuz itzultzen duenarekin alderatuz.
Split-DNSek asmoarekin idatzitako domeinu-zerrenda behar du: enpresaren atzizkiak tunelaren bidez, gainerako guztia tokian, eta bien artean gainjartzerik ez.
Nabigatzailearen DNS segurua politika horretatik kanpo dago, beraz profila aurreikusgarri portatzeko itzalita egon behar badu, desgaitu profil horretarako eta ez makinarentzat. Egin nabigatzailearen ezarpenetan, ez sistemaren ebaztailea editatuz, hurrengoan aldaketa ikusgai egon dadin. Idatzi erantzuna, ebaztailea eta konexio-etapa lerro batean proba bakoitzeko. Hotelaren Wi-Fi-an DNSak huts egin duela dioen txostenak gutxienez hiru arrazoi ezberdin dituen sintoma bat deskribatzen du.