Cum să inspectezi resolverii DNS pe care Mac-ul tău îi folosește într-un VPN

scutil --dns tipărește configurația resolverului pe care macOS o consultă cu adevărat, nu acel singur server DNS pe care l-ai tastat într-un panou de setări. Rezultatul este mai lung decât se așteaptă majoritatea, pentru că sistemul ține blocuri de resolver separate pentru calea implicită, pentru interfețele cu scop și pentru redirecționarea specifică unui domeniu. Blocul din capul rezultatului nu este neapărat cel care răspunde interogării. Dacă un nume privat se rezolvă la birou și eșuează în momentul în care VPN-ul urcă, nepotrivirea este în regulile de potrivire și în rute, nu în adresa serverului. Citește mai întâi ordinea, apoi demonstrează răspunsul cu o căutare reală.

Citește ordinea blocurilor înaintea adreselor

Fiecare intrare începe cu resolver #N și enumeră nameserver[0], uneori if_index, o linie flags, reach și, când blocul nu este o valoare implicită simplă, un domain și o listă search domain. Resolverul numărul 1 fără domeniu este implicitul care tratează numele publice. Orice poartă Scoped în marcajele sale este legat de interfața numită de if_index, iar orice marcat cu Supplemental se aplică doar domeniilor listate sub el.

Selecția este potrivire de sufix. Pentru un nume ca intranet.corp.example, macOS preferă resolverul a cărui intrare domain este cel mai lung sufix potrivit, deci un bloc cu domain : corp.example învinge implicitul chiar când se află foarte jos în rezultat. order decide egalitățile între domenii de aceeași lungime. O primă privire are rar nevoie de mai mult: întregul rezultat când vrei să citești un bloc de la început la sfârșit, primele linii pentru a învăța ordinea blocurilor și o trecere filtrată care tipărește antetele blocurilor lângă liniile câmpurilor. Blocurile cu scop apar sub propriul antet și se citesc ca o continuare a listei de deasupra, deci ține un antet în câmpul vizual când citează rezultatul.

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'

Asociază if_index cu interfața tunelului

Un index este util doar dacă poți numi interfața din spatele lui. scutil --nwi enumeră informațiile de rețea pe care le ține sistemul, inclusiv interfața primară și accesibilitatea, în timp ce ifconfig -l îți dă numele, unde utun0 până la utun9 sunt candidații de tunel pe care un client le creează de obicei. Apple folosește scutil --dns ca propriul exemplu de inspecție în ghidul de implementare, și documentează cum Network Extension poate direcționa domenii alese către resolvere alese, ceea ce este mecanismul pe care acele blocuri cu scop îl expun.

Verificarea care lămurește întrebarea este dacă resolverul se află pe calea pe care a instalat-o tunelul:

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

Dacă route -n get returnează un gateway și o interfață care nu corespund intrării resolverului, adresa poate fi perfect corectă și totuși inaccesibilă. Un tunel divizat care duce doar subrețelele corporative aruncă interogările adresate unui server DNS din afara lor, iar eșecul se arată ca un depășire de timp, de aceea rezultatul configurației continuă să pară curat.

Întreabă resolverul de sistem, apoi serverul

Trei instrumente răspund la trei întrebări diferite, iar confundarea lor produce majoritatea concluziilor greșite din acest domeniu. dscacheutil -q host -a name trece prin același resolver de sistem pe care îl folosesc aplicațiile obișnuite, deci blocurile cu scop și cele suplimentare se aplică. dig fără argument de server citește /etc/resolv.conf, care nu este sursa de adevăr pentru rezolvarea cu scop pe macOS, și sare complet peste regulile pe domeniu. dig @address ajunge la exact un server și nu spune nimic despre selecție.

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

Când prima comandă răspunde și a doua returnează NXDOMAIN, ai găsit separarea pe care o căutai și nimic nu este stricat. Când prima expiră în timp ce dig @10.20.0.53 răspunde, resolverul funcționează dar nu este accesibil pe calea aleasă de tunel, deci pasul următor este route -n get și nu o modificare a setărilor DNS. Ține numele private departe de tot ce lipești într-un tichet sau într-o notă partajată.

Ce nu îți poate arăta rezultatul

Mai multe straturi stau deasupra listei de resolvere sau lângă ea, și fiecare poate trimite o interogare undeva unde rezultatul nu menționează niciodată. Un browser cu DNS sigur activat poate rezolva prin propriul canal criptat, deci o pagină care se încarcă în timp ce dscacheutil expiră nu este o contradicție. Un proxy DNS instalat de software de securitate rulează ca furnizor Network Extension și redirecționează el însuși interogările, iar scutil --dns arată ce a fost configurat, nu adresa din amonte pe care proxy-ul a folosit-o în final. Domeniile de căutare adaugă o a treia cută: unui nume necualificat i se adaugă pe rând fiecare sufix listat, deci blocul care a răspuns poate fi unul de care nu ai suspectat niciodată.

Răspunsurile învechite sunt cel mai ieftin de exclus și cel mai des omis:

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

Dacă rezultatul se schimbă după golire, starea era în cache și rezultatul anterior descria un tunel care nu mai exista. Dacă nu se schimbă, configurația este ce este, iar întrebarea se mută către rute și către politica aplicațiilor.

Un runbook scurt pentru înainte și după

Capturează o linie de bază doar unde politica permite, și ține fișierele în afara oricărui folder sincronizat. Secvența de mai jos este cea pe care o rulez pe mașinile clienților: capturează linia de bază, conectează, capturează din nou, apoi compară și caută.

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

Citește diferența pe blocuri, nu pe linii. Un resolver nou cu scop care duce indexul interfeței tunelului și o intrare domain pentru sufixul privat este forma așteptată. Un resolver implicit nou care indică o adresă publică este o constatare care merită ridicată în fața celui care deține profilul clientului. Apoi repetă căutarea în aplicația care a eșuat cu adevărat, nu doar în shell, și notează interfața din route -n get lângă rezultat.

Pentru a anula o modificare, deconectează-te și repetă capturarea liniei de bază. Dacă blocul cu scop a dispărut, clientul a curățat după el. Dacă blocul este încă listat împotriva unei interfețe care nu mai există, starea este învechită, și o golire plus o reconectare este cea mai blândă reparație înainte ca cineva să atingă profilul.

Patru verificări, în această ordine: un bloc de resolver se potrivește cu cel mai lung sufix al numelui; acel bloc este legat de interfața pe care a instalat-o tunelul; ruta către serverul său de nume folosește tunelul; și resolverul de sistem, nu dig, returnează răspunsul. Prima verificare care eșuează îți spune dacă să schimbi politica DNS, rutele tunelului sau aplicația. Dacă toate patru trec și numele tot eșuează, problema se află deasupra DNS-ului, iar următorul lucru de inspectat este orice răspunde la portul 53 în fața lui.