Por qué el proxy de Cloudflare no puede transportar OpenVPN con un solo nombre

Una sola máquina ejecuta el sitio web y el servidor OpenVPN, y la tentación es apuntar un único nombre de host hacia ella y dejar que la nube naranja ordene el tráfico. El proxy ordena HTTP y HTTPS. No ordena una sesión de OpenVPN, sea cual sea el puerto que use esa sesión. Dos nombres, uno directo y otro con proxy, no cuestan nada y eliminan toda la clase de confusión.

Dos nombres, dos transportes

Da al sitio web un registro con proxy para que su tráfico HTTP y HTTPS pase por Cloudflare. Da a la VPN un registro solo DNS que resuelva directamente a la entrada pública de la VPN, y deja que el cliente use el puerto UDP o TCP para el que está configurado.

Ambos nombres pueden acabar en la misma máquina de origen. La diferencia es qué ocurre entre el cliente y esa máquina, y esa diferencia es el sentido de la separación.

La referencia de puertos de red de Cloudflare enumera qué puertos acepta el proxy web ordinario. Esa lista trata de HTTP y HTTPS en esos puertos, no de protocolos arbitrarios que casualmente comparten un número.

El puerto no es el protocolo

Mover OpenVPN a TCP 443 no lo convierte en HTTPS. El proxy sigue esperando una petición HTTP al inicio de la conexión, y un cliente OpenVPN envía en su lugar un mensaje de control binario. La conexión falla de una forma que parece un bloqueo de red porque nada útil llega a un registro.

Si el requisito es de verdad poner un producto de Cloudflare en la ruta de datos de la VPN, evalúa uno que documente compatibilidad con el protocolo que necesitas. No supongas que la nube naranja es un túnel TCP o UDP general, porque es un proxy inverso para tráfico web con una tarea concreta.

Un registro solo DNS es la respuesta aburrida que funciona, y es la primera a la que hay que recurrir.

Una máquina sigue necesitando dos oyentes

Los nombres separados no permiten que dos procesos enlacen la misma dirección, puerto y transporte al mismo tiempo. Si el servidor web ya ocupa TCP 443 en todas las direcciones, una instancia de OpenVPN no puede tomarlo también sin un acuerdo deliberado.

Enlaza el oyente de la VPN a un puerto distinto, o a una dirección distinta, o pon delante un multiplexor documentado y acepta el coste operativo que conlleva. Cada una de esas decisiones debe verse en las reglas del cortafuegos, porque un oyente que nadie documentó es el que se pasa por alto durante un incidente. Escribe el enlace elegido en el mismo runbook que describe el túnel. Así la siguiente persona no lo redescubre a las dos de la madrugada.

Los certificados siguen a la conexión que protegen

La conexión TLS del navegador con Cloudflare y la conexión de Cloudflare con tu origen son dos relaciones separadas con dos certificados separados. El navegador ve un certificado de borde. El origen presenta su propio certificado a Cloudflare, y un certificado Cloudflare Origin CA está pensado exactamente para esa segunda relación.

Ese certificado de origen es de confianza para Cloudflare en el modo Full (strict) y no es un certificado de navegador de confianza general. Si alguien visita directamente el nombre de host solo DNS y recibe un aviso, es la consecuencia esperada de una ruta de confianza cambiada, no la prueba de que el cifrado se haya detenido.

Por eso un sitio web visitado directamente necesita una cadena de certificados en la que confíen sus navegadores. Eso puede convivir con un sitio con proxy cuyo origen no está pensado para visitarse en absoluto.

OpenVPN lleva su propia identidad de servidor y autenticación de cliente, con su propia autoridad de certificación y su propia protección del canal de control. Un candado en el sitio web no aporta nada de eso, y los dos procesos de aprovisionamiento deben permanecer separados.

La exposición sigue al nombre

Un registro VPN solo DNS publica la dirección a la que apunta. Si esa dirección es también el origen web, el origen no queda oculto, y describirlo como oculto porque el otro nombre usa proxy es un error que dura hasta que alguien lo escanea.

Decide qué peticiones web pueden llegar directamente al origen y aplícalo en el origen, y luego permite el oyente de la VPN en sus propios términos. Las páginas de administración, las descargas de perfiles y el oyente de datos pueden tener tres requisitos de exposición distintos incluso cuando un solo paquete proporciona los tres.

Mantén los enlaces generados en el nombre web público y el esquema HTTPS, y mantén los perfiles de cliente en el nombre de la VPN con el protocolo y el puerto reales. Ninguno de los dos servicios debería depender de cambiar el ajuste de proxy del otro durante el funcionamiento normal.

Orden de trabajo: nombre con proxy para el sitio, nombre solo DNS para la VPN, oyentes distintos, certificado por relación y luego una prueba que demuestre que cada nombre solo llega al servicio que debe.