Slik granskar du DNS-resolvarane Macen din brukar på ein VPN

scutil --dns skriv ut resolverkonfigurasjonen macOS faktisk brukar, ikkje den eine DNS-tenaren du skreiv inn i eit innstillingspanel. Utdataa er lengre enn dei fleste ventar, fordi systemet held separate resolverblokker for standardstien, for avgrensa grensesnitt og for domenespesifikk vidaresending. Blokka øvst i utdataa er ikkje nødvendigvis den som svarar på spørjinga. Viss eit privat namn slår opp på kontoret og feilar i det augeblikket VPN-et kjem opp, ligg avviket i matchereglane og rutene, ikkje i tenaradressa. Les rekkjefølgja fyrst, og prov deretter svaret med eit ekte oppslag.

Les blokkerekkjefølgja før adressene

Kvar oppføring opnar med resolver #N og listar nameserver[0], av og til if_index, ei flags-linje, reach og, når blokka ikkje er ein vanleg standard, ei domain og ei search domain-liste. Resolver nummer 1 utan domene er standarden som handterer offentlege namn. Alt som ber Scoped i flagga sine, er bunde til grensesnittet som if_index namngir, og alt merkt Supplemental gjeld berre for domena som er lista under det.

Valet er suffiksmatching. For eit namn som intranet.corp.example føretrekk macOS resolveren der domain-oppføringa er det lengste matchande suffikset, så ei blokk med domain : corp.example slår standarden sjølv når ho står langt nede i utdataa. order bryt uavgjort mellom domene av same lengd. Eit fyrste blikk treng sjeldan meir: alle utdataa når du vil lese éi blokk frå ende til annan, dei fyrste linjene for å lære blokkerekkjefølgja, og ein filtrert gjennomgang som skriv ut blokkoverskriftene ved sida av feltlinjene. Avgrensa blokker viser seg under si eiga overskrift og blir lesne som ei framhalding av lista over dei, så hald ei overskrift i synet når du siterer utdataa.

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'

Knytt if_index til tunnelgrensesnittet

Ein indeks er berre nyttig viss du kan namngi grensesnittet bak han. scutil --nwi listar nettverksinformasjonen systemet held, inkludert det primære grensesnittet og tilgjenge, medan ifconfig -l gjev deg namna, der utun0 til utun9 er tunnelkandidatane ein klient vanlegvis lagar. Apple brukar scutil --dns som sitt eige granskingsdøme i utrullingsrettleiinga, og dokumenterer korleis Network Extension kan rute utvalde domene til utvalde resolvarar, som er mekanismen dei avgrensa blokkene avdekkjer.

Kontrollen som avgjer spørsmålet, er om resolveren sit på stien tunnelen installerte:

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

Viss route -n get returnerer ein gateway og eit grensesnitt som ikkje samsvarar med resolveroppføringa, kan adressa vere heilt riktig og likevel utilgjengeleg. Ein delt tunnel som berre ber dei bedriftsinterne subneta, slepp spørjingar retta mot ein DNS-tenar utanfor dei, og feilen viser seg som eit tidsavbrot, og difor ser konfigurasjonsutdataa framleis reine ut.

Spør systemresolveren, deretter tenaren

Tre verkty svarar på tre ulike spørsmål, og å blande dei gjev dei fleste feilkonklusjonane på dette området. dscacheutil -q host -a name går gjennom den same systemresolveren som vanlege program brukar, så avgrensa og supplerande blokker gjeld. dig utan tenarargument les /etc/resolv.conf, som ikkje er sanninga si kjelde for avgrensa oppslag på macOS, og det hoppar heilt over reglane per domene. dig @address når nøyaktig éin tenar og seier ingenting om valet.

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

Når den fyrste kommandoen svarar og den andre returnerer NXDOMAIN, har du funne delinga du leita etter, og ingenting er øydelagt. Når den fyrste går ut på tid medan dig @10.20.0.53 svarar, verkar resolveren, men han er ikkje tilgjengeleg på stien tunnelen valde, så neste steg er route -n get i staden for ei endring av DNS-innstillingane. Hald private namn unna alt du limer inn i ein sak eller eit delt notat.

Kva utdataa ikkje kan vise deg

Fleire lag ligg over eller ved sida av resolverselskapet, og kvart av dei kan sende ei spørjing ein stad utdataa aldri nemner. Ein nettlesar med sikker DNS slått på kan slå opp over sin eigen krypterte kanal, så ei side som lastar medan dscacheutil går ut på tid, er ikkje ei motsetning. Ein DNS-proxy installert av tryggleiksprogramvare køyrer som ein Network Extension-leverandør og videresender spørjingane sjølv, og scutil --dns viser kva som vart konfigurert, ikkje oppstraumsadressa proxyen til slutt brukte. Søkjedomene legg til ei tredje vriding: eit ukvalifisert namn får kvart oppførte suffiks lagt til i rekkjefølgje, så blokka som svara kan vere ei du aldri mistenkte.

Utdaterte svar er det billegaste å utelukke og det som oftast blir oversett:

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

Viss utdataa endrar seg etter tømminga, var tilstanden buftra og dei tidlegare utdataa skildra ein tunnel som ikkje fanst lenger. Viss dei ikkje endrar seg, er konfigurasjonen som han er, og spørsmålet flyttar seg til ruter og til programpolitikk.

Ei kort køyrebok for før og etter

Ta ei basislinje berre der politikken tillèt det, og hald filene utanfor kvar ein synkronisert mappe. Rekkjefølgja nedanfor er den eg køyrer på klientmaskinar: ta basislinja, kople til, ta på nytt, og samanlikn deretter og slå opp.

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

Les skilnaden per blokk i staden for per linje. Ein ny avgrensa resolver som ber tunnelgrensesnittet sin indeks og ei domain-oppføring for det private suffikset, er den venta forma. Ein ny standardresolver som peikar på ei offentleg adresse, er eit funn det er verdt å ta opp med den som eig klientprofilen. Gjenta deretter oppslaget inne i programmet som faktisk feila, ikkje berre i skalet, og noter grensesnittet frå route -n get ved sida av resultatet.

For å angre ei endring, kople frå og gjenta basislinjeopptaket. Viss den avgrensa blokka er borte, har klienten rydda etter seg. Viss blokka framleis er lista mot eit grensesnitt som ikkje finst lenger, er tilstanden utdatert, og ei tømming pluss ei ny tilkopling er den mildaste rettinga før nokon rører profilen.

Fire kontrollar i denne rekkjefølgja: passar ei resolverblokk til det lengste suffikset i namnet; er den blokka bunde til grensesnittet tunnelen installerte; brukar ruta til namnetenaren hans tunnelen; og returnerer systemresolveren, ikkje dig, svaret. Den fyrste kontrollen som feilar, fortel deg om du skal endre DNS-politikken, tunnelrutene eller programmet. Viss alle fire passerer og namnet framleis feilar, sit problemet over DNS, og det neste som må granskast, er kva som helst som svarar på port 53 framfor det.