OpenVPN y HTTPS en el puerto 443: ¿quién posee el socket de escucha?
TCP y UDP 443 son sockets distintos. Compartir un solo listener TCP exige un dueño, y el uso compartido del puerto de OpenVPN es un acuerdo estrecho, no un truco de proxy.
Dos servicios pueden responder ambos en el puerto 443 sin competir nunca, porque un listener se define por el transporte, la dirección y el puerto juntos, no por el número solo. Pon un servidor web y OpenVPN en una máquina, y la única pregunta que merece respuesta primero es qué socket pide cada proceso al núcleo. Anota esa lista antes de editar una configuración, y la mayoría de los errores de dirección en uso se explican solos. Todo lo que sigue a la lista es una elección entre un listener UDP, un socket TCP compartido o un frontal que enruta por protocolo.
Empieza por el socket que pide cada proceso
Un bind triunfa o falla según esa terna, así que dos demonios solo chocan cuando coinciden las tres partes. Por eso un sitio web en TCP 443 convive indefinidamente con un listener de OpenVPN en UDP 443, y por eso mover uno de ellos a una segunda dirección local en el mismo host también termina la discusión. Lee los listeners vivos en lugar de los archivos que se suponía que los creaban, porque un include obsoleto o un archivo de unidad olvidado sobrevive a la edición que recuerdas haber hecho.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
Ejecuta ss -lntup como root y lee cada línea que mencione 443, incluidas las entradas IPv6. Un listener v6 comodín suele aceptar también tráfico v4, y así es como un listener que olvidaste mantiene el puerto ocupado después de que cambias el archivo que creías responsable. Si un nombre de proceso te sorprende, estrecha la salida con ss -lntup 'sport = :443' antes de tocar nada.
Cambia el túnel a UDP cuando la red lo permita
Un listener UDP esquiva la colisión por completo y suele ser la reparación más corta, ya que no se comparte ningún socket y ningún producto extra entra en el camino. No es gratis. Algunas redes de clientes descartan UDP 443 sin enviar un reset, así que el túnel deja de establecerse en lugar de fallar en el bind, y el usuario informa que la VPN está caída sin ningún error que leer. Un listener UDP también sobrevive a un reinicio de la capa web, lo que cuenta en una máquina cuyo sitio se despliega a menudo. Prueba desde la red donde están los usuarios, porque un shell en el servidor solo demuestra que el servidor se alcanza a sí mismo.
Cambia el transporte en la configuración del servidor y en el perfil del cliente a la vez. Un perfil que todavía pide TCP entrará en un bucle de reconexiones contra un listener solo UDP, y eso parece una falla de red hasta que comparas los dos archivos.
Deja que el proceso de la VPN sea dueño de TCP 443 y reenvía el resto
Community OpenVPN en modo servidor TCP lee los primeros bytes de una conexión entrante y reenvía todo lo que no es su propio protocolo a un backend HTTPS, que es para lo que sirve la directiva port-share. El backend es un servidor web normal con TLS activado, nombrado por host y puerto en esa directiva en lugar de por una URL.
port-share 10.0.0.5 8080
En una máquina donde el sitio tiene una segunda dirección privada, esa línea envía el tráfico que no es VPN a 10.0.0.5:8080, así que el host virtual HTTPS debe estar vinculado allí y el cortafuegos debe permitir el salto local. El servidor web debe terminar TLS por sí mismo, porque los bytes que llegan son el handshake original del navegador y nada intermedio los ha descifrado. Apunta la directiva a un listener HTTP simple y el navegador recibirá un error de método no válido, que se lee como un sitio roto en lugar de un backend mal colocado. La directiva solo existe en modo servidor TCP, y un listener UDP no tiene ningún flujo que inspeccionar.
Como el proceso de la VPN acepta cada conexión, la aplicación web ve la petición reenviada llegar desde una de las direcciones del propio host en lugar de desde el visitante. Todo lo que necesita la dirección real del cliente depende del soporte del protocolo PROXY en el backend o de un frontal que la añada. Mover el backend a otra dirección local no devuelve la dirección del visitante; solo cambia cuál de las direcciones del host registra el sitio. Anota esa limitación en las notas de despliegue antes de que un informe de analítica plantee la pregunta.
Un proxy inverso es la herramienta equivocada; un enrutador de capa cuatro no
Un proxy inverso HTTP termina TLS para poder leer peticiones, lo que significa que no puede dejar pasar un flujo de OpenVPN intacto. Un enrutador de capa cuatro que reenvía por SNI o por inspección del primer paquete puede situarse delante de ambos, siempre que no termine la sesión de la que depende la VPN. Los dos dispositivos se parecen en un diagrama y se comportan de forma completamente distinta en el socket.
El Access Server comercial trae sus propios ajustes de uso compartido de puerto, y no se corresponden uno a uno con la directiva de la comunidad. Identifica el producto y la versión antes de adaptar una guía escrita para el otro. Un ajuste copiado que se ignora en silencio es peor que no tener ajuste, porque la lista de listeners sigue pareciendo plausible después.
Prueba el sitio web y el túnel como dos caminos separados
Carga el sitio y conecta el túnel, luego lee de nuevo la lista de listeners para ver qué proceso es dueño de 443 ahora. Una página que carga no demuestra nada sobre la VPN, y un túnel que conecta no demuestra nada sobre el sitio, aunque ambos usan el mismo número. Los tres comandos de abajo comprueban el socket compartido, el camino web y el servicio VPN en ese orden.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Compara la dirección del cliente en el registro de acceso del backend con la del registro de la VPN en el mismo momento. Si el sitio registra cada visitante como el propio host, el reenvío funciona y el manejo de la dirección no. Si ambos registros callan, el frontal nunca entregó la conexión. De cualquier forma, la lista de listeners decide quién acepta el socket, y ese es el hecho que hay que confirmar antes de cambiar otro archivo.
Deja ese mapa de listeners junto a la configuración para que la siguiente persona que toque 443 sepa qué proceso acepta y adónde fue el otro protocolo. Confirma la propiedad después del cambio en lugar de confiar en lo que la edición pretendía hacer.