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