Частен DNS срещу VPN: какво всъщност покрива всеки слой

Телефонът ви има частен DNS, зададен на име на хост на доставчик, и едновременно с това работи VPN приложение. Разумно е да се предположи, че едно от двете вече отговаря за търсенето на имена. Нито едното не го прави в смисъла, който предполага това изречение, и най-бързият начин да видите защо е да проследите една заявка от момента, в който докоснете връзка.

Тези две функции стоят в различни точки от едно и също пътуване. Частният DNS шифрова въпроса, който задавате на резолвер. VPN променя маршрута, по който поема връзката на отговора.

Затова преминете през това по ред, на устройство, където и двете са включени, и отбележете какво още може да види всеки слой.

Първа стъпка: търсенето напуска приложението

Докосвате връзка. Преди нещо да се свърже, приложението се нуждае от адрес за това име на хост. В Android съответният екран е Настройки, Мрежа и интернет, Частен DNS. Избирането на Име на хост на доставчик за частен DNS поставя устройството в строг режим: то извършва DNS през TLS към това име на хост на порт 853, и ако шифрованият обмен се провали, търсенето се проваля, вместо тихо да се върне към открит текст на порт 53.

Това е съществена разлика от Автоматично, което използва опортюнистично шифроване и охотно ще използва нешифрован резолвер, когато мрежата се намеси. Ако целта ви е търсенията никога да не се извършват в открит вид, строгият режим с име на хост на доставчик е настройката, която отговаря на това.

Ето първото, което разкрива това преминаване: търсенето е защитено от локалната мрежа, а резолверът все пак научава името. Шифроването покрива само прехода. Операторът на този резолвер вижда заявката, защото отговарянето на нея е негова работа.

Втора стъпка: връзката поема друг маршрут

Резолверът връща адрес и приложението се свързва с него. Тази стъпка не се влияе от това как е било шифровано търсенето. Без тунел връзката излиза от обичайния ви публичен адрес, а IP адресът на дестинацията и ръкостискането TLS обикновено все пак правят името на хоста видимо за мрежата, със или без шифрован DNS.

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

Това разделение е цялото сравнение в едно изречение. Шифроването на DNS отговаря кой може да прочете въпроса. VPN отговаря накъде отива разговорът.

Трета стъпка: вътре в тунела DNS става въпрос на политика

Сега двете функции взаимодействат, а браузърът е обичайният източник на изненади. Браузър със собствена настройка за сигурен DNS може да изпраща търсения до избрания от него резолвер през HTTPS, вместо да пита операционната система. Настройката за частен DNS в Android не стига до това решение.

Във Firefox превключвателят е в Настройки, Поверителност и сигурност, Включване на сигурен DNS. В Chrome е в Настройки, Поверителност и сигурност, Използване на сигурен DNS. И двете могат да се зададат на конкретен доставчик или да останат изключени, а когато са включени, конфигурацията на DNS на тунела се заобикаля за тези търсения, въпреки че трафикът на страницата продължава да използва тунела.

Ако VPN предава свой собствен резолвер, а браузърът настоява на своя, получавате разделение: имената се разрешават, страниците се зареждат, а търсенията, които е трябвало да минават през тунела, са излезли директно. Адрес на резолвер, различен от крайната точка на VPN, сам по себе си не е доказателство за изтичане, но път на търсене, който противоречи на заявеното ви намерение, заслужава поправка.

Четвърта стъпка: вътрешните имена са мястото, където се чупи

Свържете се към работен VPN и отворете интранет хост. Ако сигурният DNS на браузъра е включен и сочи към публичен резолвер, това име не съществува за браузъра. Тунелът е вдигнат, всичко останало работи, а едно име на хост се проваля с грешка, която изглежда сякаш сайтът е недостъпен.

Същата повреда се появява обратно в Android. Строгият частен DNS с публичен доставчик няма да разреши имена, които знае само вътрешният резолвер, а строгият режим няма резервен път. Разделянето на DNS на телефона между публичен шифрован резолвер и корпоративен резолвер не е настройка; това е въпрос на политика за маршрутизиране, на който трябва да отговори този, който управлява VPN.

Проверете това, преди да обвините тунела: потърсете вътрешното име, а след това същото име с изключен сигурен DNS на браузъра. Ако се разреши, проблемът е бил в избора на резолвер, а не във връзката.

Какво ви казва това преминаване да промените

Четири екрана носят почти всичко. Погледнете ги в този ред и запишете какво казва всеки, защото отговорът обикновено се вижда в комбинацията:

1. Настройки на Android, Мрежа и интернет, Частен DNS: Автоматично или име на хост на доставчик, и кое име на хост.
2. Настройката за сигурен DNS на браузъра: изключена или прикачена към конкретен резолвер.
3. Политиката за DNS на VPN клиента: предава ли резолвер и изключва ли разделеният тунел нещо, което все още се нуждае от имена?
4. Тест на вътрешно име на хост при вдигнат тунел, изпълнен два пъти, веднъж с включен DNS на браузъра и веднъж с изключен.

След това съпоставете поправката с изискването, а не обратното. Ако изискването е търсенията да излизат шифровани и да отиват до избран от вас резолвер, задайте строг частен DNS и накарайте браузъра да се съгласи. Ако изискването е трафикът да излиза другаде, конфигурирайте тунела и престанете да очаквате настройка за DNS да премести адреса ви.

И дръжте ограниченията в полезрението. Нито една от функциите не прави враждебна дестинация безопасна и нито една не премахва самоличност, с която сте влезли. Шифроването променя кой може да прочете въпроса; тунелът променя накъде отива връзката; нито едно от тях не анонимизира акаунта.