Како да ги проверите 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.