Чому відповідь DNS не проходить на безстановому прикордонному фаєрволі VPN

Тунель піднято, клієнти доходять до VPN-хоста, а сам хост нічого не може розв'язати. Його власні вихідні запити чисто залишають інтерфейс, отже збій на зворотному шляху: на вищій межі, яка фільтрує вхідний трафік, не пам'ятаючи, що хост щойно надіслав. Дозвіл порту тунелю зовсім не описує цей обмін. Відповідь на DNS-запит — окремий потік, і якщо межа без стану, ніщо не дало їй права повернутися.

Два обміни — не один і той самий обмін

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

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

Вхідне правило, яке вимагає порт призначення 53, описує трафік, адресований слухачеві DNS на хості, а це зовсім інша служба. Ті адреси — приклади з документації, а вихідний порт обирає клієнт для кожного запиту, тому це не значення, яке можна скопіювати в правило й чекати, що воно працюватиме далі.

Безстанова межа проти фаєрвола хоста зі станом

Фільтр межі без стану оцінює кожен вхідний пакет за своїм списком правил, не маючи за собою таблиці з'єднань. Вихідний запит, що успішно вийшов, не створює жодного дозволу для своєї вхідної відповіді, бо пристрій не має запису, що запит колись був. Фаєрвол хоста зі станом — навпаки: його відстеження з'єднань розпізнає зворотний трафік дозволеного обміну й пропускає його без правила для відповіді. Обидві межі існують на типовому шляху, і обидві мають пропускати потрібний пакет.

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

Будуйте дозвіл навколо протоколу, а не номера порту

Обмежте правило справжніми адресами резолвера, хостом призначення й політикою приймального порту, яку підтримує продукт. Пам'ятайте і про TCP-шлях DNS, бо велика відповідь або відкат через урізання переводить обмін на TCP, і правило лише для UDP його не покриє. Якщо межа підтримує перевірку зі станом для визначеного потоку, віддайте їй перевагу перед написаним вручну правилом відповіді, бо шлях зі станом автоматично йде за портами, які обрав клієнт.

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

Чому дозвіл будь-якого вихідного порту 53 не є виправленням

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

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

Перевіряйте на правильній межі, у правильному напрямку

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

Виправлення цього завершує обмін DNS, який хостові справді потрібен. Воно не перетворює хост на публічний резолвер, не дозволяє перенаправлені потоки VPN і не доводить, що DNS був причиною якоїсь не пов'язаної проблеми з тунелем.