A túa VPN cifra o DNS ou só o seguinte salto?
O DNS cifrado nun servidor VPN protexe un salto distinto do DoT no lado do cliente. Rastrexa quen recibe cada consulta antes de activar nada.
Activar DNS cifrado no servidor VPN descríbese a miúdo como pechar unha fuga, e esa descrición oculta que conexión cambiou. O salto do cliente ao resolutor e o salto do resolutor ao nivel superior son conexións separadas con propietarios separados. Cifrar unha deixa a outra exactamente como estaba.
Anota quen recibe a consulta en cada etapa antes de tocar ningún ficheiro de configuración.
Dúas disposicións parecen iguais nunha páxina de axustes
Na primeira disposición o dispositivo executa el mesmo DNS over TLS, e o túnel só transporta esa conexión ata un resolutor que escolliches. A sesión TLS termina no resolutor, o que significa que o resolutor ve a consulta e a saída da VPN ve texto cifrado que non pode ler. Na segunda disposición o dispositivo envía DNS normal polo túnel ata un reenviador no host da VPN, e ese reenviador abre a súa propia conexión cifrada cun resolutor superior. Ambas aparecen como "DNS cifrado con VPN" nunha lista de funcións, e colocan a consulta lexible en edificios distintos.
A diferenza é medible, non filosófica. Busca a sesión TLS no cliente ou no servidor e saberás que disposición tes en realidade.
Mapea a cadea de resolutores antes de cambiala
Conta os resolutores da ruta e nomea o papel de cada un. Un compoñente de reenvío entrega unha solicitude a outro resolutor, mentres que un resolutor recursivo fai o traballo de atopar unha resposta e pode falar directamente cos servidores autoritativos. Eses papeis defínense por separado precisamente por iso, e as definicións de resolutor do RFC 9076 merecen lectura antes de dar por feito que existe un único destino superior. Un host que executa o seu propio resolutor recursivo non ten un único "superior" que cifrar, o que invalida todo o plan.
Despois pregunta que compoñente ten configurado o cliente. Un enderezo DNS enviado polo perfil VPN dixeche cara a onde van as consultas, non que proceso as responde.
Fíxate tamén no comportamento ante fallos. Se o nivel superior cifrado deixa de ser accesible, o reenviador falla pechado, recorre a texto plano ou pasa a outro resolutor? Esa decisión pertence ao rexistro, porque cambia a garantía de privacidade no momento en que o túnel está menos san.
Verifica que salto está cifrado
Comeza no cliente e confirma se mantén unha sesión TLS cara ao porto 853. Unha consulta que se resolve correctamente polo porto 53 non demostra nada sobre o cifrado.
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
Despois pasa ao host da VPN e busca a conexión cifrada de saída que abriu o reenviador. A táboa de sockets dixeche se existe unha sesión TLS superior e que proceso a posúe:
ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short
Se o cliente mostra unha sesión TLS e o servidor ningunha, estás na primeira disposición e o servidor non pode ler as consultas que reenvía na capa IP. Se o servidor mostra a sesión TLS e o cliente mostra tráfico normal polo porto 53 dentro do túnel, estás na segunda disposición: o seguinte salto está protexido e o reenviador segue lendo cada nome que pide o dispositivo. Ese segundo resultado non é un fallo, pero chamalo cifrado de extremo a extremo é incorrecto.
Rexistra o propietario e o comportamento ante fallos
A propiedade decide que podes prometer. O propietario do dispositivo controla unha conexión cifrada no lado do cliente, mentres que o administrador da VPN controla a conexión seguinte que crea o seu reenviador. Quen non opera ningunha das dúas só pode describir a ruta.
Antes de activar nada, revisa o nomeado interno. Enviar nomes da organización a un resolutor público non é un deseño equivalente, e unha zona de split-horizon que só existe dentro da rede non se resolverá en absoluto no nivel superior. Proba un nome interno e un público despois do cambio e garda o resultado xunto co cambio de configuración. Se a ruta cifrada rompe a resolución dos hosts internos, a solución é unha regra de resolutor con alcance limitado e non un túnel máis ancho.
Termina escribindo unha frase por salto: que compoñente recibiu a consulta, se ese salto estaba cifrado e quen pode ler o nome. Cando a frase do host da VPN segue dicindo que pode ler as consultas, a documentación debería dicilo, porque un diagrama que afirme o contrario será crido por alguén que nunca executou os comandos.