OpenVPN tras stunnel: reenvía el envoltorio, no el puerto 1194

Coloca un envoltorio TLS delante de OpenVPN y el despliegue gana un segundo oyente, de los cuales solo uno debería mirar nunca a internet. Cuando el túnel funciona desde la misma máquina y falla desde fuera, el reenvío suele apuntar al equivocado de los dos. Lo que debe encajar es una cadena: la regla pública llega al envoltorio, y la propia conexión de backend del envoltorio llega al socket VPN real. Cuatro saltos llevan esa cadena, y cualquiera de ellos puede terminar la investigación antes de tiempo.

Dos sockets, dos dueños, uno de ellos público

El envoltorio termina TLS para la conexión externa y pasa el flujo de bytes descifrado a un oyente OpenVPN TCP simple. Son sockets separados con archivos de configuración separados, así que editar uno deja el otro intacto y todavía aparentemente sano. También significa que los dos pueden separarse siempre que se cambie uno sin el otro.

Trabajar desde la propia máquina, por tanto, demuestra muy poco sobre la ruta pública. Una conexión directa al puerto nativo se salta el envoltorio, una conexión al envoltorio en su dirección LAN se salta la traducción, y solo la disposición completa del lado del cliente ejercita lo que hace un usuario externo. Los nombres también hay que leerlos con cuidado, porque localhost significa el host que ejecuta ese componente concreto y no el host en el que escribes por casualidad. Mantén esa distinción en tus notas, porque una prueba registrada sin el salto que cubría invita a comparar dos cosas distintas.

Dónde aterriza realmente el reenvío

La cadena es más fácil de retener como cuatro saltos que como tres números de puerto, porque el mismo número puede significar cosas distintas en cada extremo. Lee la tabla fila por fila: cada fila es un socket que debe aceptar una conexión y luego abrir la siguiente. Cuando una fila apunta al par equivocado, el síntoma de la última columna es lo que reporta el usuario.

Una regla que apunta al puerto VPN nativo en lugar de al envoltorio se salta por completo la terminación TLS, que es la versión más común de este error: el cliente abre un handshake con un oyente que espera el encuadre de OpenVPN, así que la conexión puede abrirse y luego atascarse. Confirma el puerto traducido contra el archivo de configuración del envoltorio y no contra la memoria, porque la próxima persona que edite ese archivo puede haber elegido otro número. Los dos comandos de abajo muestran las dos caras de esa cuestión a la vez.

grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'

La dirección de enlace que te rechaza

Una línea accept enlazada a 127.0.0.1 solo responde al propio host, así que un reenvío que llega a la dirección LAN no puede conectar y el cliente ve un rechazo que suena a problema de filtro de paquetes. Mira el socket antes de tocar el cortafuegos, porque el socket es la respuesta más barata. O bien enlaza el envoltorio a la interfaz a la que apunta el reenvío, o bien lo mantienes en loopback y haces que el reenvío llegue a loopback a través de algo que funcione de verdad. Son dos diseños, y cada uno necesita su propia regla.

Mezclarlos es como un envoltorio funcional acaba inalcanzable desde fuera mientras cada archivo parece correcto. La comprobación de abajo es un solo comando, y responde una pregunta que una revisión de las reglas del cortafuegos no puede. Si la salida muestra una dirección loopback mientras el reenvío apunta a la dirección LAN, la corrección pertenece a la línea accept y no al filtro de paquetes.

ss -lntp '( sport = :8443 )'

Qué demostró realmente la prueba local

Un éxito registrado sin el salto que cubría no es evidencia sobre los otros saltos. Anota qué dirección usó la prueba y qué proceso respondió. Luego repite desde fuera de la red en lugar de desde un teléfono en la misma Wi-Fi, porque el comportamiento de horquilla varía entre routers y una conexión que nunca salió de la LAN puede satisfacer a un cliente sin que el reenvío participe en absoluto. Solo ese segundo intento ejercita el camino que toma un desconocido.

Cuando el intento falla, sigue una sola conexión por ambos registros: las líneas de aceptación y conexión del envoltorio, luego el registro de sesión del demonio VPN. La primera frontera que no registra nada es donde pertenece el siguiente cambio. Una vez que OpenVPN compara opciones de par, juzga esos mensajes por las reglas de esa implementación. Un aviso de inconsistencia de link-mtu no es automáticamente fatal, fijar link-mtu en 1500 no demuestra que la fragmentación se haya detenido, y la negociación de cifrado pertenece a la configuración interna de OpenVPN y no al reenvío del router.

nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pager

Esas sondas cubren el socket de backend y el registro del envoltorio, lo que separa un backend rechazado de un handshake rechazado. Ejecútalas mientras un solo intento está en curso y no después. Las marcas de tiempo de un solo intento son lo que hace fiable la comparación.

Dos identidades, dos órdenes de fallo

El certificado externo pertenece al envoltorio y la identidad interna pertenece a OpenVPN, y pueden venir de autoridades distintas. Desactivar cualquiera de las dos comprobaciones para que un camino parezca sano cambia una protección real por un resultado cosmético. Mantén ambas verificaciones y depúralas en orden, porque la secuencia de mensajes nombra la capa: un problema de certificado del envoltorio aparece antes de que se negocie cualquier opción VPN, mientras que un fallo de identidad interna aparece solo una vez establecido el flujo.

El manual de stunnel define accept, connect y el modo cliente con precisión, y esas secciones responden la pregunta del socket más rápido que adivinar. Cuando todavía no puedes decir qué capa respondió, lee el certificado que presenta el puerto público con el comando de abajo. Un certificado de envoltorio en la salida significa que el reenvío llegó al envoltorio, y el silencio o un error de protocolo significa que no. Esa única distinción ahorra más tiempo que cualquier otra comprobación aquí.

openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer