Teie VPN lükkab kolm DNS-serverit: milline vastab?
Lisakanded võivad olla varuvariant, domeenipõhine marsruut või füüsilise lingi jääk. Seostage igaüks oma ulatusega, enne kui nimetate loendi lekkimiseks.
Avage pärast ühendamist seadete leht ja näete kolme DNS-aadressi; auditi küsimus on, milline neist käsitles teie viimast päringut. Ainuüksi arv ei vasta millelegi, sest kliendi tõuge, füüsiline liides ja domeenipõhine poliitika kirjutavad kõik samasse vaatesse. Need kanded kannavad erinevaid ulatusi ning vastaja määrab ulatus, mitte asukoht. Alustage allikate eraldamisest ja seejärel testige seda, kellele kuulub teile oluline nimi.
Miks loend on teie profiilist pikem
VPN-klient lükkab tunnellingi jaoks resolveri aadresse ning operatsioonisüsteem hoiab neid selle kõrval, mis füüsilisel liidesel juba oli. Ruuter, ettevõtte DHCP-rendileping, teine VPN ja domeenipõhine poliitika lisavad igaüks oma kande. Seega võivad kolm aadressi lehel tähendada kolme ulatust, mitte kolme kandidaati ühe töö jaoks. Arvu lugemine lekkimise tõendiks on selle auditi esimene viga.
Ühe liidese sees proovib klient oma servereid tõepoolest järjest, seega järjestatud loend pole mõttetu. See, mis ei ole järjekord, on ühendatud vaade, kus profiili, füüsilise lingi ja domeenipõhiste reeglite kanded seisavad kõrvuti ilma üheainsa pingereata. See eristus määrab, mida te testite: järjekord selgitab käitumist ühe ulatuse sees ja ulatus selgitab kõike muud.
Krüpteeritud DNS rikub pildi rakenduse seest. Brauser või vestlusklient oma DNS-over-HTTPS-resolveriga saadab päringud täiesti mööda operatsioonisüsteemi loendist, seega kirjeldavad seadete lehe aadressid liiklust, mida rakendus kunagi ei tekitanud. Kontrollige rakenduse enda resolveri seadet enne, kui süüdistate profiili valesti välja tulnud nime pärast.
Mida iga kolm kontrolli ütleb
Iga allikas jätab oma jälje erinevasse kohta ja ükski üksik käsk ei näita neid kõiki. See on vastendus, mida tasub hoida seadete lehe kõrval:
| 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 |
Süsteemis, mis kasutab systemd-resolved, on autoriteetne resolvectl status, sest see raporteerib DNS-i lingi kohta koos marsruutimisdomeenidega. macOS vastab scutil --dns kaudu, mis loetleb ulatuslikud resolverid nende proovimise järjekorras. Windows jagab kaks poolt: Get-DnsClientServerAddress liidesepõhiste serverite jaoks ja Get-DnsClientNrptPolicy sufiksireeglite jaoks. Käivitage käsk, mis kuulub tegelikult kasutatavale resolverile, sest konteinerite töökeskkonna ja töölaua resolveriga masinas võib olla paigaldatud rohkem kui üks.
Varuresolver, mis ei suuda teie tsooni vastata
Teine kanne on tavaliselt seal kättesaadavuse pärast ja kättesaadavus töötab ainult siis, kui varu teab nimesid. Küsige avalikult resolverilt sisemist hostinime ja see tagastab NXDOMAIN või metamärgi-vastuse otsingudomeenist, millel pole teiega mingit seost. Kontrollimata varuüleminek tekitab seejärel katkestuse täpselt sel hetkel, mil seda vajatakse.
Split DNS on olemas, et seda ära hoida: ettevõtte sufiksid lähevad resolverile, kes hoiab tsooni, ja avalikud nimed jäävad vaiketeekonnale. Disain on korrektne ja see sõltub sellest, et sufiksite loend oleks täielik. Microsoft dokumenteerib sufiksipõhise resolveripoliitika, mis seda Windowsis juhib, ja sama idee ilmub marsruutimisdomeenidena systemd-resolvedis ning ulatuslike resolveritena macOS-is.
Võrrelge tsoone, millele varu võib vastata, poliitikas olevate sufiksitega. See võrdlus leiab lünga enne, kui kasutaja teatab, et üks sisemine sait lakkas pärast tunnelimuudatust lahendamast.
Küsige poliitika kaudu, mitte sellest mööda
Küsige operatsioonisüsteemi resolveri kaudu, sest serverile otse suunatud päring möödub poliitikast ja raporteerib ainult seda, mida see server ütleks. Kahe vastuse vahe ongi kogu mõte:
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53Kui süsteemipäring tagastab privaatse aadressi, samal ajal kui otsene päring tagastab NXDOMAIN, siis poliitika töötab ja nõrk koht on varu. Kui mõlemad tagastavad sama avaliku vastuse, lahendatakse nimi väljaspool kavandatud ulatust ja sufiksite loend on koht, kuhu vaadata. Hoidke mõlemad väljundid alles, sest resolverivaidlus laheneb kahe reaga kiiremini kui seadete lehe ekraanipildiga.
Seejärel harjutage tõrketeed, sest varu, mida keegi ei testinud, on oletus. Muutke eelistatud resolver ühe päringu jaoks mustaks auguks ja vaadake, milline aadress tagasi tuleb:
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32Kustutage see marsruut kohe, kui päring lõpeb, muidu pärib järgmine inimene mõistatuse. Kui sisemised nimed selles aknas veel lahenduvad, vastas neile midagi väljaspool kavandatud ulatust. Kui need hoopis aeguvad, puudub varu või on see õigesti piiratud, ja resolveri enda logi ütleb teile, kumb see oli.
Otsustage: hoida, piirata või eemaldada
Hoidke teist resolverit, kui see vastab vajalikule nimeruumile ja jääb profiili all kättesaadavaks. Piirake seda, kui see peaks nägema ühte sufiksit ja mitte midagi muud, ning eemaldage see, kui sellel pole ei ulatust ega dokumenteeritud eesmärki. Tööta kanne on tulevane leke ilma kasutegurita ja tarnija vaikeväärtus ei ole eesmärk.
Kirjutage tulemus nelja veergu: sufiks, resolver, liides ja omanik. See rida vastab järgmisele auditiküsimusele kiiremini kui ükski ekraanipilt ja püsib üle kliendi uuenduse, mis loendi vaikselt ümber järjestab.