Ang iyong VPN ay nagtutulak ng tatlong DNS server: alin ang sumasagot?

Buksan ang pahina ng mga setting pagkatapos kumonekta at tatlong DNS address ang nakalista; ang tanong ng audit ay kung alin ang humawak sa huli mong query. Ang bilang lamang ay walang sinasagot, dahil ang push ng kliyente, isang pisikal na interface at isang patakaran kada domain ay lahat nagsusulat sa iisang view. Ang mga entry na ito ay may magkakaibang saklaw, at saklaw, hindi posisyon, ang nagpapasya kung sino ang sumasagot. Magsimula sa paghihiwalay ng mga pinagmulan, pagkatapos subukan ang may-ari ng pangalang mahalaga sa iyo.

Bakit mas mahaba ang listahan kaysa sa iyong profile

Ang kliyente ng VPN ay nagtutulak ng mga address ng resolver para sa link ng tunnel, at itinatago ng operating system ang mga ito sa tabi ng dati nang taglay ng pisikal na interface. Isang router, isang corporate DHCP lease, isang pangalawang VPN at isang patakaran kada domain ang bawat isa ay nagdaragdag ng sariling entry. Kaya ang tatlong address sa pahina ay maaaring mangahulugang tatlong saklaw, hindi tatlong kandidato para sa isang gawain. Ang pagbasa sa bilang bilang patunay ng pagtagas ay ang unang pagkakamali sa audit na ito.

Sa loob ng isang interface, sinusubukan ng kliyente ang mga server nito sa pagkakasunod-sunod, kaya ang nakaayos na listahan ay hindi walang saysay. Ang hindi pila ay ang pinagsamang view, kung saan magkatabi ang mga entry mula sa profile, pisikal na link at mga tuntunin kada domain nang walang isang ranggo. Ang pagkakaibang iyon ang nagpapasya kung ano ang susubukan mo: ipinapaliwanag ng pagkakasunod-sunod ang pag-uugali sa loob ng isang saklaw, at ipinapaliwanag ng saklaw ang lahat ng iba pa.

Binabasag ng naka-encrypt na DNS ang larawan mula sa loob ng isang aplikasyon. Ang browser o chat client na may sariling resolver na DNS-over-HTTPS ay nagpapadala ng mga query nang lampas sa listahan ng operating system, kaya ang mga address sa pahina ng setting ay naglalarawan ng trapikong hindi kailanman ginawa ng app. Suriin ang sariling setting ng resolver ng app bago sisihin ang profile sa isang pangalang lumabas na mali.

Ano ang sinasabi ng bawat isa sa tatlong pagsusuri

Ang bawat pinagmulan ay nag-iiwan ng bakas sa ibang lugar, at walang isang utos na nagpapakita ng lahat. Ito ang mapping na sulit itago sa tabi ng pahina ng setting:

Sa sistemang gumagamit ng systemd-resolved, ang resolvectl status ang awtoridad, dahil iniuulat nito ang DNS kada link kasama ang mga domain ng routing. Sumasagot ang macOS sa pamamagitan ng scutil --dns, na naglilista ng mga resolver na may saklaw sa ayos ng pagsubok. Hinahati ng Windows ang dalawang kalahati: Get-DnsClientServerAddress para sa mga server kada interface at Get-DnsClientNrptPolicy para sa mga tuntunin ng suffix. Patakbuhin ang utos na kabilang sa resolver na aktuwal na ginagamit, dahil ang makinang may container runtime at desktop resolver ay maaaring may higit sa isang naka-install.

Isang backup na resolver na hindi makasagot para sa iyong zone

Ang pangalawang entry ay karaniwang naroon para sa availability, at gumagana lamang ang availability kung alam ng backup ang mga pangalan. Tanungin ang pampublikong resolver ng panloob na hostname at magbabalik ito ng NXDOMAIN, o isang wildcard na sagot mula sa search domain na walang kaugnayan sa iyo. Ang failover na walang sinumang nagsuri ay gumagawa ng pagkawala sa eksaktong sandaling kailangan ito.

Umiiral ang Split DNS para pigilan iyon: ang mga suffix ng kumpanya ay pumupunta sa resolver na may hawak ng zone, at ang mga pampublikong pangalan ay nananatili sa default na landas. Matatag ang disenyo, at nakadepende ito sa pagkakumpleto ng listahan ng suffix. Idinodokumento ng Microsoft ang patakaran ng resolver kada suffix na nagpapatakbo nito sa Windows, at ang parehong ideya ay lumilitaw bilang mga domain ng routing sa systemd-resolved at bilang mga resolver na may saklaw sa macOS.

Ihambing ang mga zone na maaaring sagutin ng backup sa mga suffix na nasa patakaran. Nahanap ng paghahambing na iyon ang puwang bago iulat ng isang user na tumigil nang malutas ang isang panloob na site pagkatapos ng pagbabago sa tunnel.

Magtanong sa pamamagitan ng patakaran, hindi paligid nito

Magtanong sa pamamagitan ng resolver ng operating system, dahil ang direktang query sa isang server ay lumalampas sa patakaran at iniuulat lamang ang sasabihin ng server na iyon. Ang puwang sa pagitan ng dalawang sagot ang buong punto:

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

Kung ang query ng system ay nagbabalik ng pribadong address habang ang direktang query ay nagbabalik ng NXDOMAIN, gumagana ang patakaran at ang backup ang mahinang punto. Kung pareho silang nagbabalik ng parehong pampublikong sagot, ang pangalan ay nilulutas sa labas ng saklaw na nilayon mo, at ang listahan ng suffix ang lugar na dapat tingnan. Itago ang parehong output, dahil ang pagtatalo tungkol sa resolver ay natatapos nang mas mabilis sa dalawang linya kaysa sa screenshot ng pahina ng setting.

Pagkatapos ay sanayin ang landas ng kabiguan, dahil ang backup na walang sinumang sumubok ay isang palagay. Gawing black hole ang ginustong resolver para sa isang query at tingnan kung aling address ang bumabalik:

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

Burahin ang rutang iyon kaagad pagkatapos ng query, o mamanahin ng susunod na tao ang isang misteryo. Kung ang mga panloob na pangalan ay nalulutas pa rin sa window na iyon, may sumagot sa mga ito mula sa labas ng nilayon na saklaw. Kung sa halip ay nag-time out sila, nawawala ang backup o wastong na-scope ito, at ang sariling log ng resolver ang magsasabi kung alin sa dalawa.

Magpasya: panatilihin, limitahan o alisin

Panatilihin ang pangalawang resolver kapag sinasagot nito ang namespace na kailangan mo at nananatiling maabot sa ilalim ng profile. Limitahan ito kapag isang suffix lamang at wala nang iba ang dapat nitong makita, at alisin ito kapag wala itong saklaw o dokumentadong layunin. Ang entry na walang gawain ay isang pagtagas sa hinaharap na walang pakinabang, at ang default ng vendor ay hindi layunin.

Itala ang resulta sa apat na kolum: suffix, resolver, interface at may-ari. Ang linyang iyon ay sumasagot sa susunod na tanong ng audit nang mas mabilis kaysa sa anumang screenshot, at nakakaligtas ito sa update ng kliyente na tahimik na muling nag-aayos ng listahan.