DNS праз VPN супраць DoH у браўзеры: чаго не пакажа тэст уцечкі

Адрас тэсту ўцечкі паказвае толькі, які рэзалвер адказаў. Шыфраваныя запыты, падзелены DNS і палітыка браўзера вырашаюць, ці наогул яшчэ вырашаюцца прыватныя імёны.

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

Міф першы: значок называе ваш рэзалвер

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

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

Міф другі: браўзер выходзіць з тунэля

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

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

Міф трэці: кожны VPN перамагае кожны браўзер

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

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

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

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

Рашэнне мае тры ўваходы, а не адзін

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

ConditionWhat it forces
Internal names must resolveSplit DNS: private suffixes to the VPN resolver, the rest to your chosen default
Queries must stay with one operatorPin both the system resolver and the browser mode, and disable fallback
Resolver only reachable through the tunnelKeep the pushed resolver; do not point DoH at an endpoint your routes exclude

Ні адзін з гэтых радкоў не з'яўляецца ўніверсальнай рэкамендацыяй. Рэзалвер, які кіруе VPN, канцэнтруе назіранні ў гэтага аператара; асобны сэрвіс дадае яшчэ аднаго атрымальніка запытаных імён. Ні адна з гэтых схем нічога не даказвае пра захоўванне, пакуль вы не прачытаеце палітыку.

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

Праверце палітыку, якую, як вам здаецца, вы наладзілі

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

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

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

Падобныя артыкулы