Redirección de tráfico TCP/UDP mediante túneles SSH

SSH nos permite crear túneles entre puertos TCP, por ejemplo:

ssh -L 2500:127.0.0.1:25 usuario@servidor.com

El comando anterior abrirá el puerto TCP 2500 en la máquina cliente, redirigiendo todo el tráfico mediante la conexión establecida con ‘servidor.com’ hacia ‘127.0.0.1’ (también podría ser otra IP de la red a la que tiene acceso ‘servidor.com’). También podemos hacerlo en sentido inverso:

ssh -R 2500:127.0.0.1:25 usuario@servidor.com

En este caso, se abrirá el puerto TCP 25000 en la máquina servidor, y se redirigirá el tráfico al puerto TCP 25 del cliente.

El problema aparece cuando queremos redirigir puertos UDP, para éstos tenemos 2 opciones: utilizar netcat o socat.

Imaginemos que queremos redirigir el puerto UDP 161(protocolo SNMP) de ‘servidor.com’ (donde únicamente esta escuchando por la IP 127.0.0.1). Si queremos utilizar netcat (apt-get install nc), en el servidor ejecutaremos:

mkfifo /tmp/fifo_virtual
chmod 600 /tmp/fifo_virtuall
nc -l -p 1610 -s 127.0.0.1 < /tmp/fifo_virtual | nc -u localhost 161 > /tmp/fifo_virtual

Netcat conectará el puerto UDP 161 con un nuevo puerto TCP 1610.

En el cliente, primero realizaremos la conexión SSH que nos tunelizará el anterior puerto TCP 1610:

ssh -L 1610:127.0.0.1:1610 usuario@servidor.com

Y a continuación (en el cliente):

sudo mkfifo /tmp/fifo_virtual_gpl
sudo chmod 600 /tmp/fifo_virtual_gpl
sudo ifconfig lo:0 127.0.0.2 up
sudo nc -l -u -p 161 -s 127.0.0.2 < /tmp/fifo_virtual_gpl | nc localhost 1610 > /tmp/fifo_virtual_gpl

En este caso, netcat conectará al puerto TCP 1610 creado por SSH y generará uno nuevo UDP 161. En este punto, tendremos conectado el puerto UDP 161 en la IP 127.0.0.2 del cliente con el puerto UDP 161 en la IP 127.0.0.1 del servidor, todo tunelizado y cifrado mediante SSH.

Esto mismo podemos hacerlo mediante socat (apt-get install nc), en el servidor ejecutariamos:

socat tcp4-listen:1610,bind=127.0.0.1,fork,reuseaddr UDP:localhost:161

Y en el cliente:

sudo ifconfig lo:0 127.0.0.2
sudo socat udp4-listen:161,bind=127.0.0.2,fork,reuseaddr tcp:localhost:1610

El túnel con SSH sería idéntico. Las desventajas de cada uno de ellos:

  • Netcat parece funcionar unicamente para la primera conexión UDP que se realiza, las siguientes hay que volver a re-ejecutar de nuevo los comandos.
  • Socat crea procesos hijo por cada conexión (forks), por tanto permite varias conexiones pero se si se realizan muchas, inunda la máquina de procesos.

Más detalles en: Performing UDP tunneling through an SSH connection.

Leave a Reply

Your email address will not be published. Required fields are marked *