Por qué tu mapeo de puertos VPN de Docker nunca llega a OpenVPN
El puerto del host, el del contenedor y el transporte son tres decisiones distintas. Sigue un intento UDP por cada frontera antes de tocar los certificados.
Tu contenedor puede escuchar en UDP 1195 mientras el host publica 1194, y eso es correcto siempre que el mapeo lo diga. Los números forman una tabla de traducción: el cliente marca el puerto del host, Docker reescribe el destino al puerto del contenedor y OpenVPN responde en el puerto que indica su propia configuración. Un desajuste en cualquiera de esos eslabones produce un fallo silencioso que parece un cortafuegos. Los certificados y los cifrados están después y no pueden repararlo.
Sigue un paquete del cliente al proceso antes de cambiar nada de la autenticación.
Tres números, una conexión
Los tres números son el destino remoto que usa el cliente, el mapeo publicado en el host y el oyente dentro del contenedor. No tienen que ser iguales, pero deben encadenarse. Los números iguales son un caso especial que resulta ser el habitual, por eso un desajuste es fácil de escribir una vez y difícil de ver después.
Escribe la cadena en una línea antes de depurar: dirección y puerto del cliente, mapeo del host, oyente del contenedor, transporte. Un defecto en la cadena se muestra como un número que aparece dos veces con valores distintos.
| Location | Example |
|---|---|
| Remote client destination | Host address, UDP 1194 |
| Published mapping | Host UDP 1194 to container UDP 1195 |
| Container listener | OpenVPN on UDP 1195 |
Qué dice realmente la sintaxis corta
En la forma corta el lado izquierdo es el puerto del host y el derecho el puerto del contenedor, y un sufijo con barra inclinada elige el transporte. Si omites el sufijo, Docker trata el mapeo como TCP, así que un oyente UDP detrás de un mapeo sin protocolo es un oyente al que nadie puede llegar. Ese valor por defecto está documentado y sigue sorprendiendo a quienes cuadraron los números y lo dieron por terminado.
La forma larga fija la dirección de enlace y el protocolo de forma explícita, lo que vale las líneas extra en cualquier cosa expuesta a una red. Vuelve a leer el mapeo publicado en lugar de confiar en el archivo que lo produjo.
ports:
- 1194:1195/udpDónde puede detenerse el paquete
Una petición puede descartarse antes de Docker, en Docker o en el oyente. Delante de Docker puede haber un cortafuegos de nube o un router que haga su propio reenvío, y ese dispositivo necesita el puerto orientado al host y el transporte correcto. Dentro de Docker, un mapeo al puerto de contenedor equivocado reenvía a un socket cerrado.
Luego el oyente: la configuración de OpenVPN nombra un puerto y un protocolo, y un cliente que llega a otro dentro del contenedor no llega a nada. Probar un servicio UDP con TCP no demuestra nada en ninguna de estas etapas, así que usa el transporte que usará el cliente.
Las direcciones de enlace deciden el alcance
Un mapeo publicado ligado a loopback solo es accesible desde el host, mientras que uno ligado a todas las interfaces es accesible donde el cortafuegos lo permita. Los dos parecen idénticos en un archivo Compose que omite la dirección, y el valor por defecto de Docker es el amplio.
Decide qué exposición pretende el despliegue y luego escríbela de forma explícita. Una prueba interna que conecta por loopback y un cliente remoto que no puede conectar pueden ser ambas descripciones exactas del mismo contenedor.
Lee el estado en ejecución
Inspecciona el mapeo efectivo del contenedor en ejecución y el oyente en su espacio de nombres de red. Un archivo Compose puede haberse editado después de arrancar el contenedor, los metadatos de la imagen pueden declarar un puerto sin publicarlo, y un segundo contenedor puede ocupar ya el puerto del host. Declarar un puerto en una imagen no es publicarlo, y ninguna de las dos cosas es lo mismo que escuchar.
Tres estados distintos, tres comandos distintos, y solo el último implica a OpenVPN.
Cuando el mapeo es correcto
Una vez que el paquete llega a OpenVPN, su registro es el lugar donde leer sobre TLS y autenticación. Regenerar certificados para arreglar un paquete que nunca llegó es trabajo perdido que añade una segunda variable. Mantén la nota del mapeo junto al perfil del cliente para que la siguiente persona lea una línea en lugar de redescubrir los tres números. Una captura de paquetes en el lado del host resuelve cuál de los tres eslabones falla, y cuesta menos que regenerar un certificado.
La publicación por puente es el caso descrito aquí. La red del host y las direcciones de contenedor enrutadas se saltan la traducción, así que los mismos números significan otra cosa en esos diseños.