Un moyen simple de créer un tunnel d'un port local à un autre?

J'ai un serveur de développement, qui n'est accessible qu'à partir de 127.0.0.1:8000, pas 192.168.1.x: 8000. En guise de solution rapide, existe-t-il un moyen de configurer quelque chose à écouter sur un autre port (par exemple 8001) de sorte que je puisse me connecter au réseau local 192.168.1.x: 8001 et qu'il achemine le trafic entre le client et 127.0 .0,1: 8000?

Utiliser ssh est la solution la plus simple.

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

Cela transmet le port local 8001 de votre poste de travail à l'adresse localhost du port 8000 de remote-server.com. Cela
-gsignifie que les autres clients de mon réseau peuvent se connecter au port 8001 de mon poste de travail. Sinon, seuls les clients locaux de votre poste de travail peuvent se connecter au port transféré.
-Nsignifie que tout ce que je fais est de transférer des ports, ne lancez pas de shell.
-fsignifie passer en arrière-plan après une connexion et une connexion SSH réussies.
Le port 8001 restera ouvert pour de nombreuses connexions, jusqu'à ce que ssh décède ou soit tué. Si vous êtes sur Windows, l'excellent client SSH, PuTTY, peut également le faire. Utilisez 8001 comme port local et localhost: 8000 et la destination et ajoutez un transfert de port local dans les paramètres. Vous pouvez l'ajouter après une connexion réussie avec PuTTY.

Avec socatsur le serveur:

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

Par défaut, socatécoute sur le port TCP 8001 de n’importe quelle adresse IPv4 ou IPv6 (si prise en charge) sur la machine. Vous pouvez le limiter à IPv4 / 6 en remplaçant tcp-listenpar tcp4-listenou tcp6-listen, ou à une adresse locale spécifique en ajoutant un ,bind=that-address.

Pareil pour le socket de connexion auquel vous utilisez le proxy, vous pouvez utiliser n'importe quelle adresse à la place de localhost, et remplacer tcppar tcp4ou tcp6si vous souhaitez limiter la résolution d'adresse aux adresses IPv4 ou IPv6.

Notez que pour le serveur qui écoute sur le port 8000, la connexion apparaîtra comme provenant du proxy (dans le cas de localhost, ce sera localhost), pas du client d'origine. Vous devez utiliser des approches DNAT (mais nécessitant des privilèges de superutilisateur) pour que le serveur puisse déterminer le client.

Utiliser le traditionnel ncest la solution la plus simple:

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

Cette version de ncest dans le netcat-traditionalpaquet sur Ubuntu. (Vous devez update-alternativesou appelez-le nc.traditional.)

Notez que contrairement à ssh, ce n’est pas chiffré. Gardez cela à l'esprit si vous l'utilisez en dehors d'un hôte.

OpenBSD netcat est disponible par défaut sous Linux et également sous 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

Une alternative qui fonctionne sur OS X bash consiste à utiliser un canal bidirectionnel . Cela peut fonctionner sur d'autres Unix:

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

Citant un David Spillett de » réponse sur ServerFault

rinetd devrait faire le travail, et un binaire Windows pour cela peut être obtenu à partir de http://www.boutell.com/rinetd/ (pour ceux qui recherchent la même chose sous Linux, rinetd se trouve dans les référentiels standard de presque toutes les distributions. donc peut être installé avec "apt-get install rinetd" ou "yum install rinetd" ou similaire)

C’est un simple binaire qui prend un fichier de configuration au format

bindaddress bindport connectaddress connectport

Par exemple:

192.168.1.1 8001 127.0.0.1 8000

ou

0.0.0.0 8001 127.0.0.1 8000

si vous souhaitez lier le port entrant à toutes les interfaces.

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

service iptables save
service iptables restart

Sur la base de la réponse de Mark A. , je devais faire un petit ajustement pour que cela fonctionne sur mon Mac (du moins sur macOS Mojave Version 10.14.4).

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

Cette déclaration de printf semble être cruciale. Sinon, la commande netcat pour se connecter au port 8000 ne tentera jamais réellement de se connecter, et la commande netcat pour écouter sur le port 8001 ne l'écoutera jamais sur le port 8001. Sans printf, j'essaierais chaque fois de me connecter au port 8001 Connexion rejetée.

Mon hypothèse est que netcat doit d’une manière ou d’une autre bloquer sur stdin (peut-être essaie-t-il de le lire pour une raison quelconque) avant d’effectuer réellement une opération de Socket. En tant que tel, sans l'instruction printf écrite dans fifo a, la commande netcat ne commencera jamais à écouter sur le port 8001.

Note: J'aurais laissé une réponse sur le post de Mark, mais je n'ai pas encore de réputation.

C'est une nouvelle façon de tunnelliser deux ports udp sur le serveur: https://github.com/9crk/udpeer

udpeer 8001 8002

Tester:

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