Jinsi ya kukagua vitatuzi vya DNS ambavyo Mac yako hutumia kwenye VPN

scutil --dns huchapisha usanidi wa kitatuzi ambao macOS hushauriana nao kweli, si seva ile moja ya DNS uliyoandika kwenye paneli ya mipangilio. Matokeo ni marefu kuliko wengi wanavyotarajia, kwa sababu mfumo huweka vizuizi vya kitatuzi tofauti kwa njia ya kawaida, kwa violesura vyenye wigo na kwa uelekezaji maalum wa kikoa. Kizuizi kilicho juu ya matokeo si lazima kiwe kile kinachojibu swali. Ikiwa jina la faragha linatatuliwa ofisini na kushindwa wakati VPN inapoinuka, kutokulingana kuko kwenye kanuni za ulinganisho na njia, si kwenye anwani ya seva. Soma mpangilio kwanza, kisha uthibitishe jibu kwa utafutaji halisi.

Soma mpangilio wa vizuizi kabla ya anwani

Kila ingizo hufunguka kwa resolver #N na kuorodhesha nameserver[0], wakati mwingine if_index, mstari wa flags, reach na, kizuizi kisipokuwa cha kawaida rahisi, domain na orodha ya search domain. Kitatuzi namba 1 bila kikoa ni kile cha kawaida kinachoshughulikia majina ya umma. Kitu chochote kinachobeba Scoped kwenye bendera zake kimefungwa kwa kiolesura kinachoitwa na if_index, na kitu chochote kilichowekwa alama ya Supplemental kinatumika tu kwa vikoa vilivyoorodheshwa chini yake.

Uchaguzi ni ulinganisho wa kiambishi tamati. Kwa jina kama intranet.corp.example, macOS hupendelea kitatuzi ambacho ingizo lake la domain ni kiambishi tamati kinacholingana kirefu zaidi, kwa hiyo kizuizi kilicho na domain : corp.example hushinda kile cha kawaida hata kikiwa chini sana kwenye matokeo. order huamua sare kati ya vikoa vya urefu sawa. Mtazamo wa kwanza mara chache huhitaji zaidi: matokeo yote unapotaka kusoma kizuizi kimoja mwanzo hadi mwisho, mistari ya mwanzo kujifunza mpangilio wa vizuizi, na mzunguko uliochujwa unaochapisha vichwa vya vizuizi kando ya mistari ya sehemu. Vizuizi vyenye wigo huonekana chini ya kichwa chao na husomwa kama mwendelezo wa orodha iliyo juu yao, kwa hiyo weka kichwa machoni kila unaponukuu matokeo.

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'

Oanisha if_index na kiolesura cha handaki

Kielezo kinafaa tu ikiwa unaweza kutaja kiolesura kilicho nyuma yake. scutil --nwi huorodhesha taarifa za mtandao ambazo mfumo hushikilia, ikiwa ni pamoja na kiolesura cha msingi na ufikivu, wakati ifconfig -l hukupa majina, ambapo utun0 hadi utun9 ni watahiniwa wa handaki ambao mteja huunda kwa kawaida. Apple hutumia scutil --dns kama mfano wake wa ukaguzi kwenye mwongozo wa usambazaji, na huandika jinsi Network Extension inaweza kuelekeza vikoa vilivyochaguliwa kwa vitatuzi vilivyochaguliwa, ambayo ni mbinu ambayo vizuizi hivyo vyenye wigo huifichua.

Ukaguzi unaoamua swali ni kama kitatuzi kiko kwenye njia ambayo handaki iliweka:

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

Ikiwa route -n get hurudisha lango na kiolesura ambavyo havilingani na ingizo la kitatuzi, anwani inaweza kuwa sahihi kabisa na bado isifikike. Handaki lililogawanywa linalobeba tu subneti za shirika huweka pembeni maswali yaliyoelekezwa kwa seva ya DNS nje yao, na hitilafu huonekana kama muda wa kusubiri, ndiyo sababu matokeo ya usanidi yanaendelea kuonekana safi.

Uliza kitatuzi cha mfumo, kisha seva

Zana tatu hujibu maswali matatu tofauti, na kuchanganya hizo huzalisha hitimisho nyingi zisizo sahihi katika eneo hili. dscacheutil -q host -a name hupitia kitatuzi kilekile cha mfumo ambacho programu za kawaida hutumia, kwa hiyo vizuizi vyenye wigo na vya ziada hutumika. dig bila hoja ya seva husoma /etc/resolv.conf, ambayo si chanzo cha ukweli kwa utatuzi wenye wigo kwenye macOS, na inaruka kanuni za kila kikoa kabisa. dig @address hufikia seva moja hasa na haisemi chochote kuhusu uchaguzi.

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

