Cómo un reenvío local SSH transporta una sesión TCP de OpenVPN

Aquí se apilan tres transportes, y cada uno tiene su propio entramado. La carga útil de la VPN viaja dentro de una sesión TLS, esa sesión TLS viaja dentro de una conexión TCP hacia un puerto de bucle local, y los bytes de esa conexión viajan dentro de SSH hacia un host de retransmisión, que abre la conexión TCP real hacia el receptor de la VPN. Nada en la disposición cambia lo que OpenVPN autentica, y nada en ella hace que un receptor UDP sea alcanzable por TCP. Lea el resto como una descripción del camino de los bytes, no como una receta para eludir un control de red.

Qué mueve realmente el reenvío local

El cliente SSH escucha en un puerto local. Cuando un proceso local se conecta, el cliente empaqueta los bytes en su canal cifrado, y el lado del servidor abre una nueva conexión TCP hacia el destino nombrado en la petición de reenvío.

Ese destino lo resuelve el relay, no su máquina, por eso un nombre que solo existe dentro de la red remota sigue funcionando. También significa que el relay debe poder alcanzar al receptor de la VPN y tener una ruta de vuelta hacia él. Un nombre que se resuelve en su portátil no dice nada sobre lo que el relay puede ver.

Iniciar la sesión SSH solo demuestra que el relay es alcanzable y está autenticado. No dice nada sobre si el siguiente receptor está activo, si un cortafuegos entre el relay y el receptor acepta la conexión, o si la VPN aceptará su perfil.

Apunta el cliente al receptor local

Un ejemplo declarado: el relay puede alcanzar un receptor TCP en gw.internal.example:443, y un puerto local alto expone ese camino solo a esta máquina.

ssh -N -L 127.0.0.1:24011:gw.internal.example:443 [email protected]

El manual de OpenSSH describe el reenvío local como la aceptación de conexiones TCP de forma local y la apertura de la siguiente conexión desde el lado remoto. Ate el receptor al bucle local en lugar de a todas las interfaces, porque un reenvío alcanzable desde la red es un relay abierto con su nombre. Una vinculación comodín también expone el puerto a cualquier otra cuenta local en una máquina compartida.

Después ponga el cliente de la VPN en su modo TCP y apúntelo a 127.0.0.1:24011. Si el perfil usa UDP, este diseño no puede ayudar: el reenvío transporta un flujo de bytes y no hay ningún camino de datagramas a través de él.

Mantenga las dos autenticaciones separadas

SSH autentica al host de retransmisión. OpenVPN sigue autenticando al par de la VPN, y el destino de bucle local no cambia ese requisito. Desactivar las comprobaciones de certificado porque el socket ahora apunta a localhost es el peor atajo disponible en este diseño. Convierte una disposición de transporte en una disposición de confianza, y nadie aprobó la segunda.

Mantenga intactos el ancla de confianza del perfil, la comprobación del rol de servidor y la verificación del nombre. Si su cliente compara el nombre del servidor con la dirección a la que llamó, el bucle local puede necesitar un ajuste explícito de nombre en lugar de una comprobación desactivada, y la documentación del perfil es el lugar para confirmar qué campo se compara.

Trate el relay como una segunda parte en la historia de confianza: su administrador puede ver metadatos de conexión y puede redirigir el reenvío si se cambia la configuración. La disposición necesita la aprobación tanto del relay como del propietario del servicio VPN, no solo de quien lo necesita hoy.

No construya un bucle bajo el túnel

Una vez que la VPN instala rutas, la conexión SSH que la transporta todavía necesita un camino hacia el relay que no pase por el túnel. Si la ruta por defecto se mueve a la VPN y el relay solo es alcanzable por ese mismo túnel, el transporte se derrumba y la VPN se va con él. El fallo parece un túnel caído más que un error de enrutamiento, y por eso se diagnostica mal.

La solución habitual es una ruta de host hacia la dirección del relay fijada a la interfaz física antes de que suba el túnel, más una comprobación de que la ruta sobrevive a una reconexión. Verifíquela con una consulta de ruta para la dirección del relay en lugar de suponer que el orden era correcto.

También espere que esta pila sea más lenta y más frágil que una conexión directa, porque ahora hay dos transportes ordenados y otro punto final que mantener. Es una forma de cruzar una frontera de red, no una técnica de rendimiento.

Cierre el receptor cuando termine

Detenga la sesión SSH cuando el túnel ya no sea necesario y confirme que el puerto local se ha liberado. Un reenvío olvidado mantiene un camino autenticado abierto en una máquina que puede ser compartida.

Revise también los destinos de reenvío permitidos del relay, porque una configuración permisiva convierte cualquier cuenta comprometida en un pivote general. Anote el puerto, el relay y el destino juntos, para que la siguiente persona pueda saber para qué servía el reenvío y si todavía está aprobado.