VPN через DNS — це не те саме, що DNS-сервер для VPN

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

Розділіть три схеми

У першій схемі VPN надає резолвер або налаштування політики імен. Дані застосунків і далі йдуть через їхні власні мережеві з'єднання, а тунель впливає лише на те, який сервер відповідає на запит.

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

У третій взаємодійний клієнт кодує інші дані в повідомлення DNS, а взаємодійна кінцева точка відновлює їх. Звичайний шлях резолвера стає транспортом, і резолвер тепер є складовою шляху даних, а не службою імен.

Перевірте, що переносять повідомлення DNS

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

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

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

Перевірте ємність, перш ніж брати зобов'язання

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

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

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

Перевірте безпеку носія

Не припускайте, що інкапсуляція DNS забезпечує конфіденційність або надійне автентифікування. Шлях резолвера й кінцева точка тунелю бачать те, що розкриває реалізація, і це розкриття залежить від проєкту.

Шифрування й вибір носія — окремі властивості. Тунель можна шифрувати поверх звичайного IP-шляху, а тунель через DNS можна побудувати із захистом корисного навантаження або без нього. У будь-якому разі зберігайте HTTPS застосунку і оцінюйте реальний проєкт безпеки тунелю, а не його назву.

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

Узгодьте виправлення з реальним збоєм

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

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

Список перевірок короткий: визначте схему, підтвердьте, що переносять повідомлення, виміряйте ємність, потім перегляньте довіру. Будь-який крок, що не відповідає симптому, означає, що дві інші схеми ще в грі.