Jūsų VPN siunčia tris DNS serverius: kuris atsako?
Papildomi įrašai gali būti atsarginis variantas, maršrutas pagal domeną arba fizinės jungties likutis. Priskyrę kiekvieną sričiai, tik tada vadinkite sąrašą nutekėjimu.
Prisijungę atidarykite nustatymų puslapį ir pamatysite tris DNS adresus; audito klausimas yra, kuris jų apdorojo paskutinę jūsų užklausą. Vien skaičius nieko neatsako, nes kliento stūmimas, fizinė sąsaja ir politika pagal domeną visi rašo į tą patį vaizdą. Šie įrašai turi skirtingas sritis, o atsakingąjį lemia sritis, o ne pozicija. Pradėkite atskirdami šaltinius, tada išbandykite tą, kuriam priklauso jums svarbus vardas.
Kodėl sąrašas ilgesnis už jūsų profilį
VPN klientas siunčia sprendėjo adresus tunelio jungčiai, o operacinė sistema juos laiko šalia to, ką fizinė sąsaja jau turėjo. Maršrutizatorius, įmonės DHCP nuoma, antras VPN ir politika pagal domeną kiekvienas prideda savo įrašą. Todėl trys adresai puslapyje gali reikšti tris sritis, o ne tris kandidatus vienai užduočiai. Skaičiaus skaitymas kaip nutekėjimo įrodymo yra pirmoji šio audito klaida.
Vienos sąsajos viduje klientas iš tiesų bando savo serverius iš eilės, tad surikiuotas sąrašas nėra beprasmis. Tai, kas nėra eilė, yra sujungtas vaizdas, kuriame profilio, fizinės jungties ir taisyklių pagal domeną įrašai stovi vienas šalia kito be vieno reitingo. Šis skirtumas lemia, ką bandote: tvarka paaiškina elgesį vienos srities viduje, o sritis paaiškina visa kita.
Šifruotas DNS sugriauna vaizdą iš programos vidaus. Naršyklė ar pokalbių klientas su savo DNS-over-HTTPS sprendėju siunčia užklausas visiškai aplenkdamas operacinės sistemos sąrašą, todėl nustatymų puslapio adresai aprašo srautą, kurio programa niekada nesukūrė. Patikrinkite pačios programos sprendėjo nuostatą, prieš kaltindami profilį dėl neteisingai gauto vardo.
Ką sako kiekvienas iš trijų patikrinimų
Kiekvienas šaltinis palieka savo žymę kitoje vietoje, ir nė viena komanda neparodo visų. Tai atvaizdavimas, kurį verta laikyti šalia nustatymų puslapio:
| 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 |
Sistemoje, kuri naudoja systemd-resolved, resolvectl status yra autoritetinga, nes ji praneša DNS kiekvienai jungčiai kartu su maršrutizavimo domenais. macOS atsako per scutil --dns, kuri išvardija sričių sprendėjus jų bandymo tvarka. Windows padalija dvi puses: Get-DnsClientServerAddress sąsajos serveriams ir Get-DnsClientNrptPolicy priesagų taisyklėms. Vykdykite komandą, kuri priklauso faktiškai naudojamam sprendėjui, nes mašinoje su konteinerių vykdymo aplinka ir darbalaukio sprendėju gali būti įdiegtas daugiau nei vienas.
Atsarginis sprendėjas, kuris negali atsakyti už jūsų zoną
Antras įrašas paprastai yra dėl prieinamumo, o prieinamumas veikia tik jei atsarginis žino vardus. Paklauskite viešo sprendėjo vidinio domenų vardo ir jis grąžins NXDOMAIN arba pakaitos atsakymą iš paieškos domeno, neturinčio su jumis nieko bendra. Niekieno nepatikrintas perėjimas tada sukuria sutrikimą būtent tuo metu, kai jo reikia.
Split DNS egzistuoja tam užkirsti kelią: įmonės priesagos patenka pas sprendėją, turintį zoną, o vieši vardai lieka numatytajame kelyje. Dizainas tvirtas, ir jis priklauso nuo to, ar priesagų sąrašas pilnas. Microsoft dokumentuoja priesagos sprendėjo politiką, kuri tai valdo Windows aplinkoje, ir ta pati idėja pasirodo kaip maršrutizavimo domenai systemd-resolved ir kaip sričių sprendėjai macOS.
Palyginkite zonas, už kurias atsarginis gali atsakyti, su politikoje esančiomis priesagomis. Šis palyginimas randa spragą prieš vartotojui pranešant, kad viena vidinė svetainė nustojo spręsti po tunelio pakeitimo.
Klauskite per politiką, o ne aplink ją
Klauskite per operacinės sistemos sprendėją, nes tiesioginė užklausa serveriui apeina politiką ir praneša tik tai, ką tas serveris pasakytų. Skirtumas tarp dviejų atsakymų ir yra visa esmė:
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53Jei sistemos užklausa grąžina privatų adresą, o tiesioginė užklausa grąžina NXDOMAIN, politika veikia, o silpnoji vieta yra atsarginis. Jei abi grąžina tą patį viešą atsakymą, vardas sprendžiamas už numatytos srities ribų, ir priesagų sąrašas yra vieta, kur reikia žiūrėti. Išsaugokite abu išvedimus, nes sprendėjo ginčas išsprendžiamas greičiau dviem eilutėmis nei nustatymų puslapio ekrano kopija.
Tada išbandykite gedimo kelią, nes niekieno neišbandytas atsarginis variantas yra prielaida. Paverskite pageidaujamą sprendėją juoda skyle vienai užklausai ir stebėkite, kuris adresas grįš:
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32Ištrinkite tą maršrutą vos pasibaigus užklausai, kitaip kitas žmogus paveldės mįslę. Jei vidiniai vardai tame lange vis dar sprendžiami, į juos atsakė kažkas už numatytos srities. Jei jie vietoj to baigiasi laiku, atsarginio nėra arba jis teisingai apribotas, ir paties sprendėjo žurnalas pasakys, kuris iš dviejų tai buvo.
Nuspręskite: palikti, apriboti ar pašalinti
Palikite antrą sprendėją, kai jis atsako reikiamai vardų erdvei ir lieka pasiekiamas po profiliu. Apribokite jį, kai jis turi matyti vieną priesagą ir nieko daugiau, ir pašalinkite, kai jis neturi nei srities, nei dokumentuoto tikslo. Įrašas be darbo yra būsimas nutekėjimas be naudos, o tiekėjo numatytoji reikšmė nėra tikslas.
Užrašykite rezultatą keturiais stulpeliais: priesaga, sprendėjas, sąsaja ir savininkas. Ta eilutė atsako į kitą audito klausimą greičiau nei bet kokia ekrano kopija, ir ji išgyvena kliento atnaujinimą, kuris tyliai pertvarko sąrašą.