En algunos de los servidores provistos por Helpcom se implementa un puente SSH reverso, es decir un túnel como el descrito en tunel ssh excepto que la conexión se abre desde el destino hacia el equipo de origen.

La sintaxis general de un puente reverso es:

ssh -R puertoremoto:hostlocal:puertolocal user@hostremoto

Por ejemplo, abrir el siguiente puente reverso desde el servidor de un cliente, y conectarlo al puerto 3456 en el servidor de desarrollo de Helpcom, permite al servidor de desarrollo acceder a las bases de datos del equipo cliente.

# en el servidor del cliente
ssh -R 3456:127.0.0.1:3306 miusuario@190.13.136.235
</code bash>
 
Mientras esa conexión remota esté activa, conectar al puerto ''3456'' desde ''localhost'' en el servidor de desarrollo accederá a la base de datos del cliente remoto.
 
===== Implementaciones =====
 
Este tipo de puente reverso está implementado en servidores como los de **Yomi**, para poder dar acceso a los clientes a las otras sucursales desde una sucursal con IP pública.
 
La estructura del script que ejecuta el puente es como sigue:
 
<code bash>
ssh -TN -gR 13301:127.0.0.1:3306 -p 22022 puente@${yomi_public_ip} &

Una estructura de comando como ésta se encuentra en bin/puente.sh en las sucursales que necesitan abrir el puente.

En el servidor de bodega de Yomi, se habilita el usuario puente, sin privilegios, solamente para que pueda tomar las conexiones remotas de las sucursales que necesitan abrir los puentes reversos.

El argumento -g es necesario para que el puente, una vez abierto, pueda recibir conexiones desde su red local en el lado remoto. Sin embargo la implementación de esto sólo funciona correctamente con el apoyo adecuado del servidor central (que debe soportar GatewayPorts) y del ISP (que debe soportar Nat Forwarding y Multicast Port Fallback).

Un crontab en los servidores remotos inicia la conexión junto con el sistema:

@reboot           bin/puente.sh

Para que el puente reverso funcione correctamente:

• El servidor remoto debe tener una IP - idealmente persistente - en una red alcanzable desde el servidor de inicio.
• El servidor remoto debe tener servicio de SSH abierto.

Para que el puente reverso se pueda abrir a la red local del punto remoto:

• El router de la red local debe soportar NAT Forwarding.
• Cada router o modem en el camino de “bajada” desde la red visible común (p.ej.: internet) hacia el servidor remoto debe soportar Multicast Fallback.
• Los puertos necesarios deben estar abiertos en cada servidor en la ruta de “bajada” hacia el servidor remoto.
• El servidor remoto debe tener una versión de OpenSSH Server com GatewayPorts habilitado.

La estabilidad de la conexión del puente depende especialmente de dos factores:

• La estabilidad y la velocidad de subida desde el servidor remoto.
• La traslación de puertos y conexiones de Multicast Fallback en el camino de bajada hacia la red remota.

Las siguientes notas son específicas a la implementación en Yomi:

El punto de conexión central (“endpoint”) es el servidor de Bodega (“sucursal 4”).

Los puertos abiertos son 13301 13302 y 13303 para las tres sucursales.

Una vez conectado a un servidor, es posible determinar si el puente está activado buscando el comando de ssh en la tabla de procesos:

# tomar nota del doble guión en el siguiente comando:
ps -ef | grep -- '-gR'
 
adminis+ 31697 31696  0 10:43 pts/3    00:00:00 ssh -TN -gR 13303:127.0.0.1:3306 -p 22022 puente@164.77.141.142

Si el comando entrega una salida como la que se ve arriba, esto quiere decir que el puente está activado.

Si el puente no se encuentra activado, es posible ejecutarlo de varias maneras, la más sencilla es:

nohup bin/puente.sh &

(Notar el & al final)