Slik undersøker du DNS-resolverne Macen din bruker på en VPN

scutil --dns skriver ut resolverkonfigurasjonen macOS faktisk bruker, ikke den ene DNS-serveren du skrev inn i et innstillingspanel. Utdataene er lengre enn de fleste forventer, fordi systemet holder separate resolverblokker for standardstien, for avgrensede grensesnitt og for domene-spesifikk videresending. Blokken øverst i utdataene er ikke nødvendigvis den som svarer på spørringen. Hvis et privat navn slår opp på kontoret og feiler i det øyeblikket VPN-et kommer opp, ligger avviket i matchingsreglene og rutene, ikke i serveradressen. Les rekkefølgen først, og bevis deretter svaret med et ekte oppslag.

Les blokkerekkefølgen før adressene

Hver oppføring åpner med resolver #N og lister nameserver[0], av og til if_index, en flags-linje, reach og, når blokken ikke er en vanlig standard, en domain og en search domain-liste. Resolver nummer 1 uten domene er standarden som håndterer offentlige navn. Alt som bærer Scoped i flaggene sine, er bundet til grensesnittet som if_index navngir, og alt merket Supplemental gjelder bare for domenene som er listet under det.

Valget er suffiksmatching. For et navn som intranet.corp.example foretrekker macOS resolveren der domain-oppføringen er det lengste matchende suffikset, så en blokk med domain : corp.example slår standarden selv når den står langt nede i utdataene. order bryter uavgjort mellom domener av samme lengde. Et første blikk trenger sjelden mer: hele utdataene når du vil lese én blokk fra ende til annen, de første linjene for å lære blokkerekkefølgen, og en filtrert gjennomgang som skriver ut blokkoverskriftene ved siden av feltlinjene. Avgrensede blokker vises under sin egen overskrift og leses som en fortsettelse av listen over dem, så hold en overskrift i syne når du siterer utdataene.

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

En indeks er bare nyttig hvis du kan navngi grensesnittet bak den. scutil --nwi lister nettverksinformasjonen systemet holder, inkludert det primære grensesnittet og tilgjengelighet, mens ifconfig -l gir deg navnene, der utun0 til utun9 er tunnelkandidatene en klient vanligvis oppretter. Apple bruker scutil --dns som sitt eget inspeksjonseksempel i utrullingsveiledningen, og dokumenterer hvordan Network Extension kan rute utvalgte domener til utvalgte resolvere, som er mekanismen de avgrensede blokkene avslører.

Kontrollen som avgjør spørsmålet, er om resolveren sitter på stien tunnelen installerte:

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

Hvis route -n get returnerer en gateway og et grensesnitt som ikke samsvarer med resolveroppføringen, kan adressen være helt riktig og likevel utilgjengelig. En delt tunnel som bare bærer de bedriftsinterne subnettene, slipper spørringer rettet mot en DNS-server utenfor dem, og feilen viser seg som en tidsavbrudd, og derfor ser konfigurasjonsutdataene fortsatt rene ut.

Spør systemresolveren, deretter serveren

Tre verktøy svarer på tre forskjellige spørsmål, og å blande dem gir de fleste feilkonklusjonene på dette området. dscacheutil -q host -a name går gjennom den samme systemresolveren som vanlige programmer bruker, så avgrensede og supplerende blokker gjelder. dig uten serverargument leser /etc/resolv.conf, som ikke er sannhetskilden for avgrenset oppslag på macOS, og det hopper helt over reglene per domene. dig @address når nøyaktig én server og sier ingenting om valget.

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 første kommandoen svarer og den andre returnerer NXDOMAIN, har du funnet delingen du lette etter, og ingenting er ødelagt. Når den første timer ut mens dig @10.20.0.53 svarer, virker resolveren, men den er ikke tilgjengelig på stien tunnelen valgte, så neste steg er route -n get i stedet for en endring av DNS-innstillingene. Hold private navn unna alt du limer inn i en sak eller et delt notat.

Hva utdataene ikke kan vise deg

Flere lag ligger over eller ved siden av resolverlisten, og hvert av dem kan sende en spørring et sted utdataene aldri nevner. En nettleser med sikker DNS aktivert kan slå opp over sin egen krypterte kanal, så en side som lastes mens dscacheutil timer ut, er ikke en motsetning. En DNS-proxy installert av sikkerhetsprogramvare kjører som en Network Extension-leverandør og videresender spørringene selv, og scutil --dns viser hva som ble konfigurert, ikke oppstrømsadressen proxyen til slutt brukte. Søkedomener legger til en tredje vri: et ukvalifisert navn får hvert oppførte suffiks lagt til i rekkefølge, så blokken som svarte kan være en du aldri mistenkte.

Utdaterte svar er det billigste å utelukke og det oftest oversette:

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

Hvis utdataene endrer seg etter tømmingen, var tilstanden bufret og de tidligere utdataene beskrev en tunnel som ikke lenger fantes. Hvis de ikke endrer seg, er konfigurasjonen som den er, og spørsmålet flytter seg til ruter og til applikasjonspolicy.

En kort kjørebok for før og etter

Ta en basislinje bare der policyen tillater det, og hold filene utenfor enhver synkronisert mappe. Rekkefølgen nedenfor er den jeg kjører på klientmaskiner: ta basislinjen, koble til, ta på nytt, og sammenlign 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 forskjellen per blokk i stedet for per linje. En ny avgrenset resolver som bærer tunnelgrensesnittets indeks og en domain-oppføring for det private suffikset, er den forventede formen. En ny standardresolver som peker på en offentlig adresse, er et funn det er verdt å ta opp med den som eier klientprofilen. Gjenta deretter oppslaget inne i programmet som faktisk feilet, ikke bare i skallet, og noter grensesnittet fra route -n get ved siden av resultatet.

For å angre en endring, koble fra og gjenta basislinjeopptaket. Hvis den avgrensede blokken er borte, har klienten ryddet etter seg. Hvis blokken fortsatt er listet mot et grensesnitt som ikke lenger finnes, er tilstanden utdatert, og en tømming pluss en gjenoppkobling er den mildeste rettelsen før noen rører profilen.

Fire kontroller i denne rekkefølgen: passer en resolverblokk til det lengste suffikset i navnet; er den blokken bundet til grensesnittet tunnelen installerte; bruker ruten til navneserveren dens tunnelen; og returnerer systemresolveren, ikke dig, svaret. Den første kontrollen som feiler, forteller deg om du skal endre DNS-policyen, tunnelrutene eller programmet. Hvis alle fire passerer og navnet fortsatt feiler, sitter problemet over DNS, og det neste som må undersøkes, er hva som helst som svarer på port 53 foran det.