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 спецификациясы порт ережеңіз көрмейтін шифрланған жол үшін анықтама.