Раздвоены тунэль выключае браўзер, а не яго DNS-запыты

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

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

Шлях даных і шлях рэзалвера разыходзяцца

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

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

Знайдзіце, які працэс задае пытанне

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

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

Прачытайце дзейную канфігурацыю перад тэставаннем: якія звяны нясуць DNS-серверы, на якія прасторы імёнаў яны прэтэндуюць і ці перавышае палітыка для кожнага імя прадвызначаную. У Linux раздвоены DNS выкарыстоўвае дамены маршрутызацыі; у Windows табліца палітыкі разбору імёнаў робіць тое ж для прастор імёнаў. Ні адно не відаць са старонкі тэсту ўцечкі.

Вырашыце, які рэзалвер бачыць якое імя

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

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

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

Правярайце запыт і злучэнне асобна

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

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

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

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

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