Чи справді використовується DNS вашого VPN? Перехопіть порт 53 і подивіться

Запитайте більшість людей, що клієнт VPN робить із DNS, і вони скажуть, що він задає розв'язувач, тож запити йдуть усередині тунелю. Проштовхування реальне; припущення, що воно стає запитом, — ні. Між проштовхнутим параметром і пакетом на дроті стоять три етапи, і кожен відмовляє незалежно так, що все виглядає як зламаний DNS-сервер. Тому сторінка тесту витоку й робочий браузер можуть розходитися щодо однієї машини в один і той самий момент.

Проштовхнутий параметр — не запит

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

Більшість діагностики зливає ці три в один і звинувачує сервер VPN, який зазвичай єдина сторона, здатна довести, що виконала свою частину. Читайте натомість реальний стан розв'язувача клієнта, потім простежте вихід одного запиту. Ці два спостереження відокремлюють конфігурацію від маршрутизації та від політики, і вони коштують близько п'яти хвилин. Зберігайте записи, бо наступному інженеру потрібні «до» і «після», а не їхній опис.

Перевірте, що насправді тримає інтерфейс

У Linux системним розв'язувачем може бути звичайний файл, NetworkManager або systemd-resolved, і те, хто з них ним володіє, визначає, де осяде проштовхнутий сервер. Процес OpenVPN з командного рядка сам не оновлює системний розв'язувач, тож документована інтеграція — це скрипт up/down або менеджер з'єднань, який уже вміє застосовувати налаштування. Запускати обидва — ефективний спосіб створити гонку.

resolvectl status
cat /etc/resolv.conf

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

Простежте один запит за межі машини

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

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

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

Брандмауер, який приймає лише власний DNS

Комерційні клієнти іноді встановлюють власні ланцюги фільтрації. Один документований шаблон дозволяє DNS до власного розв'язувача клієнта й відкидає весь решта трафіку UDP на порту 53, що намагається покинути інтерфейс, який не є loopback, включно з трафіком, який користувач навмисно спрямував в інше місце. Запити демона зникають без сліду, що читається як відмова розв'язувача, а не як фільтр.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

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

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

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

Чому сторінка витоку доводить менше, ніж здається

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

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