Ваш VPN прапануе тры DNS-серверы: які з іх адказвае?
Дадатковыя запісы могуць быць рэзервовым варыянтам, маршрутам для асобнага дамена або рэшткай фізічнага злучэння. Суаднясіце кожны з іх з пэўнай сферай, перш чым называць спіс уцечкай.
Адкрыйце старонку налад пасля падключэння, і ўбачыце тры адрасы DNS; пытанне аўдыту ў тым, які з іх апрацаваў ваш апошні запыт. Сам па сабе лік нічога не адказвае, бо кліенцкі штуршок, фізічны інтэрфейс і палітыка для асобных даменаў пішуць у адзін і той жа выгляд. Гэтыя запісы маюць розныя сферы, і менавіта сфера, а не пазіцыя, вырашае, хто адказвае. Пачніце з падзелу крыніц, затым праверце тую, што валодае патрэбным вам імем.
Чаму спіс даўжэйшы за ваш профіль
Кліент VPN прапануе адрасы рэзалвера для злучэння тунеля, а аперацыйная сістэма трымае іх побач з тым, што ўжо меў фізічны інтэрфейс. Маршрутызатар, карпаратыўная арэнда DHCP, другі VPN і палітыка для асобных даменаў кожны дадаюць свой запіс. Таму тры адрасы на старонцы могуць азначаць тры сферы, а не тры кандыдаты на адну працу. Чытаць лік як доказ уцечкі — першая памылка гэтага аўдыту.
У межах аднаго інтэрфейса кліент сапраўды спрабуе свае серверы па чарзе, таму ўпарадкаваны спіс не бяссэнсавы. Але чаргой не з'яўляецца аб'яднаны выгляд, дзе запісы профілю, фізічнага злучэння і правілаў для асобных даменаў стаяць побач без адзінага ранжыравання. Гэта адрозненне вызначае, што вы правяраеце: парадак тлумачыць паводзіны ў межах адной сферы, а сфера — усё астатняе.
Шыфраваны DNS ламае карціну знутры праграмы. Браўзер або кліент чатаў з уласным рэзалверам DNS-over-HTTPS цалкам абыходзіць сістэмны спіс, таму адрасы на старонцы налад апісваюць трафік, якога праграма ніколі не стварала. Праверце ўласную наладу рэзалвера праграмы, перш чым вінаваціць профіль у няправільным імені.
Што паказвае кожная з трох праверак
Кожная крыніца пакідае свой след у розным месцы, і ніводная каманда не пакажа ўсе. Вось суаднясенне, якое варта трымаць побач са старонкай налад:
| Entry source | Where it is visible | What it proves |
|---|---|---|
| Tunnel profile | Link-scoped DNS on the tunnel device | Which servers the VPN asked you to use, not which one answered |
| Per-domain policy | Suffix list or routing domains | Which names are steered to a particular resolver |
| Physical link | DNS on the LAN interface | Whether a second scope still exists outside the tunnel |
| Application resolver | App settings, absent from the OS list | Whether the system list was consulted at all |
У сістэме з systemd-resolved аўтарытэтнай з'яўляецца resolvectl status, бо яна паведамляе пра DNS для кожнага злучэння разам з даменамі маршрутызацыі. macOS адказвае праз scutil --dns, якая пералічвае рэзалверы са сферамі ў парадку іх спроб. Windows дзеліць дзве паловы: Get-DnsClientServerAddress для сервераў кожнага інтэрфейса і Get-DnsClientNrptPolicy для правілаў суфіксаў. Запусціце каманду, якая адпавядае рэзалверу, што фактычна выкарыстоўваецца, бо на машыне з кантэйнерным асяроддзем і настольным рэзалверам можа быць усталяваны не адзін.
Рэзервовы рэзалвер, які не можа адказаць за вашу зону
Другі запіс звычайна існуе для даступнасці, а даступнасць працуе толькі тады, калі рэзерв ведае імёны. Спытайце публічны рэзалвер пра ўнутранае імя хоста, і ён верне NXDOMAIN або адказ па шаблоне з пошукавага дамена, які не мае да вас ніякага дачынення. Рэзервовы пераход, якога ніхто не правяраў, тады стварае збой менавіта ў момант, калі ён патрэбны.
Split DNS існуе, каб гэтаму засцерагчы: суфіксы кампаніі ідуць да рэзалвера, які трымае зону, а публічныя імёны застаюцца на стандартным шляху. Дызайн слушны, і ён залежыць ад таго, ці поўны спіс суфіксаў. Microsoft дакументуе палітыку рэзалвера для кожнага суфікса, што кіруе гэтым у Windows, і тая ж ідэя ўзнікае як дамены маршрутызацыі ў systemd-resolved і як рэзалверы са сферамі ў macOS.
Параўнайце зоны, за якія можа адказваць рэзерв, з суфіксамі ў палітыцы. Гэтае параўнанне знойдзе прабел перш, чым карыстальнік паведаміць, што адзін унутраны сайт перастаў вырашацца пасля змены тунеля.
Запытвайце праз палітыку, а не ў абыход яе
Запытвайце праз рэзалвер аперацыйнай сістэмы, бо прамы запыт да сервера абыходзіць палітыку і паведамляе толькі тое, што сказаў бы гэты сервер. Розніца паміж двума адказамі і ёсць сутнасць:
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53Калі сістэмны запыт вяртае прыватны адрас, а прамы вяртае NXDOMAIN, палітыка працуе, і слабое месца — рэзерв. Калі абодва вяртаюць адзін і той жа публічны адказ, імя вырашаецца па-за сферай, якую вы мелі на ўвазе, і шукаць трэба ў спісе суфіксаў. Захоўвайце абодва вывады, бо спрэчку пра рэзалвер хутчэй закрыюць два радкі, чым здымак экрана старонкі налад.
Затым праверце шлях збою, бо рэзерв, якога ніхто не тэставаў, — гэта здагадка. Ператварыце прыярытэтны рэзалвер у чорную дзірку для аднаго запыту і паглядзіце, які адрас вернецца:
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32Выдаліце гэты маршрут адразу пасля завяршэння запыту, інакш наступны чалавек атрымае ў спадчыну загадку. Калі ўнутраныя імёны ў гэтым акне ўсё яшчэ вырашаюцца, значыць, на іх адказала нешта па-за меркаванай сферай. Калі ж яны замест гэтага сканчаюцца тайм-аўтам, рэзерв адсутнічае або слушна абмежаваны, і ўласны журнал рэзалвера скажа, што менавіта было.
Вырашыце: пакінуць, абмежаваць або выдаліць
Трымайце другі рэзалвер, калі ён адказвае за патрэбную вам прастору імёнаў і застаецца дасяжным пад профілем. Абмяжуйце яго сферай, калі ён павінен бачыць адзін суфікс і нічога іншага, і выдаліце яго, калі ў яго няма ні сферы, ні дакументаванай мэты. Запіс без працы — будучая ўцечка без карысці, а стандарт пастаўшчыка — не мэта.
Запішыце вынік у чатыры слупкі: суфікс, рэзалвер, інтэрфейс і ўладальнік. Гэты радок адкажа на наступнае пытанне аўдыту хутчэй за любы здымак экрана і перажыве абнаўленне кліента, якое ціха перапарадкоўвае спіс.