VPN sobre DNS no es lo mismo que un servidor DNS de VPN

VPN sobre DNS describe una idea de transporte y no es sinónimo de apuntar un dispositivo a un resolutor personalizado. La pregunta que resuelve la confusión es sencilla: ¿qué transportan realmente los mensajes DNS? Una VPN normal puede instalar un resolutor para que las aplicaciones cubiertas encuentren nombres privados, y cambiar ese resolutor solo cambia la resolución de nombres. Ejecute las comprobaciones siguientes en orden, porque los tres arreglos comparten vocabulario y casi nada más.

Separe los tres arreglos

En el primer arreglo, la VPN proporciona un resolutor o un ajuste de política de nombres. Los datos de la aplicación siguen viajando por sus propias conexiones de red, y el túnel solo influye en qué servidor responde a la consulta.

En el segundo, el DNS cifrado protege el intercambio DNS en sí. DNS sobre HTTPS y DNS sobre TLS envuelven las consultas al resolutor elegido y no transportan paquetes de ninguna otra aplicación. Tampoco ocultan los nombres de consulta al resolutor que usted eligió, lo que es una frontera de confianza distinta de ocultarlos a la red local.

En el tercero, un cliente que coopera codifica otros datos en mensajes DNS y un extremo que coopera los reconstruye. La ruta normal del resolutor se convierte en el transporte, y el resolutor ahora es un componente de la ruta de datos en lugar de un servicio de nombres.

Compruebe qué transportan los mensajes DNS

Cambie el resolutor y observe si cambia la ruta del tráfico de la aplicación. Si la aplicación sigue conectando a las mismas direcciones por los mismos sockets, cambió la resolución de nombres y nada más.

Un túnel transportado por DNS necesita un arreglo correspondiente del lado del servidor. Iodine es un ejemplo documentado: su documentación del proyecto describe un túnel IP a través de DNS y requiere un componente de servidor que entienda la codificación. Introducir una dirección de resolutor público en Android no proporciona ese extremo, y un término de marketing compartido por dos productos no es una especificación de protocolo.

La captura es la comprobación decisiva. Si ve consultas normales al resolutor y nada más, no hay túnel. Si ve carga codificada en nombres de consulta y respuestas, ha encontrado el portador, y la siguiente pregunta es cuánto puede mover.

Compruebe la capacidad antes de comprometerse

DNS se diseñó para consultas y respuestas, no para entrega masiva. La sobrecarga de codificación, los límites de tamaño de los mensajes y el comportamiento del resolutor se llevan su parte de la ruta nominal, así que la capacidad útil es menor de lo que sugiere el enlace subyacente. Trate cualquier cifra de rendimiento que no haya medido en su propia ruta como una hipótesis y no como un presupuesto. Mida ambas direcciones, porque la subida y la bajada pueden chocar con límites distintos en un portador de petición y respuesta.

El cliente también debe decidir qué tráfico entra en el túnel. Una interfaz local del servicio VPN puede recoger paquetes, pero la interfaz no dice nada sobre cómo el transporte remoto los protege o los reenvía. La fragmentación y la retransmisión se comportan de forma distinta cuando el portador es un protocolo de petición y respuesta en lugar de un flujo, y una conexión que permanece abierta dice poco sobre la latencia interactiva.

Mida con el tráfico que piensa transportar. Un túnel que va bien para un latido periódico puede ser inservible para una sesión interactiva, y lo contrario también es cierto.

Compruebe la seguridad del portador

No suponga que la encapsulación DNS proporciona confidencialidad o autenticación fuerte. La ruta del resolutor y el extremo del túnel ven lo que expone la implementación, y esa exposición varía según el diseño.

El cifrado y la elección del portador son propiedades separadas. Un túnel puede cifrarse sobre una ruta IP simple, y un túnel transportado por DNS puede construirse con o sin protección para su carga. Mantenga el HTTPS de la aplicación en su sitio en cualquier caso, y evalúe el diseño de seguridad real del túnel y no su nombre.

Si el requisito es privacidad frente a la red local, el DNS cifrado y un túnel de datos responden a partes distintas de eso. Anote contra qué observador se defiende antes de elegir uno.

Adapte la solución al fallo real

Para una VPN lenta normal, sustituirla por un túnel transportado por DNS añade un transporte restringido encima del problema. No repara la calidad de radio, la congestión ni la carga del servidor, y normalmente las hace más visibles.

Para fallos de nombres privados, revise primero la política de resolutor prevista: qué servidor debe responder, qué nombres están dentro del alcance y si el cliente tiene permiso para usarlo. Después elija un transporte autorizado que coincida con el requisito, y conserve la configuración del resolutor en el registro de cambios para que el siguiente incidente no reinicie la misma búsqueda.

La lista de comprobaciones es corta: identifique el arreglo, confirme qué transportan los mensajes, mida la capacidad y luego revise la confianza. Cualquier paso que no coincida con el síntoma significa que los otros dos arreglos siguen presentes.