OpenVPN en el puerto 53: tres conversaciones que la gente confunde
La consulta del extremo, el transporte cifrado y el DNS posterior al túnel son tres conversaciones. Identifique qué etapa falló antes de cambiar un puerto o un resolutor.
Los informes que dicen que la VPN está bloqueada en el puerto 53 mezclan tres observaciones que fallan por motivos distintos. La resolución del nombre del extremo ocurre antes de que exista cualquier túnel, el transporte cifrado es una conversación aparte y las consultas DNS que se hacen después son una tercera. Cada una tiene su propia firma de fallo, y solo una de ellas trata de DNS en realidad.
Ordene los paquetes por propósito antes de cambiar nada, porque la corrección sigue a la etapa.
Tres conversaciones, un número de puerto
La primera conversación es una consulta de nombre para el extremo: su máquina pregunta a su resolutor configurado dónde está vpn.example.com, y esa respuesta llega por DNS normal antes de que el cliente envíe un solo paquete de túnel. La segunda es el propio transporte de OpenVPN, que se conecta a la dirección que produjo la consulta con el protocolo y el puerto que indique el perfil. La tercera ocurre cuando el túnel ya está activo, cuando las aplicaciones piden nombres y la configuración de resolutor empujada decide quién responde.
Esas tres pueden tener éxito o fallar de forma independiente. Un cliente puede resolver su extremo a la perfección y aun así no alcanzar el receptor, y puede establecer un túnel mientras toda consulta de nombre interna falla porque la configuración DNS nunca llegó.
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
Lea la tabla como una lista de comprobación, no como una descripción. Si el nombre del extremo no se resuelve, nada posterior puede funcionar, y el túnel nunca arranca.
El número de puerto no nombra la aplicación
El puerto 53 transporta DNS por convención, y un operador de OpenVPN también puede publicar un receptor allí, y por eso mismo el número es un mal identificador. Una sesión de OpenVPN sobre UDP 53 sigue siendo una sesión de OpenVPN, y una consulta DNS a un servidor en el puerto 53 no dice nada sobre si se permite un túnel. Las líneas proto y remote del perfil definen el extremo exterior; el número de puerto no define nada por sí solo.
Eso corta en ambos sentidos al diagnosticar: una sonda UDP genérica al puerto 53 demuestra que un puerto responde, no que responda el servicio VPN. Pruebe con el cliente real y el perfil real, porque solo eso ejercita el saludo que el servicio espera.
Demuestre el receptor antes de culpar a la red
En el servidor, confirme qué está enlazado con ss -lunp | grep 53 y compárelo con el protocolo y el puerto del perfil. Desde la red del cliente, ejecute el cliente con mayor verbosidad para que el registro muestre qué dirección y qué transporte intentó. Si el servidor escucha y los paquetes del cliente no llegan, la ruta o la política los rechazan, y eso es una conversación para el propietario de la red, no un motivo para cambiar de puerto.
Un puerto distinto solo ayuda cuando el servicio realmente escucha allí y el despliegue lo permite. Mover un receptor para esquivar el filtrado de una red gestionada es una decisión de política, no un paso de resolución de problemas. Pregunte al propietario de la red qué está permitido antes de cambiar el servicio, porque una solución alternativa que vulnera la política se cerrará más adelante de todos modos. Anote esa respuesta junto al perfil para que la siguiente persona no repita la petición.
Compruebe el DNS después del túnel, por separado
Una vez activo el túnel, inspeccione el estado del resolutor en la interfaz VPN y consulte un nombre interno y un nombre público. Si los nombres internos fallan mientras el túnel transporta tráfico, la configuración DNS empujada no se aplicó, lo que es una cuestión de integración del cliente y no de transporte. Si los nombres públicos fallan y los internos funcionan, la política de túnel dividido hace lo que se configuró para hacer.
Deje los cambios de DNS al propietario del resolutor. Sobrescribir una configuración de resolutor gestionada para que pase una prueba puede romper nombres privados para todo lo demás en la máquina. Si el túnel empuja un resolutor y el cliente lo ignora, corrija la integración del cliente en lugar de añadir una entrada estática en otro sitio. Las entradas estáticas ocultan el fallo hasta que alguien cambia de red. Anote qué resolutor debe responder cada espacio de nombres.