VPN падключаны, але імёны не развязваюцца: дзе DNS сапраўды ламаецца

Тунэль падняты, значок зялёны, і кожная ўкладка браўзера паведамляе пра збой развязання імёнаў. Гэтую карціну ствараюць тры розныя механізмы: рэзалвер можа быць недасягальным, кліент можа пытацца ў рэзалвера, якога вы не чакалі, або могуць збаўляць толькі прыватныя імёны. Раздзяліце іх, перш чым што-небудзь змяняць у пратаколе тунэля, бо кожны рамонтуецца ў іншым месцы. Парадак ніжэй пачынаецца з назіранняў, якія аддзяляюць трох адзін ад аднаго.

Што насамрэч патрэбна запыту

Запыту патрэбны тры рэчы: адрас рэзалвера, маршрут да гэтага адраса і адказ, які адпавядае пытанню. Кожнае можа збавіць само па сабе, а бачны сімптом — тая ж старонка, якая не загружаецца. Таму старонка памылкі амаль нічога вам не кажа, пакуль вы не ведаеце, якое з трох зламалася.

Кліент даведваецца пра свой рэзалвер з профілю VPN, з DHCP на тунэлі або са сваёй канфігурацыі, і тое, якая крыніца пераможа, залежыць ад платформы. У Windows ipconfig /all паказвае DNS-серверы па кожным адаптары, так што вы бачыце, ці сапраўды прыбыло перададзенае значэнне. Перададзенае значэнне, якое так і не дайшло да аперацыйнай сістэмы, — ціхі і часты збой. Прачытайце наладжанае значэнне, перш чым кранаць профіль.

Linux і macOS адказваюць на тое ж пытанне іншымі камандамі, і адказ варты таго ж чытання: resolvectl status і scutil --dns абодва пералічваюць серверы па інтэрфейсах. Параўнайце гэты спіс з адрасам, які профіль нібыта перадае. Разыходжанне тут тлумачыць усё далейшае, таму высветліце яго, перш чым правяраць імёны.

Праверце адно публічнае і адно прыватнае імя

Запытайце звычайнае публічнае імя хоста і дакументаванае прыватнае імя хоста з той жа машыны і запішыце, які сервер адказаў на кожнае. Калі збаўляюць абодва, зламаны рэзалвер або яго маршрут. Калі збаўляе толькі прыватнае імя, рэзалвер адказаў, і пытанне пераходзіць да зоны або маршрутызацыі. Выканайце абодва запыты на працягу хвіліны адзін ад аднаго, каб змена маршруту не магла патлумачыць розніцу.

Трымайце ўнутраныя імёны па-за публічнымі здымкамі экрана і па-за публічнымі рэзалверамі. Тайм-аўт і адказ пра неіснуючы дамен — розныя назіранні: першае кажа, што нічога не вярнулася, другое — што ўлада адказала, што імя не існуе. Калі лічыць іх адной памылкай, вы трапляеце не на той узровень, а папярэджанне пра сертыфікат — зноў трэцяе, а не збой DNS.

nslookup друкуе і сервер, у якога запытвалі, і атрыманы адказ, а гэта менавіта тая пара, якая вам патрэбна. Выканайце яго двойчы ў адной абалонцы і запішыце адрас, які адказаў, побач з кожным адказам.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Пераканайцеся, што кліент сапраўды дасягае гэтага сервера

Прыватны рэзалвер, перададзены профілем, карысны толькі тады, калі кліент можа дасягнуць яго пры паднятым тунэлі. Адрас, які выглядае правільна, без маршруту дае тайм-аўт, і стан падключэння тунэля нічога не кажа пра гэты маршрут. Праверка — гэта пошук маршруту менавіта да рэзалвера, а не да канчатковай кропкі VPN.

Кожная платформа адказвае на гэта адным радком, і інтэрфейс, названы ў вывадзе, — гэта ўвесь адказ. Калі ён паказвае на фізічны адаптар, пакуль рэзалвер знаходзіцца за тунэлем, профіль не перадае прэфікс, які яго пакрывае.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

У профілі раздзеленага тунэля рэзалвер можа знаходзіцца па-за перададзенымі маршрутамі, і гэта праблема профілю, а не сервера. Параўнайце адрас рэзалвера з перададзенымі прэфіксамі і пераканайцеся, што адзін з іх яго пакрывае. Тое ж разыходжанне тлумачыць, чаму DNS працуе ў адной сетцы і збаўляе ў іншай з ідэнтычным профілем.

Памятайце, што браўзеры могуць абыходзіць сістэмны рэзалвер

Браўзер з уключаным бяспечным DNS можа адпраўляць запыты праз HTTPS да пастаўшчыка на свой выбар і цалкам ігнараваць рэзалвер аперацыйнай сістэмы. Тады сістэма выглядае правільна, пакуль браўзер збаўляе, або наадварот. Гэта пытанне палітыкі для браўзера, а не для тунэля.

Праверце наладу бяспечнага DNS у браўзеры і любую кіраваную палітыку, якая ёй кіруе, затым паспрабуйце другую праграму або браўзер пры нязменным тунэлі. Калі збаўляе толькі адна праграма, выпраўленне належыць гэтай праграме. Прыватнае акно — не чыстае параўнанне, бо яно можа па змаўчанні адключаць пашырэнні ў адным браўзеры і не адключаць у іншым, і яно ніколі не абыходзіць кіраваную палітыку. Замест гэтага выкарыстайце другі профіль браўзера або іншую праграму.

Ачысціце кэш і паўторна праверце рэальную задачу

Пасля выпраўлення налады ачысціце лакальны кэш рэзалвера, каб стары адказ не перажыў выпраўленне. Кароткае аднаўленне з наступным збоем азначае, што прычына ўсё яшчэ ёсць, а не што ачыстка не ўдалася. Выберыце радок, які адпавядае вашай машыне, бо тры кэшы асобныя.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Затым паўтарыце першапачатковую задачу, а не сінтэтычны запыт, бо менавіта задача важная карыстальніку. Перападключыцеся адзін раз, каб паўторная праверка ахоплівала стан, у якім карыстальнік сапраўды будзе. Даведнік nslookup ад Microsoft — гэта старонка, якую варта трымаць для аргументаў запыту.

Калі імёны збаўляюць толькі пасля адключэння, кліент не аднавіў папярэднюю канфігурацыю, і гэта памылка жыццёвага цыклу, пра якую трэба паведаміць, а не DNS-сервер, які трэба замяніць. Працоўны запыт таксама не з'яўляецца тэстам уцечкі, бо краіна выхаду нічога не кажа пра тое, які рэзалвер адказаў.