Je li VPN promijenio moj DNS? Uporedite prije i poslije
Profil može namjerno premjestiti vaše upite. Uporedite politiku rezolvera i stvarni odgovor prije i poslije povezivanja VPN-a, držeći jednu varijablu.
Povežete tunel, otvorite privatnu kontrolnu ploču i ime se razriješi u adresu koju nikada niste vidjeli. Ili se dogodi suprotno: pregledač nastavi raditi dok alat komandne linije iznenada ne razriješi ništa. Oba ishoda dolaze iz iste promjene, a ljudi to obično objašnjavaju jednom rečenicom o VPN-u koji "koristi svoj DNS", što nije dovoljno precizno za otklanjanje greške ili provjeru. U toj rečenici kriju se dva pitanja: koje upite ovaj profil treba da preuzme i da li je vaša mašina zaista poslala te upite rezolveru koji joj je dodijeljen? Držati ih odvojeno jeste cijela metoda, jer test koji ih miješa daje samouvjeren pogrešan odgovor u oba smjera.
Zašto profil uopšte daje rezolver
Unutar tunela, imena iza udaljenog kraja obično se razrješavaju u adrese koje postoje samo u toj mreži. Privatna zona kao corp.internal nema javnu delegaciju, pa rezolver koji na nju odgovara mora biti dostupan iz unutrašnjosti tunela. Isti mehanizam služi i drugoj svrsi: kada bi upiti inače izašli kroz vašeg ISP-a, rezolver na udaljenoj strani zadržava upit unutar šifrovane staze. Zato adresa DNS servera dolazi kao dio politike veze, a ne kao globalna postavka koju ste jednom odabrali za mašinu.
Adresa sama po sebi ništa ne rješava. Rezolver može odgovoriti samo ako do njega postoji ruta, a najčešći kvar je rezolver dostupan samo dok je tunel podignut. Kada tunel padne a politika ostane, upiti idu na adresu bez putanje, a simptom je istek vremena, a ne čista greška. Ta razlika je važna kada čitate sljedeći rezultat testa, jer istek vremena šalje ljude u transportne postavke koje nikada nisu bile uključene.
Uporedite dva dizajna prije nego što uporedite odgovore
Puni tunel i podijeljeni DNS daju suprotna očekivanja i nijedno nije kvar. Pod punim tunelom svaki upit može preći na provajdera ili na korporativni rezolver, pa je različit odgovor javnih imena nakon povezivanja očekivan. Pod podijeljenim DNS-om samo navedene domene idu na privatni rezolver dok sve ostalo ostaje lokalno; na Windowsu lista domena živi u Name Resolution Policy Table, na macOS-u u match domains DNS postavki, a na systemd-resolved hostu u per-link routing domains.
To je poređenje koje treba prvo napraviti, jer ono odlučuje šta se računa kao greška. Kod podijeljenog DNS-a javno ime koje odgovara s novog rezolvera je ono što vrijedi istražiti, dok je interno ime koje ispravno odgovara sistem koji radi svoj posao. Kod punog tunela anomalija je javno ime koje još uvijek odgovara s rezolvera vašeg ISP-a. Microsoftova dokumentacija o razrješavanju VPN imena opisuje Windowsov redoslijed ovih pravila, uključujući kako se podudarni unos politike konsultuje prije vlastitih servera adaptera.
U prostoriji je i treći rezolver koji je lako zaboraviti. Sigurni DNS pregledača sam razrješava imena i može nastaviti odgovarati nakon što je tunel promijenio politiku operativnog sistema, pa stranica koja se učita dokazuje da je rezolver pregledača radio, a ne da je profil primijenjen. Ako upoređujete samo ono što pregledač prikazuje, pola vremena testirate pogrešan sloj.
Zabilježite osnovnu liniju sa samo jednom varijablom
Promijenite tunel. Ne mijenjajte istovremeno ime, alat ili sufiks pretrage u istom koraku. Odaberite ime za koje smijete postavljati upite, zabilježite koji ste program koristili i zapišite ili adresu koja se vratila ili tačnu grešku. Na Windowsu Get-DnsClientServerAddress -AddressFamily IPv4 ispisuje servere po adapteru, a Get-DnsClientNrptPolicy ispisuje unose politike; na Linuxu sa systemd-resolved resolvectl status prikazuje DNS servere i domene rutiranja po vezi; na macOS-u scutil --dns ispisuje redoslijed rezolvera koji će sistem zaista slijediti.
Zatim se povežite kroz uobičajene kontrole klijenta i ponovite tačno iste komande. Sačuvajte prvi izlaz, a ne sjećanje na njega, jer je poređenje cijela poenta, a drugo čitanje uzeto nakon čišćenja keša već je drugo mjerenje. Ako je osnovna linija uzeta s pregledačem naprijed, a pokretanje nakon povezivanja se odvija u terminalu, upoređujete dva rezolvera, a ne dva stanja jednog rezolvera.
Eksplicitni upit i pretraga iz aplikacije su različiti testovi
Pitati jedan određeni server, pomoću nslookup name 10.20.0.1 ili dig @10.20.0.1 name, dokazuje jednu stvar: server koji ste naveli odgovara kada do njega možete doći. To potpuno zaobilazi logiku odabira, pa ne može reći da li bi sistem odabrao taj server za ovo ime. Koristite ga da provjerite je li dodijeljeni rezolver dostupan, a ne koristite ga za provjeru politike.
Pretraga kroz lokalni rezolver zaista primjenjuje odabir. resolvectl query name prolazi kroz ista pravila domena rutiranja i izvještava koji protokol je odgovorio, Resolve-DnsName na Windowsu prolazi kroz tabelu politike i keš klijenta, a scutil --dns prikazuje redoslijed koji bi pretraga slijedila. Pokrenite obje vrste i držite ih u odvojenim kolonama svojih bilješki. Uspješan eksplicitni upit pored neuspjele pretrage iz aplikacije je problem rutiranja ili odabira, a ne rezolver koji odbija raditi.
Keširanje stoji između vas i odgovora. Operativni sistem, lokalni stub rezolver, pregledač i negativno keširanje svi drže rezultate, pa pretraga može uspjeti bez ijednog paketa koji napusti mašinu. Zabilježite rezultat prije nego što bilo šta očistite: ipconfig /flushdns, resolvectl flush-caches ili sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder na macOS-u. Preskočite široki reset mreže u ovoj fazi, jer uništava dokaze koje još prikupljate.
Šta razlika znači
Uporedite dva reda koja ste zabilježili i klasifikujte promjenu prije nego što dodirnete ijednu postavku.
| 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 |
Jedan red zaslužuje naglasak. Ime koje se razriješi nije usluga koja radi, a uspjeh DNS-a kaže samo da je adresa pronađena. Ne govori ništa o prosljeđivanju, pravilima zaštitnog zida ili o tome smije li vaš račun uopšte koristiti uslugu, pa završite testiranjem stvarne aplikacije umjesto pretpostavke da se kvar sam povukao.
Vratite osnovnu liniju i provjerite je
Prekinite vezu kroz vlastite kontrole klijenta umjesto da ubijete proces, zatim ponovo pročitajte iste tri komande. Serveri po vezi, unosi politike i odgovor za vaše test ime treba da se vrate na osnovnu liniju koju ste ranije zapisali. Zaostali unos politike nakon čistog prekida je stvarni defekt vrijedan bilježenja, i upravo zato su ručne izmjene generisane datoteke rezolvera loša navika: datoteka se prepisuje i izmjena nestaje, ili izmjena preživi i prikuje rezolver koji više nema rutu.
Prođite kroz ovu listu jednom, po redu. Odlučite koji dizajn profil primjenjuje prije nego što procijenite bilo koji rezultat. Držite ime, alat i sufiks fiksiranim kroz oba pokretanja. Odvojite eksplicitni upit od pretrage iz aplikacije. Čitajte efektivnu politiku, a ne samo odgovor. Očistite keš na kraju, nakon što je poređenje zapisano. Provjerite sa stvarnom aplikacijom, zatim jednom restartujte i potvrdite da je stanje prekida još uvijek čisto.