Amri ya kwanza inapojibu na ya pili kurudisha NXDOMAIN, umepata mgawanyiko uliokuwa ukiusaka na hakuna kilichovunjika. Ya kwanza inapokosa muda wakati dig @10.20.0.53 ikijibu, kitatuzi hufanya kazi lakini hakiwezi kufikiwa kwenye njia iliyochaguliwa na handaki, kwa hiyo hatua inayofuata ni route -n get si kubadilisha mipangilio ya DNS. Weka majina ya faragha nje ya kitu chochote unachobandika kwenye tikiti au dokezo linaloshirikiwa.

Kile matokeo hayawezi kukuonyesha

Tabaka kadhaa hukaa juu ya orodha ya vitatuzi au kando yake, na kila moja inaweza kutuma swali mahali ambapo matokeo hayataji kamwe. Kivinjari kilicho na DNS salama hakiwezi kutatua kupitia chaneli yake iliyofichwa, hivyo ukurasa unaopakia wakati dscacheutil inakosa muda si ukinzani. Proksi ya DNS iliyowekwa na programu ya usalama hufanya kazi kama mtoa huduma wa Network Extension na huelekeza maswali yenyewe, na scutil --dns huonyesha kilichosanidiwa, si anwani ya juu ambayo proksi ilitumia mwishowe. Vikoa vya utafutaji vinaongeza mkunjo wa tatu: jina lisilo na sifa huongezewa kila kiambishi tamati kilichoorodheshwa kwa mpangilio, kwa hiyo kizuizi kilichojibu kinaweza kuwa kile ambacho hukuwahi kukishuku.

Majibu yaliyopitwa na wakati ni ya bei nafuu kuyaondoa na yanayorukwa mara nyingi:

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

Ikiwa matokeo yatabadilika baada ya kusafisha, hali ilikuwa kwenye akiba na matokeo ya awali yalielezea handaki ambalo halikuwepo tena. Ikiwa hayatabadilika, usanidi ni kama ulivyo, na swali huhamia kwenye njia na kwenye sera za programu.

Kijitabu kifupi cha kabla na baada

Chukua mstari wa msingi pale tu sera inaporuhusu, na uweke faili nje ya folda yoyote iliyosawazishwa. Mpangilio ulio chini ni ule ninaoendesha kwenye mashine za wateja: chukua mstari wa msingi, unganisha, chukua tena, kisha linganisha na utafute.

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

Soma tofauti kwa vizuizi si kwa mistari. Kitatuzi kipya chenye wigo kinachobeba kielezo cha kiolesura cha handaki na ingizo la domain kwa kiambishi tamati cha faragha ndicho umbo linalotarajiwa. Kitatuzi kipya cha kawaida kinachoelekeza kwenye anwani ya umma ni ugunduzi unaostahili kupelekwa kwa mmiliki wa wasifu wa mteja. Kisha rudia utafutaji ndani ya programu iliyoshindwa kweli, si kwenye shell tu, na uandike kiolesura kutoka route -n get kando ya matokeo.

Ili kubatilisha mabadiliko, tenganisha na urudie kuchukua mstari wa msingi. Ikiwa kizuizi chenye wigo kimekwenda, mteja amejisafisha. Ikiwa kizuizi bado kimeorodheshwa dhidi ya kiolesura ambacho hakipo tena, hali imepitwa na wakati, na kusafisha pamoja na kuunganisha tena ndio marekebisho laini zaidi kabla ya mtu yeyote kugusa wasifu.

Ukaguzi nne kwa mpangilio huu: kama kizuizi cha kitatuzi kinaoana na kiambishi tamati kirefu zaidi cha jina; kama kizuizi hicho kimefungwa kwa kiolesura ambacho handaki liliweka; kama njia kuelekea seva yake ya majina inatumia handaki; na kama kitatuzi cha mfumo, si dig, ndicho kinarudisha jibu. Ukaguzi wa kwanza unaoshindwa hukuambia kama ubadilishe sera ya DNS, njia za handaki au programu. Ikiwa zote nne zinapita na jina bado linashindwa, tatizo liko juu ya DNS, na kitu kinachofuata cha kukagua ni kitu chochote kinachojibu bandari 53 mbele yake.