El teu VPN xifra el DNS o només el següent salt?

Activar el DNS xifrat al servidor VPN sovint es descriu com tancar una filtració, i aquesta descripció amaga quina connexió ha canviat. El salt del client al resoledor i el salt del resoledor a l'extrem superior són connexions separades amb propietaris separats. Xifrar-ne una deixa l'altra exactament com era.

Anota qui rep la consulta a cada etapa abans de tocar cap fitxer de configuració.

Dos arranjaments semblen iguals en una pàgina de paràmetres

En el primer arranjament el dispositiu executa ell mateix DNS over TLS, i el túnel només transporta aquesta connexió fins a un resoledor que has triat. La sessió TLS acaba al resoledor, cosa que significa que el resoledor veu la consulta i la sortida del VPN veu text xifrat que no pot llegir. En el segon arranjament el dispositiu envia DNS ordinari pel túnel fins a un reenviador a l'amfitrió VPN, i aquest reenviador obre la seva pròpia connexió xifrada amb un resoledor superior. Tots dos apareixen com a "DNS xifrat amb VPN" en una llista de funcions, i situen la consulta llegible en edificis diferents.

La diferència és mesurable, no pas filosòfica. Busca la sessió TLS al client o al servidor i sabràs quin arranjament tens realment.

Mapa la cadena de resoledors abans de canviar-la

Compta els resoledors del camí i anomena el paper de cadascun. Un component de reenviament lliura una petició a un altre resoledor, mentre que un resoledor recursiu fa la feina de trobar una resposta i pot parlar directament amb servidors autoritatius. Aquests papers es defineixen per separat precisament per això, i les definicions de resoledor del RFC 9076 val la pena llegir-les abans de donar per fet que existeix una única destinació superior. Un amfitrió que executa el seu propi resoledor recursiu no té cap "superior" únic per xifrar, cosa que invalida tot el pla.

Després pregunta quin component té configurat el client. Una adreça DNS empesa pel perfil VPN et diu on van les consultes, no quin procés les respon.

Fixa't també en el comportament davant d'errors. Si el resoledor superior xifrat esdevé inabastable, el reenviador falla tancat, torna a text pla o passa a un altre resoledor? Aquesta decisió pertany al registre, perquè canvia la garantia de privadesa en el moment en què el túnel està menys sa.

Verifica quin salt està xifrat

Comença pel client i confirma si manté una sessió TLS cap al port 853. Una consulta que es resol correctament pel port 53 no demostra res sobre el xifrat.

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

Després passa a l'amfitrió VPN i busca la connexió xifrada de sortida que ha obert el reenviador. La taula de sockets et diu si existeix una sessió TLS superior i quin procés la posseeix:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

Si el client mostra una sessió TLS i el servidor no en mostra cap, ets al primer arranjament i el servidor no pot llegir les consultes que reenvia a la capa IP. Si el servidor mostra la sessió TLS i el client mostra trànsit ordinari al port 53 dins del túnel, ets al segon arranjament: el salt següent està protegit i el reenviador encara llegeix cada nom que demana el dispositiu. Aquest segon resultat no és un fracàs, però anomenar-lo xifrat d'extrem a extrem és incorrecte.

Anota el propietari i el comportament davant d'errors

La propietat decideix què pots prometre. El propietari del dispositiu controla una connexió xifrada al costat del client, mentre que l'administrador del VPN controla la connexió següent que crea el seu reenviador. Qui no opera cap de les dues només pot descriure el camí.

Abans d'activar res, comprova l'assignació de noms interna. Enviar noms d'organització a un resoledor públic no és un disseny equivalent, i una zona de split-horizon que només existeix dins de la xarxa no es resoldrà mai a l'exterior. Prova un nom intern i un de públic després del canvi i desa el resultat amb el canvi de configuració. Si el camí xifrat trenca la resolució dels amfitrions interns, la solució és una regla de resoledor amb abast limitat, no un túnel més ampli.

Acaba escrivint una frase per salt: quin component ha rebut la consulta, si aquell salt estava xifrat i qui pot llegir el nom. Quan la frase de l'amfitrió VPN encara diu que pot llegir les consultes, la documentació ho hauria de dir, perquè un diagrama que afirmi el contrari serà cregut per algú que mai no ha executat les ordres.