Дазволіць DNS толькі праз VPN-рэзалвер: пакрокавая інструкцыя

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

Крок 1: назвіце рэзалвер і шлях

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

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

Крок 2: задайце палітыку там, дзе яна насамрэч жыве

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

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

Крок 3: уводзьце шлях вузка

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

Блакаваць DoH і DoT законна; меркаваць, што правіла порта 53 ужо іх заблакавала, не. Браўзер з DoH развязвае імёны шляхам, якога ваша правіла ніколі не апісвала, і праграма з уласным рэзалверам робіць тое ж самае. Запішыце кожны шлях, які вы хочаце дазволіць, і кожны, які хочаце адхіліць. Правіла, якое не называе шлях, не прыняло рашэння пра яго.

Крок 4: сачыце за прыватнымі і публічнымі імёнамі

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

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

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

Крок 5: пакіньце шлях назад

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

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