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.

Artigos relacionados