Ваш 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 усё яшчэ кажа, што ён можа чытаць запыты, дакументацыя павінна гэта сказаць, бо дыяграме, якая сцвярджае адваротнае, даверыцца той, хто ніколі не запускаў гэтыя каманды.