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 добавляет ограниченный транспорт поверх проблемы. Он не исправляет качество радиосвязи, перегрузку или нагрузку сервера и обычно делает их заметнее.

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

Список проверок короток: определите схему, подтвердите, что переносят сообщения, измерьте ёмкость, затем пересмотрите доверие. Любой шаг, не соответствующий симптому, означает, что две другие схемы всё ещё в игре.