Paano siyasatin ang mga DNS resolver na ginagamit ng iyong Mac sa VPN

scutil --dns ay inililimbag ang resolver configuration na talagang kinukonsulta ng macOS, hindi ang nag-iisang DNS server na itinipa mo sa isang panel ng settings. Mas mahaba ang output kaysa inaasahan ng karamihan, dahil nagtatago ang system ng hiwalay na resolver blocks para sa default path, para sa mga interface na may saklaw at para sa pagpapasa na partikular sa domain. Ang bloke sa itaas ng output ay hindi laging ang sumasagot sa query. Kung ang isang pribadong pangalan ay naleres sa opisina at nabigo sa sandaling umakyat ang VPN, ang pagkakaiba ay nasa mga tuntunin ng pagtutugma at sa mga ruta, hindi sa address ng server. Basahin muna ang pagkakasunod-sunod, pagkatapos patunayan ang sagot sa tunay na paghahanap.

Basahin ang pagkakasunod-sunod ng bloke bago ang mga address

Bawat entry ay nagbubukas sa resolver #N at naglilista ng nameserver[0], kung minsan if_index, isang linya ng flags, reach at, kapag ang bloke ay hindi simpleng default, isang domain at isang listahan ng search domain. Ang resolver numero 1 na walang domain ang default na humahawak ng mga pampublikong pangalan. Anumang may Scoped sa mga flag nito ay nakatali sa interface na pinangalanan ng if_index, at anumang minarkahan ng Supplemental ay nalalapat lamang sa mga domain na nakalista sa ilalim nito.

Ang pagpili ay pagtutugma ng suffix. Para sa pangalang tulad ng intranet.corp.example, mas gusto ng macOS ang resolver na ang entry na domain ay ang pinakamahabang tumutugmang suffix, kaya ang bloke na may domain : corp.example ay nananalo sa default kahit na nasa ilalim ito ng output. Ang order ay nagtatakda ng tabla sa pagitan ng mga domain na magkapareho ang haba. Bihirang mangailangan ng higit pa ang unang tingin: ang buong output kapag gusto mong basahin ang isang bloke mula umpisa hanggang dulo, ang mga paunang linya para matutunan ang pagkakasunod-sunod ng bloke, at isang sinasala na pag-ikot na naglilimbag ng mga header ng bloke sa tabi ng mga linya ng field. Lumilitaw ang mga bloke na may saklaw sa ilalim ng sarili nilang header at binabasa na parang karugtong ng listahan sa itaas nila, kaya panatilihin ang header sa paningin tuwing sinisipi mo ang output.

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

Itugma ang if_index sa interface ng tunel

Ang index ay kapaki-pakinabang lamang kung maipapangalan mo ang interface sa likod nito. Inililista ng scutil --nwi ang impormasyon ng network na hawak ng system, kabilang ang pangunahing interface at maabot, habang ang ifconfig -l ay nagbibigay sa iyo ng mga pangalan, kung saan ang utun0 hanggang utun9 ang mga kandidato sa tunel na karaniwang ginagawa ng isang kliyente. Ginagamit ng Apple ang scutil --dns bilang sarili nitong halimbawa ng pagsiyasat sa gabay sa paglalang, at idinodokumento kung paano maaaring itulak ng Network Extension ang mga piling domain sa mga piling resolver, na siyang mekanismong inilalantad ng mga bloke na may saklaw.

Ang pagsusuring nagtatakda ng tanong ay kung ang resolver ay nakaupo sa rutang inilagay ng tunel:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

Kung ang route -n get ay nagbabalik ng gateway at interface na hindi tumutugma sa entry ng resolver, ang address ay maaaring perpektong tama at gayon pa man hindi maabot. Ang hinati na tunel na nagdadala lamang ng mga subnet ng korporasyon ay nagtatapon ng mga query na patungo sa isang DNS server sa labas ng mga ito, at ang kabiguan ay lumilitaw bilang timeout, kaya patuloy na mukhang malinis ang output ng configuration.

Tanungin ang system resolver, pagkatapos ang server

Tatlong kasangkapan ang sumasagot sa tatlong magkaibang tanong, at ang paghahalo sa mga ito ay gumagawa ng karamihan ng maling konklusyon sa larangang ito. Ang dscacheutil -q host -a name ay dumadaan sa parehong system resolver na ginagamit ng mga ordinaryong aplikasyon, kaya nalalapat ang mga bloke na may saklaw at pandagdag. Ang dig na walang argumento ng server ay nagbabasa ng /etc/resolv.conf, na hindi ang pinagmumulan ng katotohanan para sa resolution na may saklaw sa macOS, at ganap nitong nilalaktawan ang mga tuntunin kada domain. Ang dig @address ay umabot sa eksaktong isang server at walang sinasabi tungkol sa pagpili.

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

