¿Manera simple de crear un túnel de un puerto local a otro?

Tengo un servidor de desarrollo, al que solo se puede acceder desde 127.0.0.1:8000, no desde 192.168.1.x: 8000. Como truco rápido, ¿hay alguna manera de configurar algo para escuchar en otro puerto (por ejemplo, 8001) para que desde la red local pueda conectar 192.168.1.x: 8001 y así se canalice el tráfico entre el cliente y 127.0 .0.1: 8000?

Usar ssh es la solución más fácil.

ssh -g -L 8001: localhost: 8000 -f -N usuario@remote-server.com

Esto reenvía el puerto local 8001 en su estación de trabajo a la dirección localhost en el puerto remote-server.com 8000.
-gsignifica permitir que otros clientes en mi red se conecten al puerto 8001 en mi estación de trabajo. De lo contrario, solo los clientes locales en su estación de trabajo pueden conectarse al puerto reenviado.
-Nsignifica que todo lo que estoy haciendo es reenviar puertos, no iniciar un shell.
-fsignifica bifurcación en segundo plano después de una conexión SSH exitosa e inicio de sesión.
El puerto 8001 permanecerá abierto para muchas conexiones, hasta que ssh muera o muera. Si estás en Windows, el excelente cliente SSH PuTTY también puede hacer esto. Use 8001 como el puerto local y localhost: 8000 y el destino y agregue un reenvío de puerto local en la configuración. Puede agregarlo después de una conexión exitosa con PuTTY.

Con socaten el servidor:

socat tcp-listen:8001,reuseaddr,fork tcp:localhost:8000

De forma predeterminada, socatescuchará en el puerto TCP 8001 en cualquier dirección IPv4 o IPv6 (si es compatible) en la máquina. Puede restringirlo a IPv4 / 6 reemplazando tcp-listencon tcp4-listeno tcp6-listen, o a una dirección local específica agregando un ,bind=that-address.

Lo mismo para el zócalo de conexión al que está enviando proxy, puede usar cualquier dirección en lugar de localhost, y reemplazar tcpcon tcp4o tcp6si desea restringir la resolución de la dirección a direcciones IPv4 o IPv6.

Tenga en cuenta que para el servidor que escucha en el puerto 8000, la conexión aparecerá como proveniente del proxy (en el caso de localhostque así sea localhost), no del cliente original. Debería usar enfoques DNAT (pero que requieren privilegios de superusuario) para que el servidor pueda saber quién es el cliente.

Usar lo tradicional nces la solución más fácil:

nc -l -p 8001 -c "nc 127.0.0.1 8000"

Esta versión de ncestá en el netcat-traditionalpaquete en Ubuntu. (Tienes que hacerlo update-alternativeso llamarlo nc.traditional).

Tenga en cuenta que, a diferencia de ssh, esto no está cifrado. Tenga esto en cuenta si lo usa fuera de un host.

OpenBSD netcat está disponible por defecto en Linux y también en OS X.

OSX:

mkfifo a
mkfifo b
nc 127.0.0.1 8000 < b > a &
nc -l 8001 < a > b &

Linux:

mkfifo backpipe
nc -l 12345 0<backpipe | nc www.google.com 80 1>backpipe

Una alternativa que funciona en OS X bash es usar una tubería bidireccional . Puede funcionar en otros Unixes:

nc 127.0.0.1 8000 <&1 | nc -l 8001 >&0

Citando la respuesta de David Spillett en ServerFault

rinetd debería hacer el trabajo, y se puede obtener un binario de Windows para ello en http://www.boutell.com/rinetd/ (para cualquiera que busque lo mismo en Linux, rinetd está en los repositorios estándar de casi todas las distribuciones entonces se puede instalar con "apt-get install rinetd" o "yum install rinetd" o similar)

Es un binario simple que toma un archivo de configuración en el formato

bindaddress bindport connectaddress connectport

Por ejemplo:

192.168.1.1 8001 127.0.0.1 8000

o

0.0.0.0 8001 127.0.0.1 8000

si desea vincular el puerto entrante a todas las interfaces.

iptables -t nat -A PREROUTING -p tcp --dport <origin-port> -j REDIRECT --to-port <destination-port>

service iptables save
service iptables restart

Según la respuesta de Mark A. , tuve que hacer un pequeño ajuste para que funcione en mi Mac (al menos en macOS Mojave Versión 10.14.4)

mkfifo a
mkfifo b
nc 127.0.0.1 8000 < b > a &
nc -l 8001 < a > b &
printf "" > a

Esa declaración printf parece ser crucial. De lo contrario, el comando netcat para conectarse al puerto 8000 nunca intentará conectarse realmente, y el comando netcat para escuchar en el puerto 8001 nunca escuchará en el puerto 8001. Sin el printf, cada vez que intentara conectarme al puerto 8001 obtendría conexión denegada.

Mi suposición es que netcat debe bloquear de alguna manera en stdin (tal vez esté tratando de leerlo por alguna razón) antes de realizar cualquier operación de Socket. Como tal, sin la declaración printf escrita en fifo a, el comando netcat nunca comenzará a escucharse en el puerto 8001.

Nota: Hubiera dejado una respuesta en la publicación de Mark, pero aún no tengo reputación.

Esta es una nueva forma de tunelizar dos puertos udp en el servidor: https://github.com/9crk/udpeer

udpeer 8001 8002

Probar:

nc -u xxxx.com 8001
nc -u xxxx.com 8002