Розділений тунель виключає браузер, а не його 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

Запитайте резолвер і явно, щоб збій можна було віднести до сервера, а не до шляху. Потім перезапустіть браузер і повторіть, бо застосунки кешують негативні відповіді, і старий збій виглядає постійним.

Після схваленої зміни запишіть маршрут даних і отримувача резолвера двома окремими рядками з датою. Якщо поведінка повернеться при наступному підключенні, виправляти треба профіль, який її задає, а не браузер.