Aldatu al du VPNak nire DNSa? Konparatu aurretik eta ondoren
Profil batek zure kontsultak nahita mugi ditzake. Konparatu resolverraren politika eta benetako erantzuna VPN bat konektatu aurretik eta ondoren, aldagai bat finko mantenduz.
Tunela konektatzen duzu, panel pribatu bat irekitzen duzu, eta izena inoiz ikusi ez duzun helbide batean ebazten da. Edo kontrakoa gertatzen da: nabigatzaileak lanean jarraitzen du eta komando-lerroko tresna batek bat-batean ezer ebazten ez du. Bi emaitzak aldaketa beretik datoz, eta jendeak normalean esaldi batekin azaltzen du VPNak "bere DNS propioa erabiltzen duela" esanez, eta hori ez da nahikoa zehatza arazteko edo egiaztatzeko. Esaldi horretan bi galdera daude ezkutuan: zein kontsulta hartu behar ditu profil honek, eta zure makinak benetan bidali al zizkion eman zioten resolverrari? Hauek bereizita edukitzea da metodo osoa, horiek nahasten dituen proba batek norabide bietan ziur okerreko erantzuna ematen baitu.
Zergatik ematen duen profilek resolver bat
Tunel baten barruan, urruneko muturraren atzeko izenak normalean sare horretan bakarrik dauden helbideetan ebazten dira. corp.internal bezalako zona pribatu batek ez du delegazio publikorik, beraz, hura erantzuten duen resolverra tunelaren barnetik irisgarria izan behar da. Mekanismo berak bigarren helburu bat ere betetzen du: kontsultak bestela zure hornitzailearen bidez irtengo balira, urruneko aldeko resolver batek kontsulta bide zifratuaren barruan mantentzen du. Horregatik iristen da DNS zerbitzariaren helbidea konexioaren politikaren parte gisa, eta ez makinarako behin aukeratu zenuen ezarpen global gisa.
Helbideak berak ez du ezer erabakitzen. Resolver batek erantzun dezake soilik hara doan ibilbide bat badago, eta hutsegite ohikoena tunela aktibo dagoen bitartean soilik irisgarria den resolverra da. Tunela erori eta politika geratzen denean, kontsultak ibilbiderik gabeko helbide batera doaz, eta sintoma denbora-muga agortzea da, ez errore garbia. Aldea hori garrantzitsua da hurrengo probaren emaitza irakurtzean, denbora-mugak jendea inoiz inplikatuta egon ez ziren garraio-ezarpenetara bidaltzen baitu.
Konparatu bi diseinuak erantzunak konparatu aurretik
Tunel osoak eta DNS zatituak aurkako itxaropenak sortzen dituzte, eta bietako bat ere ez da gaizki funtzionatzea. Tunel osoaren pean kontsulta bakoitza hornitzailera edo enpresako resolverrera joan daiteke, beraz, izen publikoek konektatu ondoren desberdin erantzutea espero daiteke. DNS zatituaren pean zerrendatutako domeinuak soilik doaz resolver pribatura, eta gainerako guztia lokala da; Windowsen domeinu-zerrenda Name Resolution Policy Table delakoan bizi da, macOSen DNS ezarpenen domeinu parekideetan, eta systemd-resolved duen ostalari batean esteka bakoitzeko bideratze-domeinuetan.
Hori da lehenengo egin beharreko konparazioa, honek erabakitzen baitu zer den akats. DNS zatituarekin, resolver berri batetik erantzuten duen izen publikoa da ikertzea merezi duena, eta zuzen erantzuten duen barne-izena sistema bere lana egiten ari da. Tunel osoarekin, anomalia zure hornitzailearen resolverretik oraindik erantzuten duen izen publikoa da. Microsoften VPN izenen ebazpenari buruzko dokumentazioak Windowsen arau horien ordena deskribatzen du, politikako sarrera bat bat datorrena adapterraren zerbitzarien aurretik nola kontsultatzen den barne.
Gela horretan hirugarren resolver bat dago, erraza ahazteko. Nabigatzailearen DNS seguruak berak ebazten ditu izenak eta erantzuten jarrai dezake tunelak sistema eragilearen politika aldatu ondoren, beraz, kargatzen den orrialde batek nabigatzailearen resolverra funtzionatu zuela frogatzen du, ez profila aplikatu zenik. Nabigatzaileak erakusten duena soilik konparatzen baduzu, denboraren erdian geruza okerra probatzen ari zara.
Erregistratu oinarrizko lerro bat aldagai bakarrekin
Aldatu tunela. Ez aldatu, halaber, izena, tresna edo bilaketa-atxizkia pausu berean. Aukeratu kontsultatzeko baimena duzun izen bat, idatzi zein aplikazio erabili zenuen, eta idatzi itzuli zen helbidea edo errore zehatza. Windowsen Get-DnsClientServerAddress -AddressFamily IPv4-k adapter bakoitzeko zerbitzariak inprimatzen ditu eta Get-DnsClientNrptPolicy-k politikako sarrerak; systemd-resolved duen Linuxen resolvectl status-k esteka bakoitzeko DNS zerbitzariak eta bideratze-domeinuak erakusten ditu; macOSen scutil --dns-k sistemak benetan jarraituko duen resolver ordena inprimatzen du.
Gero konektatu bezeroaren ohiko kontrolekin eta errepikatu komando berak zehatz-mehatz. Gorde lehen irteera, hura gogoratu beharrean, konparazioa baita kontu osoa, eta cachea hustu ondoren hartutako bigarren irakurketa dagoeneko beste neurketa bat da. Oinarrizko lerroa nabigatzailea aurretik zuela hartu bazen eta konektatu osteko exekuzioa terminalean gertatzen bada, bi resolver konparatzen ari zara, ez resolver beraren bi egoera.
Kontsulta esplizitua eta aplikazioaren bilaketa proba desberdinak dira
Zerbitzari zehatz bati galdetzeak, nslookup name 10.20.0.1 edo dig @10.20.0.1 name erabiliz, gauza bakarra frogatzen du: izendatu duzun zerbitzariak erantzuten duela hara iristen zarenean. Hautaketa-logika erabat saihesten du, beraz ezin dizu esan sistemak zerbitzari hori aukeratuko zukeen izen honetarako. Erabili esleitutako resolverra irisgarria den probatzeko, eta ez erabili politika probatzeko.
Resolver lokalaren bidezko bilaketak bai darabil hautaketa. resolvectl query name bideratze-domeinuaren arau berak zeharkatzen ditu eta zein protokolo erantzun zuen jakinarazten du, Resolve-DnsName Windowsen politika-taula eta bezeroaren cachea zeharkatzen ditu, eta scutil --dns bilaketa batek jarraituko lukeen ordena erakusten du. Exekutatu bi motak, eta eduki itzazu zure oharren zutabe bereizietan. Kontsulta esplizitu arrakastatsua aplikazioaren bilaketa huts baten ondoan bideratze edo hautaketa arazoa da, ez lan egiteari uko egiten dion resolverra.
Cachea zu eta erantzunaren artean dago. Sistema eragileak, resolver stub lokalak, nabigatzaileak eta cache negatiboak guztiek emaitzak gordetzen dituzte, beraz bilaketa batek arrakasta izan dezake pakete bakar bat ere makinatik irten gabe. Erregistratu emaitza ezer hustu aurretik: ipconfig /flushdns, resolvectl flush-caches edo sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder macOSen. Saltatu sarearen berrezarpen zabala etapa honetan, oraindik biltzen ari zaren froga suntsitzen baitu.
Zer esan nahi du aldeak
Konparatu erregistratu dituzun bi errenkadak eta sailkatu aldaketa ezarpen bakarra ukitu aurretik.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
Errenkada batek enfasia merezi du. Ebazten den izen bat ez da funtzionatzen duen zerbitzu bat, eta DNSaren arrakastak helbide bat aurkitu zela besterik ez du esaten. Ez du ezer esaten birbidaltzeaz, suebakiko arauez edo zure kontuak zerbitzua erabiltzeko baimena duen ala ez, beraz amaitu aplikazio erreala probatuz, hutsegiteak bere kabuz alde egin zuela suposatu beharrean.
Berrezarri oinarrizko lerroa eta egiaztatu
Deskonektatu bezeroaren beraren kontrolekin, prozesua hiltzen ibili beharrean, eta gero irakurri berriro hiru komando berak. Esteka bakoitzeko zerbitzariak, politikako sarrerak eta zure proba-izenaren erantzunak lehenago idatzitako oinarrizko lerrora itzuli beharko lukete. Deskonexio garbi baten ondoren geratzen den politikako sarrera bat benetako akats bat da, erregistratzea merezi duena, eta horrexegatik da ohitura txarra sortutako resolver fitxategia eskuz aldatzea: fitxategia berridatzi egiten da eta aldaketa desagertu egiten da, edo aldaketak bizirik irauten du eta jada ibilbiderik ez duen resolver bat finkatzen du.
Egin zerrenda hau behin, ordenan. Erabaki zein diseinu ezartzen duen profilek edozein emaitza epaitu aurretik. Mantendu izena, tresna eta atxizkia finko bi exekuzioetan. Bereizi kontsulta esplizitua aplikazioaren bilaketatik. Irakurri politika eraginkorra, ez soilik erantzuna. Hustu cacheak azkenik, konparazioa idatzi ondoren. Egiaztatu aplikazio errealarekin, gero berrabiarazi behin eta baieztatu deskonektatutako egoera oraindik garbi dagoela.