Vaš VPN gura tri DNS servera: koji odgovara?
Dodatni unosi mogu biti rezerva, ruta po domeni ili ostatak fizičke veze. Povežite svaki s opsegom prije nego što listu nazovete curenjem.
Otvorite stranicu postavki nakon povezivanja i tri DNS adrese su navedene; pitanje revizije je koja je obradila vaš posljednji upit. Sam broj ne odgovara ni na što, jer klijentski potisak, fizičko sučelje i pravilo po domeni svi pišu u isti prikaz. Ti unosi nose različite opsege, a opseg, a ne položaj, odlučuje ko odgovara. Počnite razdvajanjem izvora, zatim testirajte onaj koji posjeduje ime do kojeg vam je stalo.
Zašto je lista duža od vašeg profila
VPN klijent gura adrese razrješivača za vezu tunela, a operacijski sustav ih drži uz ono što je fizičko sučelje već imalo. Usmjerivač, korporativni DHCP zakup, drugi VPN i pravilo po domeni svaki doprinose vlastitim unosom. Tri adrese na stranici stoga mogu značiti tri opsega, a ne tri kandidata za jedan posao. Čitati broj kao dokaz curenja prva je pogreška ove revizije.
Unutar jednog sučelja klijent doista redom isprobava svoje servere, pa uređena lista nije besmislena. Ono što nije red je spojeni prikaz, gdje unosi iz profila, fizičke veze i pravila po domeni stoje jedni uz druge bez jedinstvenog poretka. Ta razlika odlučuje što testirate: redoslijed objašnjava ponašanje unutar jednog opsega, a opseg objašnjava sve ostalo.
Šifrirani DNS razbija sliku iznutra aplikacije. Preglednik ili klijent za razgovor s vlastitim DNS-over-HTTPS razrješivačem šalje upite posve mimo popisa operacijskog sustava, pa adrese na stranici postavki opisuju promet koji aplikacija nikada nije stvorila. Provjerite vlastitu postavku razrješivača aplikacije prije nego što optužite profil za ime koje je ispalo pogrešno.
Što govori svaka od tri provjere
Svaki izvor ostavlja svoj trag na drugom mjestu i nijedna naredba ne pokazuje sve. Ovo je preslikavanje koje vrijedi držati uz stranicu postavki:
| Entry source | Where it is visible | What it proves |
|---|---|---|
| Tunnel profile | Link-scoped DNS on the tunnel device | Which servers the VPN asked you to use, not which one answered |
| Per-domain policy | Suffix list or routing domains | Which names are steered to a particular resolver |
| Physical link | DNS on the LAN interface | Whether a second scope still exists outside the tunnel |
| Application resolver | App settings, absent from the OS list | Whether the system list was consulted at all |
Na sustavu koji koristi systemd-resolved, resolvectl status je mjerodavan jer izvješćuje DNS po vezi zajedno s domenama usmjeravanja. macOS odgovara kroz scutil --dns, koji navodi razrješivače s opsegom redom kojim se isprobavaju. Windows dijeli dvije polovice: Get-DnsClientServerAddress za servere po sučelju i Get-DnsClientNrptPolicy za pravila sufiksa. Pokrenite naredbu koja pripada razrješivaču koji se stvarno koristi, jer stroj s kontejnerskim okruženjem i stolnim razrješivačem može imati više od jednog instaliranog.
Rezervni razrješivač koji ne može odgovoriti za vašu zonu
Drugi unos obično postoji radi dostupnosti, a dostupnost radi samo ako rezerva poznaje imena. Pitajte javni razrješivač za interno ime hosta i on vraća NXDOMAIN ili odgovor s džokerom iz domene pretraživanja koja nema veze s vama. Neispitani prijelaz u rezervu tada stvara prekid točno u trenutku kad je potreban.
Split DNS postoji da to spriječi: sufiksi tvrtke idu razrješivaču koji drži zonu, a javna imena ostaju na zadanom putu. Dizajn je valjan i ovisi o tome da je popis sufiksa potpun. Microsoft dokumentira pravilo razrješivača po sufiksu koje to pokreće na Windowsu, a ista se ideja pojavljuje kao domene usmjeravanja u systemd-resolved i kao razrješivači s opsegom na macOS-u.
Usporedite zone za koje rezerva smije odgovarati sa sufiksima prisutnima u pravilu. Ta usporedba pronalazi prazninu prije nego korisnik prijavi da je jedno interno mjesto prestalo razrješavati nakon promjene tunela.
Pitajte kroz pravilo, ne oko njega
Pitajte kroz razrješivač operacijskog sustava, jer izravan upit serveru zaobilazi pravilo i izvješćuje samo što bi taj server rekao. Razlika između dva odgovora je cijela poanta:
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53
Ako upit sustava vraća privatnu adresu dok izravni upit vraća NXDOMAIN, pravilo radi i rezerva je slaba točka. Ako oba vraćaju isti javni odgovor, ime se razrješava izvan opsega koji ste namjeravali, a popis sufiksa je mjesto za provjeru. Sačuvajte oba izlaza, jer se rasprava o razrješivaču brže rješava s dva retka nego sa snimkom zaslona stranice postavki.
Zatim isprobajte put kvara, jer rezerva koju nitko nije testirao pretpostavka je. Pretvorite preferirani razrješivač u crnu rupu za jedan upit i gledajte koja se adresa vraća:
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32
Izbrišite tu rutu čim upit završi, inače sljedeća osoba naslijedi misterij. Ako se interna imena u tom prozoru još razrješavaju, odgovorilo je nešto izvan namjeravanog opsega. Ako pak isteknu, rezerva nedostaje ili je ispravno omeđena, a vlastiti zapisnik razrješivača kaže koje je od to dvoje bilo.
Odlučite: zadržati, omeđiti ili ukloniti
Zadržite drugi razrješivač kad odgovara na prostor imena koji trebate i ostaje dostupan pod profilom. Ograničite ga opsegom kad treba vidjeti jedan sufiks i ništa više, i uklonite ga kad nema ni opseg ni dokumentiranu svrhu. Unos bez posla buduće je curenje bez koristi, a zadana vrijednost proizvođača nije svrha.
Zabilježite ishod u četiri stupca: sufiks, razrješivač, sučelje i vlasnik. Taj redak odgovara na sljedeće revizijsko pitanje brže od bilo koje snimke zaslona i preživljava ažuriranje klijenta koje tiho presloži listu.