Kapag ang unang utos ay sumagot at ang pangalawa ay nagbalik ng NXDOMAIN, natagpuan mo ang paghahati na hinahanap mo at walang nasira. Kapag ang una ay nauubusan ng oras habang ang dig @10.20.0.53 ay sumasagot, gumagana ang resolver ngunit hindi maabot sa rutang pinili ng tunel, kaya ang susunod na hakbang ay route -n get at hindi isang pagbabago sa mga setting ng DNS. Ilayo ang mga pribadong pangalan sa anumang idinidikit mo sa isang ticket o sa isang ibinahaging tala.

Ano ang hindi maipakita sa iyo ng output

Ilang suson ang nakaupo sa itaas o sa tabi ng listahan ng resolver, at bawat isa ay makapagpapadala ng query sa isang lugar na hindi binabanggit ng output. Ang isang browser na may naka-enable na secure DNS ay maaaring mag-resolve sa sarili nitong naka-encrypt na channel, kaya ang isang pahinang naglo-load habang nag-timeout ang dscacheutil ay hindi kontradiksyon. Ang isang DNS proxy na inilagay ng security software ay tumatakbo bilang provider ng Network Extension at siya mismo ang nagpapasa ng mga query, at ang scutil --dns ay nagpapakita kung ano ang na-configure, hindi ang upstream address na ginamit ng proxy sa huli. Ang mga search domain ay nagdaragdag ng ikatlong kulubot: ang isang hindi kwalipikadong pangalan ay dinadagdagan ng bawat nakalista na suffix nang sunod-sunod, kaya ang bloke na sumagot ay maaaring isa na hindi mo kailanman pinaghinalaan.

Ang mga lumang sagot ay ang pinakamurang ibukod at ang pinakamadalas na nalalaktawan:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

Kung ang output ay nagbago pagkatapos ng pag-flush, ang estado ay naka-cache at inilarawan ng naunang output ang isang tunel na wala na. Kung hindi ito nagbago, ang configuration ay kung ano ito, at lumilipat ang tanong sa mga ruta at sa patakaran ng aplikasyon.

Isang maikling runbook para sa bago at pagkatapos

Kumuha ng baseline lamang kung saan pinapayagan ng patakaran, at ilayo ang mga file sa anumang naka-sync na folder. Ang pagkakasunod-sunod sa ibaba ang isinasagawa ko sa mga makina ng kliyente: kunin ang baseline, kumonekta, kumuha muli, pagkatapos ihambing at hanapin.

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

Basahin ang pagkakaiba kada bloke kaysa kada linya. Ang isang bagong resolver na may saklaw na nagdadala ng index ng interface ng tunel at isang entry na domain para sa pribadong suffix ay ang inaasahang hugis. Ang isang bagong default resolver na nakaturo sa isang pampublikong address ay isang natuklasan na sulit iharap sa may-ari ng profile ng kliyente. Pagkatapos ay ulitin ang paghahanap sa loob ng aplikasyong talagang nabigo, hindi lamang sa shell, at itala ang interface mula sa route -n get sa tabi ng resulta.

Upang baligtarin ang isang pagbabago, idiskonekta at ulitin ang pagkuha ng baseline. Kung nawala ang bloke na may saklaw, nilinis ng kliyente ang sarili nito. Kung ang bloke ay nakalista pa rin laban sa isang interface na wala na, ang estado ay luma na, at ang pag-flush kasama ang muling pagkonekta ang pinakamalambot na pagwawasto bago may humawak sa profile.

Apat na pagsusuri, sa ganitong pagkakasunod-sunod: tumutugma ba ang isang bloke ng resolver sa pinakamahabang suffix ng pangalan; nakatali ba ang bloke sa interface na inilagay ng tunel; ginagamit ba ng ruta patungo sa server ng pangalan nito ang tunel; at ang system resolver, hindi ang dig, ba ang nagbabalik ng sagot. Ang unang pagsusuring nabigo ay nagsasabi sa iyo kung babaguhin ang patakaran ng DNS, ang mga ruta ng tunel o ang aplikasyon. Kung pumasa ang lahat ng apat at nabigo pa rin ang pangalan, ang problema ay nasa itaas ng DNS, at ang susunod na dapat siyasatin ay anumang sumasagot sa port 53 sa harap nito.