Ці змяніў VPN мой DNS? Параўнайце да і пасля
Профіль можа наўмысна перанакіраваць вашы запыты. Параўнайце палітыку рэзалвера і фактычны адказ да і пасля падключэння VPN, трымаючы адну зменную нязменнай.
Вы падключаеце тунель, адкрываеце прыватную панэль, і імя разрозніваецца ў адрас, якога вы ніколі не бачылі. Альбо адбываецца адваротнае: браўзер працягвае працаваць, а інструмент каманднага радка раптам перастае разрозніваць што-небудзь. Абодва вынікі паходзяць ад адной і той жа змены, і людзі звычайна тлумачаць гэта адным сказам пра VPN, які «выкарыстоўвае свой DNS», што недастаткова дакладна, каб адладзіць або праверыць. У гэтым сказе схаваныя два пытанні: якія запыты павінен узяць на сябе гэты профіль і ці сапраўды ваша машына адправіла іх таму рэзалверу, які ёй выдалі? Трымаць іх асобна — гэта і ёсць увесь метад, бо тэст, які іх змешвае, дае ўпэўнены няправільны адказ у абодвух кірунках.
Чаму профіль наогул прадастаўляе рэзалвер
Унутры тунеля імёны за далёкім канцом звычайна разрозніваюцца ў адрасы, якія існуюць толькі ў гэтай сетцы. Прыватная зона, такая як corp.internal, не мае публічнага дэлегавання, таму рэзалвер, які адказвае за яе, павінен быць дасяжны знутры тунеля. Той самы механізм служыць і другой мэце: калі запыты інакш выходзілі б праз вашага інтэрнэт-правайдэра, рэзалвер на далёкім баку трымае запыт унутры шыфраванага шляху. Менавіта таму адрас DNS-сервера прыходзіць як частка палітыкі злучэння, а не як глабальная налада, якую вы аднойчы выбралі для машыны.
Адрас сам па сабе нічога не вырашае. Рэзалвер можа адказаць, толькі калі да яго ёсць маршрут, і найчасцейшая памылка — рэзалвер, дасяжны толькі пакуль тунель узняты. Калі тунель падае, а палітыка застаецца, запыты ідуць на адрас без шляху, і сімптом — тайм-аўт, а не чыстая памылка. Гэтая розніца важная, калі вы чытаеце наступны вынік тэсту, бо тайм-аўт накіроўвае людзей у налады транспарту, якія тут зусім не ўдзельнічалі.
Параўнайце два дызайны перад параўнаннем адказаў
Поўны тунель і падзелены DNS даюць супрацьлеглыя чаканні, і ні адно з іх не з'яўляецца няспраўнасцю. Пры поўным тунелі кожны запыт можа перайсці да правайдэра або да карпаратыўнага рэзалвера, таму розны адказ публічных імёнаў пасля падключэння — гэта чакана. Пры падзеленым DNS толькі пералічаныя дамены ідуць да прыватнага рэзалвера, а ўсё астатняе застаецца лакальным; на Windows спіс даменаў жыве ў табліцы палітыкі разрознівання імёнаў, на macOS — у адпаведных даменах налад DNS, а на хосце systemd-resolved — у даменах маршрутызацыі для кожнага злучэння.
Менавіта гэтае параўнанне трэба зрабіць першым, бо яно вырашае, што лічыць дэфектам. Пры падзеленым DNS публічнае імя, якое адказвае з новага рэзалвера, — гэта тое, што варта даследаваць, а ўнутранае імя, якое адказвае правільна, — гэта сістэма, якая робіць сваю працу. Пры поўным тунелі анамаліяй з'яўляецца публічнае імя, якое ўсё яшчэ адказвае з рэзалвера вашага правайдэра. Дакументацыя Microsoft пра разрозніванне імёнаў у VPN апісвае парадак гэтых правіл у Windows, у тым ліку як супадаючы запіс палітыкі разглядаецца перад уласнымі серверамі адаптара.
У пакоі ёсць трэці рэзалвер, пра які лёгка забыцца. Бяспечны DNS браўзера разрознівае імёны самастойна і можа працягваць адказваць пасля таго, як тунель змяніў палітыку аперацыйнай сістэмы, таму старонка, якая загружаецца, даказвае, што рэзалвер браўзера працаваў, а не што профіль быў ужыты. Калі вы параўноўваеце толькі тое, што паказвае браўзер, вы ў палове выпадкаў правяраеце не той узровень.
Запішыце базавы ўзровень толькі з адной зменнай
Змяніце тунель. Не змяняйце адначасова імя, інструмент або суфікс пошуку на тым самым кроку. Выберыце імя, запыт да якога вам дазволены, адзначце, якое прыкладанне вы выкарысталі, і запішыце або адрас, які вярнуўся, або дакладную памылку. На Windows Get-DnsClientServerAddress -AddressFamily IPv4 друкуе серверы для кожнага адаптара, а Get-DnsClientNrptPolicy друкуе запісы палітыкі; на Linux з systemd-resolved resolvectl status паказвае DNS-серверы і дамены маршрутызацыі для кожнага злучэння; на macOS scutil --dns друкуе парадак рэзалвераў, які сістэма фактычна будзе выконваць.
Затым падключыцеся праз звычайныя сродкі кліента і паўтарыце дакладна тыя ж каманды. Захавайце першы вывад, а не ўспамін пра яго, бо ўсё і ёсць у параўнанні, а другое чытанне, знятае пасля ачышчэння кэша, — гэта ўжо іншае вымярэнне. Калі базавы ўзровень здымаўся з браўзерам наперадзе, а запуск пасля падключэння адбываецца ў тэрмінале, вы параўноўваеце два рэзалверы, а не два станы аднаго рэзалвера.
Яўны запыт і пошук прыкладання — розныя тэсты
Запыт да аднаго пэўнага сервера, праз nslookup name 10.20.0.1 або dig @10.20.0.1 name, даказвае адну рэч: сервер, які вы назвалі, адказвае, калі да яго можна дабрацца. Ён цалкам абыходзіць логіку выбару, таму не можа сказаць, ці абрала б сістэма менавіта гэты сервер для гэтага імя. Выкарыстоўвайце яго, каб праверыць дасяжнасць прызначанага рэзалвера, і не выкарыстоўвайце для праверкі палітыкі.
Пошук праз лакальны рэзалвер сапраўды ажыццяўляе выбар. resolvectl query name праходзіць тыя ж правілы даменаў маршрутызацыі і паведамляе пратакол, які адказаў, Resolve-DnsName на Windows ідзе праз табліцу палітыкі і кэш кліента, а scutil --dns паказвае парадак, якому б ішоў пошук. Запусціце абодва тыпы і трымайце іх у асобных слупках вашых нататак. Паспяховы яўны запыт побач з няўдалым пошукам прыкладання — гэта праблема маршрутызацыі або выбару, а не рэзалвер, які адмаўляецца працаваць.
Кэшаванне стаіць паміж вамі і адказам. Аперацыйная сістэма, лакальны заглушаны рэзалвер, браўзер і адмоўнае кэшаванне ўсе захоўваюць вынікі, таму пошук можа паспяхова завяршыцца, нават калі ні адзін пакет не пакідае машыну. Запішыце вынік, перш чым нешта ачышчаць: ipconfig /flushdns, resolvectl flush-caches або sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder на macOS. Прапусціце шырокі скід сеткі на гэтым этапе, бо ён знішчае доказы, якія вы яшчэ збіраеце.
Што азначае розніца
Параўнайце два радкі, якія вы запісалі, і класіфікуйце змену, перш чым крануць хоць адну наладу.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
Адзін радок варта падкрэсліць. Імя, якое разрозніваецца, — гэта не працуючая паслуга, і поспех DNS кажа толькі пра тое, што адрас быў знойдзены. Ён нічога не кажа пра перанакіраванне, правілы фаервала ці пра тое, ці мае ваш уліковы запіс права карыстацца паслугай наогул, таму скончыце тым, што праверыце сапраўднае прыкладанне, а не будзеце меркаваць, што збой сышоў сам сабой.
Аднавіце базавы ўзровень і праверце яго
Адключыцеся праз уласныя сродкі кліента, а не забіваючы працэс, затым перачытайце тыя ж тры каманды. Серверы для кожнага злучэння, запісы палітыкі і адказ для вашага тэставага імя павінны вярнуцца да базавага ўзроўню, які вы запісалі раней. Застаўшыся запіс палітыкі пасля чыстага адключэння — гэта сапраўдны дэфект, варты запісу, і менавіта таму ручныя праўкі ў згенераваным файле рэзалвера — дрэнная звычка: файл перапісваецца і праўка знікае, або праўка застаецца і замацоўвае рэзалвер, у якога больш няма маршруту.
Прайдзіцеся па гэтым спісе адзін раз, па парадку. Вырашыце, які дызайн рэалізуе профіль, перш чым ацэньваць любы вынік. Трымайце імя, інструмент і суфікс нязменнымі ў абодвух запусках. Аддзяліце яўны запыт ад пошуку прыкладання. Чытайце эфектыўную палітыку, а не толькі адказ. Ачышчайце кэшы апошнімі, пасля таго як параўнанне запісана. Праверце на сапраўдным прыкладанні, затым адзін раз перазагрузіцеся і пераканайцеся, што стан адключэння ўсё яшчэ чысты.