Jūsu VPN nosūta trīs DNS serverus: kurš atbild?

Pēc savienojuma atveriet iestatījumu lapu, un tajā ir uzskaitītas trīs DNS adreses; audita jautājums ir, kura apstrādāja jūsu pēdējo vaicājumu. Tikai skaits neko neatbild, jo klienta grūdiens, fiziskā saskarne un politika katram domēnam visi raksta vienā skatā. Šiem ierakstiem ir dažādi apjomi, un atbildētāju nosaka apjoms, nevis pozīcija. Sāciet ar avotu atdalīšanu, pēc tam pārbaudiet to, kuram pieder jums svarīgais nosaukums.

Kāpēc saraksts ir garāks par jūsu profilu

VPN klients nosūta atrisinātāja adreses tuneļa savienojumam, un operētājsistēma tās glabā blakus tam, kas fiziskajai saskarnei jau bija. Maršrutētājs, uzņēmuma DHCP noma, otrs VPN un politika katram domēnam katrs pievieno savu ierakstu. Tāpēc trīs adreses lapā var nozīmēt trīs apjomus, nevis trīs kandidātus vienam uzdevumam. Skaita lasīšana kā noplūdes pierādījums ir šī audita pirmā kļūda.

Vienas saskarnes ietvaros klients patiešām izmēģina savus serverus pēc kārtas, tāpēc sakārtots saraksts nav bezjēdzīgs. Tas, kas nav rinda, ir apvienotais skats, kur profila, fiziskā savienojuma un noteikumu katram domēnam ieraksti stāv blakus bez viena vienota ranžējuma. Šī atšķirība nosaka, ko jūs pārbaudāt: secība izskaidro uzvedību viena apjoma ietvaros, un apjoms izskaidro visu pārējo.

Šifrēts DNS salauž ainu no lietojumprogrammas iekšpuses. Pārlūks vai tērzēšanas klients ar savu DNS-over-HTTPS atrisinātāju sūta vaicājumus pilnībā garām operētājsistēmas sarakstam, tāpēc iestatījumu lapas adreses apraksta satiksmi, ko lietojumprogramma nekad nav radījusi. Pirms vainot profilu nepareizi iegūtā nosaukumā, pārbaudiet pašas lietojumprogrammas atrisinātāja iestatījumu.

Ko saka katra no trim pārbaudēm

Katrs avots atstāj savu pēdu citā vietā, un neviena komanda neparāda visus. Šis ir kartējums, ko ir vērts turēt blakus iestatījumu lapai:

Sistēmā, kas izmanto systemd-resolved, resolvectl status ir autoritatīva, jo tā ziņo par DNS katram savienojumam kopā ar maršrutēšanas domēniem. macOS atbild caur scutil --dns, kas uzskaita apjoma atrisinātājus to izmēģināšanas secībā. Windows sadala divas puses: Get-DnsClientServerAddress saskarnes serveriem un Get-DnsClientNrptPolicy sufiksa noteikumiem. Izpildiet komandu, kas pieder faktiski izmantotajam atrisinātājam, jo mašīnā ar konteineru izpildlaika vidi un darbvirsmas atrisinātāju var būt instalēts vairāk nekā viens.

Rezerves atrisinātājs, kas nevar atbildēt par jūsu zonu

Otrs ieraksts parasti ir pieejamības dēļ, un pieejamība darbojas tikai tad, ja rezerve zina nosaukumus. Pajautājiet publiskam atrisinātājam iekšēju resursdatora nosaukumu, un tas atgriež NXDOMAIN vai aizstājējzīmes atbildi no meklēšanas domēna, kuram ar jums nav nekāda sakara. Neviena pārbaudīta pāreja tad rada pārtraukumu tieši tajā brīdī, kad tā ir vajadzīga.

Split DNS pastāv, lai to novērstu: uzņēmuma sufiksi dodas pie atrisinātāja, kuram ir zona, un publiskie nosaukumi paliek noklusējuma ceļā. Dizains ir stabils, un tas ir atkarīgs no tā, vai sufiksu saraksts ir pilnīgs. Microsoft dokumentē sufiksa atrisinātāja politiku, kas to vada Windows vidē, un tā pati ideja parādās kā maršrutēšanas domēni systemd-resolved un kā apjoma atrisinātāji macOS.

Salīdziniet zonas, par kurām rezerve drīkst atbildēt, ar politikā esošajiem sufiksiem. Šis salīdzinājums atrod plaisu pirms tam, kad lietotājs ziņo, ka viena iekšējā vietne pēc tuneļa maiņas pārstāja atrisināties.

Vaicājiet caur politiku, nevis tai apkārt

Vaicājiet caur operētājsistēmas atrisinātāju, jo tiešs vaicājums serverim apiet politiku un ziņo tikai to, ko šis serveris teiktu. Atšķirība starp abām atbildēm ir visa būtība:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

Ja sistēmas vaicājums atgriež privātu adresi, bet tiešais vaicājums atgriež NXDOMAIN, politika darbojas un vājā vieta ir rezerve. Ja abi atgriež vienu un to pašu publisko atbildi, nosaukums tiek atrisināts ārpus paredzētā apjoma, un sufiksu saraksts ir vieta, kur skatīties. Saglabājiet abas izvades, jo atrisinātāja strīds tiek atrisināts ātrāk ar divām rindām nekā ar iestatījumu lapas ekrānuzņēmumu.

Pēc tam izmēģiniet kļūmes ceļu, jo rezerve, kuru neviens nav pārbaudījis, ir pieņēmums. Padariet vēlamo atrisinātāju par melno caurumu vienam vaicājumam un vērojiet, kura adrese atgriežas:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

Izdzēsiet šo maršrutu, tiklīdz vaicājums ir pabeigts, pretējā gadījumā nākamā persona manto noslēpumu. Ja iekšējie nosaukumi tajā logā joprojām tiek atrisināti, uz tiem atbildēja kaut kas ārpus paredzētā apjoma. Ja tie tā vietā beidzas ar taimautu, rezerves nav vai tā ir pareizi ierobežota, un paša atrisinātāja žurnāls pasaka, kurš no diviem tas bija.

Izlemiet: paturēt, ierobežot vai noņemt

Paturiet otru atrisinātāju, ja tas atbild uz nepieciešamo nosaukumu telpu un paliek sasniedzams profila ietvaros. Ierobežojiet to, ja tam jāredz viens sufikss un nekas cits, un noņemiet, ja tam nav ne apjoma, ne dokumentēta mērķa. Ieraksts bez darba ir nākotnes noplūde bez ieguvuma, un piegādātāja noklusējums nav mērķis.

Ierakstiet rezultātu četrās kolonnās: sufikss, atrisinātājs, saskarne un īpašnieks. Šī rinda atbild uz nākamo audita jautājumu ātrāk nekā jebkurš ekrānuzņēmums, un tā pārdzīvo klienta atjauninājumu, kas klusi pārkārto sarakstu.