Ваш VPN шифрує DNS чи лише наступний хоп?

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

Запишіть, хто отримує запит на кожному етапі, перш ніж торкатися файлу конфігурації.

Дві схеми виглядають однаково на сторінці налаштувань

У першій схемі пристрій сам запускає DNS over TLS, а тунель лише переносить це з'єднання до вибраного вами резолвера. Сеанс TLS завершується на резолвері, тобто резолвер бачить запит, а вихід VPN бачить зашифрований текст, який не може прочитати. У другій схемі пристрій надсилає звичайний DNS через тунель до форвардера на хості VPN, і цей форвардер відкриває власне зашифроване з'єднання з вищим резолвером. У списку функцій обидві виглядають як "зашифрований DNS з VPN", але читабельний запит вони розміщують у різних будівлях.

Різниця вимірювана, а не філософська. Знайдіть сеанс TLS на клієнті або на сервері й дізнаєтеся, яка схема у вас насправді.

Складіть карту ланцюга резолверів, перш ніж його змінювати

Порахуйте резолвери на шляху й назвіть роль кожного. Компонент пересилання передає запит іншому резолверу, тоді як рекурсивний резолвер виконує роботу з пошуку відповіді й може напряму спілкуватися з авторитетними серверами. Ці ролі визначені окремо саме з цієї причини, і визначення резолверів із RFC 9076 варто прочитати, перш ніж припускати, що існує єдиний вищий адресат. Хост, який запускає власний рекурсивний резолвер, не має єдиного "вищого рівня" для шифрування, що робить увесь план недійсним.

Потім запитайте, який компонент налаштований використовувати клієнт. DNS-адреса, яку надає профіль VPN, повідомляє, куди йдуть запити, а не який процес на них відповідає.

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

Перевірте, який хоп зашифровано

Почніть із клієнта й підтвердіть, чи має він сеанс TLS до порту 853. Запит, який правильно розв'язується через порт 53, нічого не доводить про шифрування.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

Потім перейдіть на хост VPN і пошукайте вихідне зашифроване з'єднання, яке відкрив форвардер. Таблиця сокетів покаже, чи існує вищий сеанс TLS і який процес ним володіє:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

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

Запишіть власника й поведінку під час збою

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

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

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