Како проверити DNS резолвере које ваш Mac користи на VPN-у

scutil --dns штампа конфигурацију резолвера коју macOS заиста користи, а не онај једини DNS сервер који сте унели у панел поставки. Излаз је дужи него што већина очекује, јер систем држи одвојене блокове резолвера за подразумевану путању, за интерфејсе с опсегом и за прослеђивање специфично за домен. Блок на врху излаза није нужно онај који одговара на упит. Ако се приватно име реши у канцеларији и не успе у тренутку када се VPN подигне, неслагање је у правилима подударања и у рутама, не у адреси сервера. Прво прочитајте редослед, затим докажите одговор стварном претрагом.

Прочитајте редослед блокова пре адреса

Сваки запис почиње са resolver #N и наводи nameserver[0], понекад if_index, ред flags, reach и, када блок није обичан подразумевани, domain и листу search domain. Резолвер број 1 без домена је подразумевани који обрађује јавна имена. Све што у заставицама носи Scoped везано је за интерфејс који именује if_index, а све означено са Supplemental важи само за домене наведене испод њега.

Избор је подударање суфикса. За име као intranet.corp.example, macOS претпочита резолвер чији је запис domain најдужи одговарајући суфикс, па блок са domain : corp.example побеђује подразумевани чак и када стоји дубоко у излазу. order решава изједначења између домена исте дужине. Први поглед ретко тражи више: цео излаз када желите да прочитате један блок од почетка до краја, почетне редове да научите редослед блокова и филтрирани пролаз који штампа заглавља блокова поред редова поља. Блокови с опсегом појављују се под сопственим заглављем и читају се као наставак листе изнад њих, зато држите заглавље у видокругу када год цитирате излаз.

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'

Повежите if_index са интерфејсом тунела

Индекс је користан само ако можете да именујете интерфејс иза њега. scutil --nwi наводи мрежне информације које систем држи, укључујући примарни интерфејс и достижност, док ifconfig -l даје имена, где су utun0 до utun9 кандидати за тунел које клијент обично ствара. Apple користи scutil --dns као сопствени пример провере у водичу за распоређивање, и документује како Network Extension може да усмерава изабране домене ка изабраним резолверима, што је механизам који откривају ти блокови с опсегом.

Провера која решава питање јесте да ли резолвер стоји на путањи коју је тунел инсталирао:

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

Ако route -n get врати пролаз и интерфејс који се не поклапају са записом резолвера, адреса може бити потпуно тачна и ипак недоступна. Подељени тунел који носи само корпоративне подмреже одбацује упите усмерене ка DNS серверу изван њих, а квар се показује као истек времена, зато излаз конфигурације и даље изгледа чисто.

Питајте системски резолвер, затим сервер

Три алата одговарају на три различита питања, а њихово мешање ствара већину погрешних закључака у овој области. dscacheutil -q host -a name пролази кроз исти системски резолвер који користе уобичајене апликације, па важе блокови с опсегом и допунски блокови. dig без аргумента сервера чита /etc/resolv.conf, што није извор истине за решавање с опсегом на macOS, и потпуно прескаче правила по домену. dig @address достиже тачно један сервер и не говори ништа о избору.

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

Када прва наредба одговори, а друга врати NXDOMAIN, пронашли сте поделу коју сте тражили и ништа није покварено. Када прва истекне у времену док dig @10.20.0.53 одговара, резолвер ради али није доступан на путањи коју је тунел изабрао, зато је следећи корак route -n get, а не измена DNS подешавања. Држите приватна имена изван свега што лепите у тикет или заједничку белешку.

Шта излаз не може да вам покаже

Неколико слојева седи изнад листе резолвера или поред ње, и сваки може да пошаље упит негде што излаз никада не помиње. Прегледач са укљученим безбедним DNS-ом може да решава преко сопственог шифрованог канала, па страница која се учитава док dscacheutil истиче није противречност. DNS прокси који инсталира безбедносни софтвер ради као добављач Network Extension-а и сам прослеђује упите, а scutil --dns показује шта је конфигурисано, а не адресу изнад коју је прокси на крају користио. Домени претраге додају трећи набор: на неквалификовано име додаје се сваки наведени суфикс по реду, па блок који је одговорио може бити онај који никада нисте ни слутили.

Застарели одговори се најјефтиније искључују и најчешће прескачу:

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

Ако се излаз промени после чишћења, стање је било у кешу и ранији излаз је описивао тунел који више није постојао. Ако се не промени, конфигурација је таква каква је, и питање се сели на руте и на политику апликација.

Кратак приручник за пре и после

Снимите основну линију само тамо где политика дозвољава и држите датотеке изван сваке синхронизоване фасцикле. Следећи редослед је оно што извршавам на клијентским машинама: снимите основну линију, повежите се, снимите поново, затим упоредите и потражите.

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

Читајте разлику по блоковима, а не по редовима. Нови резолвер с опсегом који носи индекс интерфејса тунела и запис domain за приватни суфикс је очекивани облик. Нови подразумевани резолвер који показује на јавну адресу је налаз који вреди изнети ономе ко поседује профил клијента. Затим поновите упит унутар апликације која је заиста заказала, не само у љусци, и запишите интерфејс из route -n get поред резултата.

Да поништите промену, прекините везу и поновите снимање основне линије. Ако је блок с опсегом нестао, клијент је почистио за собом. Ако је блок још увек наведен према интерфејсу који више не постоји, стање је застарело, а чишћење уз поновно повезивање је најнежнија поправка пре него што било ко дотакне профил.

Четири провере овим редом: да ли се неки блок резолвера поклапа са најдужим суфиксом имена; да ли је тај блок везан за интерфејс који је тунел инсталирао; да ли рута ка његовом серверу имена користи тунел; и да ли одговор враћа системски резолвер, а не dig. Прва провера која не успе каже вам да ли да промените DNS политику, руте тунела или апликацију. Ако све четири прођу а име и даље не успева, проблем је изнад DNS-а, и следеће што треба прегледати је све што пред њим одговара на порту 53.