Чаму nslookup вырашае праз VPN, а браўзер не можа

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

Праверкі ніжэй ідуць па гэтых шляхах ад сістэмы вонкі. Не правіце профіль VPN, пакуль не даведаецеся, які шлях адказаў і які зламаўся.

Тры палітыкі вызначаюць адказ

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

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

Чаму браўзер задае іншае пытанне

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

Перавага сямейства адрасоў тлумачыць затрымку, а не памылку. Браўзер, які спачатку запытвае запісы IPv6 у тунелі, што нясе толькі IPv4, чакае сканчэння тайм-аўту, перш чым адступіць. Firefox меў такую перавагу менавіта для гэтага, і яе адключэнне — дыягнастычны крок, а не рамонт.

Чытайце спіс рэзалвераў і правілы

У Windows выведзіце тое, што трымае сістэма, перш чым тэарэтызаваць. Get-DnsClientServerAddress паказвае серверы па кожным інтэрфейсе, Get-DnsClientNrptRule пералічвае правілы прасторы імёнаў, а Resolve-DnsName адказвае на дакладнае імя праз сістэмны шлях. Параўнайце гэты адказ з прамым запытам да сервера VPN па адрасе. Калі Resolve-DnsName падае, а прамы запыт паспяховы, падазроным з'яўляецца спіс рэзалвераў або правіла прасторы імёнаў.

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

Недасягальны прасунуты рэзалвер

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

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

Шыфраваны DNS абыходзіць увесь шлях

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

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

Рамоны, што адпавядаюць збою

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

Затым аддзяліце пошук ад злучэння. Імя, якое вырашаецца ў правільны адрас, але адмаўляе злучэнне, — гэта праблема сэрвісу, фар'явола або сертыфіката, і змены DNS яе не выправяць.

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