Дозволити 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 — це довідка для зашифрованого шляху, якого ваше правило порту не бачить.