Todos nos hemos encontrado en algún momento con que ese servicio al que queremos acceder está en un equipo inalcanzable desde nuestra red u otros problemas similares. Si disponemos de acceso SSH podemos solucionar fácilmente problemas de este tipo utilizando túneles SSH.
Planteamos un primer escenario, en el que tenemos un servidor de bases de datos al que podemos acceder por SSH, pero cuyo cortafuegos nos impide interactuar directamente con la base de datos (suponemos MySQL, que utiliza el puerto 3306).
En este caso, para ganar acceso local a la base de datos, haremos que todo el tráfico que vaya al puerto local X se redirija a través de la conexión SSH al puerto local 3306 de la máquina a la que nos estamos conectando, utilizando el modificador -L:
ssh -L X:localhost:3306 172.16.1.100
Ahora, si tenemos una aplicación que utilice dicho servidor de base de datos, símplemente debemos indicarle que la base de datos se encuentra en nuestro equipo local, en el puerto X. Del mismo modo, si el equipo que tiene la base de datos es un tercer equipo, al que no tenemos acceso desde nuestro equipo local pero si desde el servidor al que nos conectamos a través de SSH, la orden será:
ssh -L X:172.16.1.111:3306 172.16.1.100
También podemos querer justo lo contrario: que un servidor remoto pueda acceder a un recurso o servicio proporcionado por nuestro equipo o nuestra red local.
En este caso, haremos que todo el tráfico que el servidor remoto envíe a su puerto Y se redirija hacia el puerto Z de nuestro equipo, utilizando el modificador -R:
ssh -R Y:localhost:Z 172.16.1.100
Al igual que en el caso anterior, si el equipo que contiene el servicio que queremos conectar es uno distinto del nuestro, cambiaremos localhost por la IP de dicho equipo. Por ejemplo:
ssh -R Y:192.168.0.123:Z 172.16.1.100
Como extra, indicar que los servidores SSH ofrecen otra característica interesante, que consiste en crear un proxy de tipo SOCKS en el equipo local. Con esto hacemos que todas las peticiones que se envíen al puerto X del equipo local, se redirijan hacia el equipo remoto y se envíen a su destino como si las hubiera enviado el equipo remoto:
ssh -D X 172.16.1.100
Esto es de especial utilidad ya que existen multitud de aplicaciones cuyo tráfico puede ser reenviado a través de un proxy SOCKS. El mejor ejemplo de esto son los navegadores modernos, como Firefox, por ejemplo:
Esperamos que les haya gustado este pequeño post.
TIP: Cuando el número de “saltos” es considerable, resulta muy pesado mover ficheros desde el último salto hasta tu maquina. Nosotros, en iniqua.com, utilizamos una solución “rápida” -> http://www.iniqua.com/2010/11/13/eqntdc-uuencode-uudecode/
Hola ffranz,
No conocía esta opción, pero parece muy interesante.
¡ Gracias por el comentario !
Estimados, muy buen post. Solo una consulta, que puerto debo usar en caso de querer setear el localhost como proxy local con la opción ssh -D X 172.16.1.100. Muchas gracias.
Hola Tavo,
En principio no existe restricción de puerto. El único requisito es que indiques el mismo puerto tanto en el SSH como en la aplicación que vaya a utilizar el túnel SOCKS.
En esta página encontrarás información sobre nuevas tecnologías, circuitos electrónicos, montajes y esquemas eléctricos.
Buen artículo y explicaciones. Lo recomendaré por las redes sociales.