Ako skontrolovať DNS resolvery, ktoré váš Mac používa vo VPN

scutil --dns vypisuje konfiguráciu resolvera, ktorú macOS skutočne využíva, nie ten jediný DNS server, ktorý ste zadali do panela nastavení. Výstup je dlhší, než väčšina ľudí čaká, pretože systém drží oddelené bloky resolvera pre predvolenú cestu, pre rozsahové rozhrania a pre smerovanie špecifické pre doménu. Blok na začiatku výstupu nemusí byť ten, ktorý odpovedá na dopyt. Ak sa súkromné meno v kancelárii preloží a prestane fungovať v okamihu, keď sa VPN zdvihne, nesúlad je v pravidlách párovania a v trasách, nie v adrese servera. Prečítajte najprv poradie a potom dokážte odpoveď skutočným dopytom.

Prečítajte poradie blokov skôr než adresy

Každý záznam sa začína resolver #N a vypisuje nameserver[0], niekedy if_index, riadok flags, reach a keď blok nie je obyčajná predvolená hodnota, aj domain a zoznam search domain. Resolver číslo 1 bez domény je predvolený, ktorý obsluhuje verejné mená. Čokoľvek, čo vo svojich príznakoch nesie Scoped, je viazané na rozhranie, ktoré pomenúva if_index, a čokoľvek označené Supplemental platí len pre domény uvedené pod ním.

Výber je párovanie prípony. Pre meno ako intranet.corp.example dáva macOS prednosť resolveru, ktorého záznam domain je najdlhšia zodpovedajúca prípona, takže blok s domain : corp.example porazí predvolený, aj keď stojí hlboko vo výstupe. order rozhoduje zhodnosti medzi doménami rovnakej dĺžky. Prvý pohľad málokedy potrebuje viac: celý výstup, keď chcete prečítať jeden blok od začiatku do konca, úvodné riadky na spoznanie poradia blokov a filtrovaný prechod, ktorý vypisuje hlavičky blokov vedľa riadkov polí. Rozsahové bloky sa objavujú pod vlastnou hlavičkou a čítajú sa ako pokračovanie zoznamu nad nimi, preto majte hlavičku na očiach, kedykoľvek výstup citujete.

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'

Priraďte if_index k rozhraniu tunela

Index je užitočný len vtedy, keď dokážete pomenovať rozhranie za ním. scutil --nwi vypisuje sieťové informácie, ktoré systém drží, vrátane primárneho rozhrania a dostupnosti, kým ifconfig -l vám dáva mená, kde utun0 až utun9 sú kandidáti na tunel, ktoré klient zvyčajne vytvára. Apple používa scutil --dns ako svoj vlastný príklad kontroly v sprievodcovi nasadením, a dokumentuje, ako Network Extension môže smerovať vybrané domény na vybrané resolvery, čo je mechanizmus, ktorý tieto rozsahové bloky odhaľujú.

Kontrola, ktorá otázku rozhodne, je, či resolver sedí na ceste, ktorú tunel nainštaloval:

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

Ak route -n get vráti bránu a rozhranie, ktoré nezodpovedajú záznamu resolvera, adresa môže byť úplne správna a napriek tomu nedostupná. Rozdelený tunel, ktorý nesie iba firemné podsiete, zahadzuje dopyty smerované na DNS server mimo nich, a zlyhanie sa prejaví ako vypršanie času, preto výstup konfigurácie stále vyzerá čisto.

Opýtajte sa systémového resolvera, potom servera

Tri nástroje odpovedajú na tri rôzne otázky a ich zámena produkuje väčšinu nesprávnych záverov v tejto oblasti. dscacheutil -q host -a name ide cez rovnaký systémový resolver, aký používajú bežné aplikácie, takže platia rozsahové aj doplnkové bloky. dig bez argumentu servera číta /etc/resolv.conf, čo nie je zdrojom pravdy pre rozsahové prekladanie na macOS, a pravidlá pre jednotlivé domény úplne preskakuje. dig @address dosiahne presne jeden server a o výbere nepovie nič.

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

Keď prvý príkaz odpovie a druhý vráti NXDOMAIN, našli ste rozdelenie, ktoré ste hľadali, a nič nie je pokazené. Keď prvý vyprší, kým dig @10.20.0.53 odpovedá, resolver funguje, ale nie je dostupný na ceste, ktorú tunel zvolil, takže ďalším krokom je route -n get, a nie úprava nastavení DNS. Držte súkromné mená mimo všetkého, čo vkladáte do tiketu alebo zdieľanej poznámky.

Čo vám výstup nemôže ukázať

Nad zoznamom resolverov alebo vedľa neho sedí niekoľko vrstiev a každá môže poslať dopyt niekam, čo výstup nikdy nezmieni. Prehliadač so zapnutým bezpečným DNS môže prekladať cez svoj vlastný šifrovaný kanál, takže stránka, ktorá sa načíta, kým dscacheutil vyprší, nie je protirečenie. DNS proxy nainštalované bezpečnostným softvérom beží ako poskytovateľ Network Extension a dopyty posiela ďalej samo, a scutil --dns ukazuje, čo bolo nakonfigurované, nie adresu proti prúdu, ktorú proxy napokon použilo. Domény vyhľadávania pridávajú tretiu vrásku: k nekvalifikovanému menu sa v poradí pripája každá uvedená prípona, takže blok, ktorý odpovedal, môže byť taký, aký ste nikdy netušili.

Zastarané odpovede sa vylučujú najlacnejšie a najčastejšie sa prehliadajú:

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

Ak sa výstup po vyčistení zmení, stav bol v cache a skorší výstup opisoval tunel, ktorý už neexistoval. Ak sa nezmení, konfigurácia je taká, aká je, a otázka sa presúva k trasám a k politike aplikácií.

Krátky runbook pre pred a po

Zachytte základnú líniu len tam, kde to politika dovoľuje, a držte súbory mimo každého synchronizovaného priečinka. Postup nižšie je ten, ktorý spúšťam na klientskych strojoch: zachyťte základnú líniu, pripojte sa, zachyťte znova, potom porovnajte a hľadajte.

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

Čítajte rozdiel po blokoch, nie po riadkoch. Nový rozsahový resolver, ktorý nesie index rozhrania tunela a záznam domain pre súkromnú príponu, je očakávaný tvar. Nový predvolený resolver ukazujúci na verejnú adresu je zistenie, ktoré stojí za to nadniesť tomu, kto vlastní profil klienta. Potom zopakujte dopyt v aplikácii, ktorá skutočne zlyhala, nielen v shell-e, a poznamenajte rozhranie z route -n get vedľa výsledku.

Ak chcete zmenu vrátiť, odpojte sa a zopakujte zachytenie základnej línie. Ak rozsahový blok zmizol, klient po sebe upratal. Ak je blok stále uvedený voči rozhraniu, ktoré už neexistuje, stav je zastaraný, a vyčistenie plus opätovné pripojenie je najšetrnejšia oprava, kým sa niekto dotkne profilu.

Štyri kontroly v tomto poradí: či nejaký blok resolvera zodpovedá najdlhšej prípone mena; či je ten blok viazaný na rozhranie, ktoré nainštaloval tunel; či trasa k jeho mennému serveru používa tunel; a či odpoveď vracia systémový resolver, a nie dig. Prvá kontrola, ktorá zlyhá, vám povie, či meniť politiku DNS, trasy tunela alebo aplikáciu. Ak všetky štyri prejdú a meno stále zlyháva, problém je nad DNS a ďalšia vec na preskúmanie je všetko, čo pred ním odpovedá na port 53.