Як праверыць 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 перад ім.