Kako preveriti DNS-resolverje, ki jih vaš Mac uporablja v VPN

scutil --dns izpiše konfiguracijo resolverja, ki jo macOS res uporablja, ne tistega enega strežnika DNS, ki ste ga vnesli v ploščo z nastavitvami. Izpis je daljši, kot večina pričakuje, ker sistem hrani ločene bloke resolverja za privzeto pot, za vmesnike z obsegom in za posredovanje, specifično za domeno. Blok na vrhu izpisa ni nujno tisti, ki odgovori na poizvedbo. Če se zasebno ime v pisarni razreši in odpove v trenutku, ko se VPN dvigne, je neskladje v pravilih ujemanja in v poteh, ne v naslovu strežnika. Najprej preberite vrstni red, nato dokažite odgovor z resničnim iskanjem.

Preberite vrstni red blokov pred naslovi

Vsak vnos se odpre s resolver #N in našteje nameserver[0], včasih if_index, vrstico flags, reach in, ko blok ni preprosta privzeta vrednost, tudi domain in seznam search domain. Resolver številka 1 brez domene je privzeti, ki obravnava javna imena. Vse, kar v svojih zastavicah nosi Scoped, je vezano na vmesnik, ki ga imenuje if_index, in vse označeno z Supplemental velja le za domene, naštete pod njim.

Izbira je ujemanje pripone. Za ime, kot je intranet.corp.example, macOS raje izbere resolver, katerega vnos domain je najdaljša ujemajoča se pripone, zato blok z domain : corp.example premaga privzeto tudi, ko stoji zelo nizko v izpisu. order odloči izenačenja med domenami enake dolžine. Prvi pogled redko potrebuje več: celoten izpis, ko želite prebrati en blok od začetka do konca, uvodne vrstice za spoznavanje vrstnega reda blokov in filtriran prehod, ki izpiše glave blokov ob vrsticah polj. Bloki z obsegom se pojavijo pod svojo glavo in se berejo kot nadaljevanje seznama nad njimi, zato imejte glavo v vidnem polju, kadar koli citirate izpis.

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'

Povežite if_index z vmesnikom tunela

Kazalo je uporabno le, če lahko poimenujete vmesnik za njim. scutil --nwi našteje omrežne informacije, ki jih sistem hrani, vključno s primarnim vmesnikom in dosegljivostjo, medtem ko vam ifconfig -l da imena, kjer so utun0 do utun9 kandidati za tunel, ki jih odjemalec običajno ustvari. Apple uporablja scutil --dns kot svoj lastni primer pregleda v vodniku za uvajanje, in dokumentira, kako lahko Network Extension usmerja izbrane domene k izbranim resolverjem, kar je mehanizem, ki ga razkrivajo ti bloki z obsegom.

Preveritev, ki razreši vprašanje, je, ali resolver sedi na poti, ki jo je namestil tunel:

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

Če route -n get vrne prehod in vmesnik, ki se ne ujemata z vnosom resolverja, je naslov lahko popolnoma pravilen in vseeno nedosegljiv. Razdeljen tunel, ki prenaša le poslovna podomrežja, zavrže poizvedbe, usmerjene na strežnik DNS zunaj njih, in napaka se pokaže kot prekoračitev časa, zato je izpis konfiguracije še vedno videti čist.

Vprašajte sistemski resolver, nato strežnik

Tri orodja odgovarjajo na tri različna vprašanja, njihovo mešanje pa ustvarja večino napačnih sklepov na tem področju. dscacheutil -q host -a name gre skozi isti sistemski resolver, kot ga uporabljajo običajne aplikacije, zato veljajo bloki z obsegom in dopolnilni bloki. dig brez argumenta strežnika bere /etc/resolv.conf, kar ni vir resnice za razreševanje z obsegom na macOS, in popolnoma preskoči pravila za posamezne domene. dig @address doseže natanko en strežnik in ne pove nič o izbiri.

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

Ko prvi ukaz odgovori in drugi vrne NXDOMAIN, ste našli delitev, ki ste jo iskali, in nič ni pokvarjeno. Ko prvi prekorači čas, medtem ko dig @10.20.0.53 odgovarja, resolver deluje, vendar ni dosegljiv na poti, ki jo je izbral tunel, zato je naslednji korak route -n get, ne pa spreminjanje nastavitev DNS. Zasebna imena imejte zunaj vsega, kar prilepite v zahtevo ali deljeno opombo.

Česa vam izpis ne more pokazati

Nekaj plasti sedi nad seznamom resolverjev ali ob njem in vsaka lahko pošlje poizvedbo nekam, česar izpis nikoli ne omenja. Brskalnik z vklopljenim varnim DNS lahko razrešuje prek svojega šifriranega kanala, zato stran, ki se naloži, medtem ko dscacheutil prekorači čas, ni protislovje. Proxy DNS, ki ga namesti varnostna programska oprema, teče kot ponudnik Network Extension in sam posreduje poizvedbe, scutil --dns pa pokaže, kaj je bilo konfigurirano, ne naslova nad njim, ki ga je proxy nazadnje uporabil. Domene iskanja dodajo tretjo gubo: nekvalificiranemu imenu se po vrsti doda vsaka našteta pripona, zato je blok, ki je odgovoril, lahko tak, kot si ga nikoli niste predstavljali.

Zastarele odgovore je najceneje izključiti in se najpogosteje spregledajo:

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

Če se izpis po čiščenju spremeni, je bilo stanje v predpomnilniku in prejšnji izpis je opisoval tunel, ki ga ni bilo več. Če se ne spremeni, je konfiguracija taka, kakršna je, in vprašanje se premakne na poti in na politiko aplikacij.

Kratek priročnik za pred in po

Zajemite izhodišče le tam, kjer politika dovoljuje, in datoteke hranite zunaj vsake usklajene mape. Spodnje zaporedje je tisto, ki ga izvajam na odjemalskih strojih: zajemite izhodišče, povežite se, zajemite znova, nato primerjajte in poiščite.

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

Razliko berite po blokih, ne po vrsticah. Nov resolver z obsegom, ki nosi kazalo vmesnika tunela in vnos domain za zasebno pripono, je pričakovana oblika. Nov privzeti resolver, ki kaže na javni naslov, je ugotovitev, ki jo je vredno izpostaviti tistemu, ki ima v lasti profil odjemalca. Nato ponovite iskanje znotraj aplikacije, ki je res odpovedala, ne le v lupini, in zabeležite vmesnik iz route -n get ob rezultatu.

Če želite spremembo razveljaviti, prekinite povezavo in ponovite zajem izhodišča. Če je blok z obsegom izginil, je odjemalec počistil za seboj. Če je blok še vedno naveden proti vmesniku, ki ne obstaja več, je stanje zastarelo, in čiščenje skupaj s ponovno povezavo je najnežnejša poprava, preden se kdo dotakne profila.

Štiri preveritve v tem vrstnem redu: ali se kakšen blok resolverja ujema z najdaljšo pripono imena; ali je ta blok vezan na vmesnik, ki ga je namestil tunel; ali pot do njegovega imenskega strežnika uporablja tunel; in ali odgovor vrne sistemski resolver, ne dig. Prva preveritev, ki spodleti, vam pove, ali spremeniti politiko DNS, poti tunela ali aplikacijo. Če vse štiri uspejo in ime še vedno spodleti, je težava nad DNS, naslednja stvar za pregled pa je vse, kar pred njim odgovarja na vrata 53.