Split-DNS užfiksavimas: pasakykite, kur atliktas kiekvienas stebėjimas

Du žmonės sprendžia tą pačią Split-DNS problemą ir gauna skirtingus resolver adresus. Vienas naudojo paieškos įrankį, kitas fiksavo paketus adapteryje, o trečias perskaitė paties kliento diagnostiką. Nė vienas jų nemeluoja ir nė vienas neaprašo to paties etapo. Stebėjimo taško įvardijimas prieštaravimą paverčia žemėlapiu.

Viena paieška, keli stebėjimo taškai

Vienam vidiniam vardui yra bent penkios vietos, kur žiūrėti: programa ir jos kviečiamas resolver API, kliente galiojanti domeno politika, fiksavimas adapteryje ar filtre, kontroliuojama tinklų sietuvo riba ir resolver, kuris iš tikrųjų gauna užklausą.

Kiekvienas atsako į skirtingą klausimą, ir nė vienas vienas pats neįrodo, kur užklausa nukeliavo.

Fiksavimas adapteryje rodo paketus, o ne ketinimą. Jis nepasako, kokį resolver pasirinko klientas, o tuščias fiksavimas gali reikšti talpykloje saugomą atsakymą ar kitą resolver API, o ne atmestą paketą. Kiekvieną stebėjimą traktuokite kaip vieno etapo įrodymą. Tada etapus surinkite į kelią.

Kliento filtras yra tarp programos ir laido

VPN klientas su Split-DNS taiko domenų atitikimą prieš paketui paliekant mašiną. Tunelio priesagoje esantys vardai patenka į vidinį resolver; visa kita patenka į vietinį. Filtras yra politika, o politika gali skirtis priklausomai nuo platformos ir kliento versijos.

Cisco Secure Client Split-DNS gairės apima domenų atitikimą ir Windows filtrą, ir atskiria tai, ką programa mato naudodama vietinį resolver API, nuo to, ką mato toks įrankis kaip nslookup. Būtent šie skirtumai ir yra esmė.

Pradėkite nuo galiojančio profilio ir vienos įprastos programos paieškos. Bet koks testas, kuriame nurodomas konkretus serveris, yra tyčinis apylankis; paaiškinkite jį paties kliento diagnostika ir neleiskite jam tapti priėmimo kriterijumi.

nslookup eina kitu keliu nei programa

nslookup sukuria savo DNS užklausą ir gali apeiti operacinės sistemos resolver politiką. Tai daro jį naudingu įrankiu užduoti konkretų klausimą konkrečiam serveriui, ir klaidinančiu įrankiu tikrinti, ką patirs programa.

Windows sistemoje vardų sprendimo politikos lentelė nusprendžia, kuri priesaga naudoja kurį serverį. Ją perskaičius matoma politika, kurios laikysis programa, ir dažnai tai ir yra trūkstama dalis.

Perskaitykite politiką ir tada užduokite tą patį klausimą per įprastą resolver:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Užšifruoti resolveriai slepia užklausą, o ne ryšį

Naršyklė su savo DNS-over-HTTPS resolver yra visai kitas atvejis. Užklausa išeina TLS viduje, todėl paketų fiksavimas rodo ryšį su resolver adresu, bet ne klausiamą vardą.

Pirmiausia išsiaiškinkite valdomą naršyklės politiką, tada palyginkite ją su operacinės sistemos paieška. Naršyklė, kuriai leidžiama pasirinkti savo resolver, Split-DNS politikos gali apskritai nematyti.

Ta pati atsargumo priemonė galioja bet kuriam klientui, kuris atsineša savo resolver. Fiksavimas, kuris atpažįsta nuotolinį ryšį, nėra įrodymas apie užklausos vardą. Jei vardo reikia, paimkite jį iš paties resolver žurnalų arba iš programos diagnostikos, laikydamiesi taikomų privatumo taisyklių.

Palyginkite su pažymėtu testu

Pasirinkite patvirtintą vidinį vardą testavimui ir viešą vardą, neturintį jokios jautrios reikšmės. Kiekvienam užrašykite laiką, įrašo tipą, atsakymą ir tikėtą politiką.

Kur leidžiama, palyginkite resolver gavimą su vienu siauru kliento ar sietuvo stebėjimu:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

Niekada nesiųskite privačių vardų nesusijusiems viešiems resolveriams vien tam, kad sukurtumėte palyginimą, ir redaguokite viską, kuo dalijatės. Galiausiai atskirkite teisingą DNS atsakymą nuo po jo einančio paslaugos ryšio: išspręstas privatus adresas vis dar reikalauja maršruto ir programos leidimo.