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

За откази на частни имена първо проверете предвидената политика на резолвера: кой сървър трябва да отговаря, кои имена са в обхвата и дали на клиента е разрешено да го използва. След това изберете разрешен транспорт, който отговаря на изискването, и пазете конфигурацията на резолвера в записа за промени, за да не започне следващият инцидент същото търсене отначало.

Списъкът с проверки е кратък: определете подредбата, потвърдете какво пренасят съобщенията, измерете капацитета, след което прегледайте доверието. Всяка стъпка, която не съответства на симптома, означава, че другите две подредби все още са в игра.