VPN povezan, ali imena ne rade: gdje se DNS zapravo kvari

Tunel je podignut, ikona zelena, a svaka kartica preglednika prijavljuje neuspjeh razrješavanja imena. Tri različita mehanizma stvaraju tu sliku: resolver može biti nedostupan, klijent može pitati resolver koji niste očekivali ili mogu zakazati samo privatna imena. Razdvojite ih prije nego što promijenite bilo šta u protokolu tunela, jer se svaki popravlja na drugom mjestu. Redoslijed ispod počinje zapažanjima koja razdvajaju ta tri slučaja.

Šta upit zapravo treba

Upit treba tri stvari: adresu resolvera, rutu do te adrese i odgovor koji odgovara pitanju. Svako od toga može zakazati samo, a vidljivi simptom je ista stranica koja se ne učitava. Zato stranica s greškom ne govori gotovo ništa dok ne saznate koje je od troje pokvareno.

Klijent saznaje svoj resolver iz VPN profila, iz DHCP-a na tunelu ili iz vlastite konfiguracije, a koji izvor pobjeđuje zavisi od platforme. Na Windowsu ipconfig /all ispisuje DNS servere po adapteru, pa možete vidjeti je li poslana vrijednost zaista stigla. Poslana vrijednost koja nikad nije došla do operativnog sistema tih je i čest neuspjeh. Pročitajte konfigurisanu vrijednost prije nego dirnete profil.

Linux i macOS odgovaraju na isto pitanje različitim komandama, a odgovor zaslužuje isto čitanje: resolvectl status i scutil --dns oba navode servere po interfejsu. Uporedite taj spisak s adresom koju profil tvrdi da šalje. Nesklad ovdje objašnjava sve dalje, zato ga riješite prije testiranja imena.

Testirajte jedno javno i jedno privatno ime

Pitajte obično javno ime hosta i dokumentovano privatno ime hosta s iste mašine i zapišite koji je server odgovorio na svako. Ako oba zakazu, resolver ili njegova ruta su pokvareni. Ako zakaže samo privatno ime, resolver je odgovorio i pitanje postaje zona ili rutiranje. Pokrenite oba upita u razmaku od minute, da promjena rute ne može objasniti razliku.

Držite interna imena izvan javnih snimaka ekrana i javnih resolvera. Istek vremena i odgovor o nepostojećoj domeni različita su zapažanja: prvo kaže da ništa nije vraćeno, drugo da je autoritet odgovorio da ime ne postoji. Ako ih tretirate kao jednu grešku, idete na pogrešan sloj, a upozorenje o certifikatu je opet treća stvar, ne kvar DNS-a.

nslookup ispisuje i server kojem je upućen upit i primljeni odgovor, a to je tačno par koji vam treba. Pokrenite ga dvaput u istoj ljusci i zapišite adresu koja je odgovorila pored svakog odgovora.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Potvrdite da klijent zaista dosegne taj server

Privatni resolver koji profil šalje koristan je samo ako ga klijent može dosegnuti dok je tunel podignut. Adresa koja izgleda ispravno bez rute daje istek vremena, a povezano stanje tunela ne govori ništa o toj ruti. Provjera je traženje rute prema samom resolveru, ne prema VPN endpointu.

Svaka platforma odgovara na to jednim redom, a interfejs naveden u izlazu cijeli je odgovor. Ako pokazuje na fizički adapter dok resolver stoji iza tunela, profil ne šalje prefiks koji ga pokriva.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

Na split-tunnel profilu resolver može stajati izvan poslanih ruta, što je problem profila, a ne servera. Uporedite adresu resolvera s poslanim prefiksima i potvrdite da ih jedan pokriva. Isti nesklad objašnjava zašto DNS radi na jednoj mreži, a ne uspijeva na drugoj s identičnim profilom.

Imajte na umu da preglednici mogu zaobići sistemski resolver

Preglednik sa uključenim sigurnim DNS-om može slati upite preko HTTPS-a provajderu po vlastitom izboru i potpuno ignorisati resolver operativnog sistema. Tada sistem izgleda ispravno dok preglednik ne uspijeva, ili obrnuto. To je pitanje politike za preglednik, ne za tunel.

Provjerite postavku sigurnog DNS-a u pregledniku i svaku upravljanu politiku koja je kontroliše, pa pokušajte drugu aplikaciju ili preglednik s nepromijenjenim tunelom. Ako ne uspijeva samo jedna aplikacija, popravka pripada toj aplikaciji. Privatni prozor nije čisto poređenje, jer u jednom pregledniku može podrazumijevano isključiti ekstenzije, a u drugom ne, i nikada ne zaobilazi upravljanu politiku. Umjesto toga koristite drugi profil preglednika ili drugu aplikaciju.

Očistite keš i ponovo testirajte pravi zadatak

Nakon ispravke postavke očistite lokalni keš resolvera da stari odgovor ne nadživi popravku. Kratak oporavak pa novi neuspjeh znači da je uzrok još prisutan, a ne da je čišćenje neuspjelo. Odaberite red koji odgovara mašini na kojoj ste, jer su tri keša odvojena.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Zatim ponovite prvobitni zadatak umjesto sintetičkog upita, jer zadatak je ono što korisnika zanima. Ponovo se povežite jednom, da ponovni test pokrije stanje u kojem će korisnik zaista biti. Microsoftov nslookup priručnik stranica je koju treba čuvati za argumente upita.

Ako imena ne uspijevaju samo nakon odspajanja, klijent nije vratio prethodnu konfiguraciju, što je greška životnog ciklusa o kojoj treba izvijestiti, a ne DNS server koji treba zamijeniti. Ispravan upit takođe nije test curenja, jer zemlja izlaza ne govori koji je resolver odgovorio.