tunnel
1.0.0
Sicherer, gemultiplexter TCP/UDP-Port-Forwarder mit Piping-Server von @nwtgck als Relay. Hauptsächlich für P2P-Verbindungen zwischen Peers hinter (mehreren) NAT/Firewalls konzipiert.
Für den Sonderfall von IPFS siehe unten #Beispiele.
ID: Jeder Knoten erhält eine eindeutige (base64) ID -
tunnel -iDie ID ist an die Hardware (MAC-Adresse) und die Umgebungsvariablen USER, HOME und HOSTNAME gebunden. Teilen Sie es ein für alle Mal mit Ihren Kollegen. Hinweis: Zwei Benutzer auf demselben Computer erhalten unterschiedliche Knoten-IDs, da sich ihre USER- und HOME-Variablen unterscheiden.
Servermodus: Stellen Sie Ihren lokalen Port den Peers zur Verfügung, mit denen Sie eine geheime Zeichenfolge teilen –
tunnel [options] [-u] [-k < shared-secret > ] < local-port >Client-Modus: Leiten Sie Ihren lokalen Port an den exponierten lokalen Port des Peers weiter –
tunnel [options] [-u] [-k < shared-secret > ] [-b < local-port > ] [-I < IP > ] < peer-ID:peer-port > Wenn mit der Option -b kein lokaler Port angegeben wird, verwendet tunnel einen zufälligen, nicht verwendeten Port. Der verwendete Port wird immer bei stdout gemeldet.
Die Option -I ist praktisch, wenn der Client auf einem Laptop läuft, der gelegentlich eine Verbindung zum LAN herstellt, in dem sich der Server befindet. Wenn der Server im LAN mit privater IP = <IP> gefunden werden kann, stellt tunnel eine Verbindung über das LAN her.
Client und Server müssen dasselbe Geheimnis verwenden, um sich miteinander verbinden zu können. Die geheime Zeichenfolge kann auch mithilfe der Umgebungsvariablen TUNNEL_KEY übergeben werden. Das mit -k übergebene Geheimnis hat Vorrang.
Das Flag -u bezeichnet die Verwendung von UDP anstelle des Standard-TCP. Wenn es verwendet wird, muss es von beiden Peers verwendet werden.
Alle Protokolle befinden sich standardmäßig in stderr. Mit der Option -l <logfile> kann man tunnel jedoch im Hintergrund ( Daemon-Modus ) starten, wobei die Protokolle in <logfile> gespeichert werden. Die Daemon-Prozess-ID wird dem Benutzer beim Start angezeigt, sodass er den Daemon jederzeit beenden kann
tunnel -K < procID >Optionen:
Eine vollständige Liste der Optionen finden Sie unter: tunnel -h
Herunterladen mit:
curl -LO https://raw.githubusercontent.com/SomajitDey/tunnel/main/tunnelMachen Sie es ausführbar:
chmod +rx ./tunnelDann systemweit installieren mit:
./tunnel -c install Wenn Sie keine sudo Berechtigung haben, können Sie stattdessen lokal installieren:
./tunnel -c install -lSo können Sie jederzeit nach der Installation aktualisieren:
tunnel -c update Dieses Programm ist einfach ein ausführbares bash -Skript, das auf Standard-GNU-Tools wie socat , openssl , curl , mktemp , cut , awk , sed , flock , pkill , dd , xxd , base64 usw. basiert, die in Standard-Linux-Distributionen leicht verfügbar sind.
Wenn auf Ihrem System eines dieser Tools fehlt und Sie nicht über die erforderlichen sudo Berechtigungen verfügen, um es aus dem nativen Paket-Repository zu installieren (z. B. sudo apt-get install <package> ), laden Sie eine portable Binärdatei herunter und installieren Sie sie lokal unter ${HOME}/.bin .
SSH :
Peer A macht lokalen SSH-Port verfügbar –
tunnel -k " ${secret} " 22Peer B verbindet sich -
tunnel -b 67868 -k " ${secret} " -l /dev/null " ${peerA_ID} :22 " # Daemon due to -l
ssh -l " ${login_name} " -p 67868 localhost IPFS :
Angenommen, Peer A hat die IPFS-Peer-ID: 12orQmAlphanumeric . Ihr IPFS-Daemon lauscht am Standard-TCP-Port 4001. Sie macht ihn verfügbar mit –
tunnel -k " ${swarm_key} " ipfs swarm_key ist einfach eine beliebige geheime Zeichenfolge, die Peer A verwenden kann, um zu steuern, wer über tunnel eine Swarm-Verbindung zu ihr herstellen kann.
Peer B verbindet sich jetzt mit Peer A für Dateifreigabe, Pubsub oder P2P –
tunnel -k " ${swarm_key} " 12orQmAlphanumericDieser letzte Befehlsschwarm stellt über das Piping-Server-Relay eine Verbindung zu Peer A her und stellt im Hintergrund alle paar Sekunden eine Schwarmverbindung her, um die Verbindung aufrechtzuerhalten.
tunnel startet den IPFS-Daemon im Hintergrund, sofern er nicht bereits aktiv ist.
Der Pfad zum IPFS-Repository kann mit der Option -r übergeben werden. Ansonsten wird wie gewohnt die Umgebungsvariable IPFS_PATH oder der Standardpfad ~/.ipfs verwendet. Beispiel: tunnel -r ~/.ipfs -i gibt die IPFS-Peer-ID an.
Remote-Shell :
Angenommen, Sie müssten regelmäßig Befehle auf der Linux-Box Ihres Arbeitsplatzes von Ihrem Heimcomputer aus ausführen. Und aus irgendeinem Grund möchten/können Sie SSH nicht über tunnel verwenden.
Stellen Sie am Arbeitsplatzcomputer einen beliebigen lokalen TCP-Port bereit, z. B. 49090, und verbinden Sie eine Shell mit diesem Port:
tunnel -l " /tmp/tunnel.log " -k " your secret " 49090 # Note the base64 node id emitted
socat TCP-LISTEN:49090,reuseaddr,fork SYSTEM: ' bash 2>&1 'Zurück bei Ihnen zu Hause:
tunnel -l " /dev/null " -b 5000 -k " your secret " " node_id_of_workplace:49090 "
rlwrap nc localhost 5000Die Verwendung von rlwrap ist keine Notwendigkeit. Aber es macht das Erlebnis auf jeden Fall angenehmer, da es GNU Readline verwendet und sich den Eingabeverlauf merkt (aufrufbar mit den Auf-/Ab-Pfeiltasten, ähnlich wie bei Ihren lokalen Bash-Sitzungen).
Redis :
Müssen Sie eine Verbindung zu einer Remote-Redis-Instanz herstellen, die von einem Peer oder Ihnen selbst gehostet wird? Stellen Sie auf dem Remote-Host den TCP-Port bereit, auf dem redis-server ausgeführt wird (Standard: 6379), mit tunnel .
Verwenden Sie auf Ihrem lokalen Computer tunnel um einen TCP-Port an den Remote-Port weiterzuleiten. Richten Sie Ihr redis-cli auf den weitergeleiteten lokalen Port.
Nachfolgend sind einige zufällige Anwendungsfälle aufgeführt, die mir für tunnel einfallen könnten. Im Großen und Ganzen sollte alles, was NAT/Firewall-Durchquerung (z. B. WebRTC ohne TURN) oder den Beitritt zu einem Remote-LAN beinhaltet, als tunnel nützlich sein. Einige der folgenden Ideen sind eher skizzenhaft, wurden überhaupt nicht getestet und funktionieren möglicherweise nicht, werden aber dennoch hier dokumentiert, zumindest vorerst, nur der Inspiration halber. Wenn Sie eines davon nützlich oder nutzlos fanden oder völlig neue Anwendungen für tunnel entdeckt haben, posten Sie es bitte unter „Diskussionen“. Die Fälle, die ich getestet habe, sind als „funktionierend“ gekennzeichnet.
tunnel weitergeleitet wurde.tunnel bei Heroku aus (kostenlos) und leiten Sie den in der Umgebungsvariablen PORT gespeicherten Port an Ihren lokalen Port weiter, den Sie freigeben möchten. Und Sie haben Ihre öffentliche URL als: https://Ihr-App-Name.herokuapp.com.tunnel . tunnel verschlüsselt den gesamten Datenverkehr zwischen einem Peer und dem Relay mit TLS, wenn das Relay https verwendet. Zwischen den Peers untereinander gibt es per se keine Ende-zu-Ende-Verschlüsselung. Es wird jedoch behauptet, dass das Piping-Server-Relay speicherlos ist.
Ein Client-Peer kann nur dann eine Verbindung zu einem Serving-Peer herstellen, wenn dieser denselben geheimen Schlüssel (TUNNEL_KEY) verwendet. Der Schlüssel wird hauptsächlich für die Peer-Erkennung in der Relay-Phase verwendet. Bei jeder neuen Verbindung zum weitergeleiteten lokalen Port sendet der Client einen zufälligen Sitzungsschlüssel an den bedienenden Peer. Anschließend stellen die Peers auf Grundlage dieses Zufallsschlüssels eine neue Verbindung an einem anderen Relay-Punkt her, damit die eigentliche Datenübertragung stattfinden kann. Außenseiter, nämlich. Bösewichte, die den TUNNEL_KEY nicht kennen, sollten diesen Fluss nicht stören können.
Ein böswilliger Peer kann jedoch Folgendes tun. Da er den TUNNEL_KEY und die Knoten-ID des bedienenden Peers kennt, kann er sich als letzterer ausgeben. Daten von einem ahnungslosen Verbindungspartner würden daher an den Imitator weitergeleitet, wodurch der echte Server ausgehungert würde. Zukünftige Updates/Implementierungen von tunnel sollten diese Bedrohung mithilfe von Krypto mit öffentlichem Schlüssel bewältigen. [In diesem Fall wäre der zufällige Sitzungsschlüssel, der für jede neue weiterzuleitende Verbindung generiert wird, allein vom echten Server entschlüsselbar.]
Da tunnel im Wesentlichen die Transportschicht darstellen, sollten die oben genannten Punkte nicht entmutigend sein, da die meisten Anwendungen wie SSH und IPFS Daten auf der Anwendungsschicht verschlüsseln. Eine Ende-zu-Ende-Verschlüsselung tunnel für alle Datenübertragungen würde die Latenz nur erhöhen. Sie können jedoch jederzeit einen SSH-Tunnel erstellen, nachdem Sie das Low-Level-Peering mit tunnel eingerichtet haben, wenn Sie dies wünschen.
Das vom tunnel verwendete Standard-Relay ist https://ppng.io. Sie können auch ein anderes öffentliches Relay aus dieser Liste verwenden oder Ihre eigene Instanz bei kostenlosen Diensten hosten, wie sie beispielsweise von Heroku angeboten werden. Um eine Verbindung herzustellen, müssen zwei Peers natürlich dasselbe Relais verwenden.
Wenn Sie möchten, können Sie mit einfachen Tools wie Sertain auch Ihr eigenes Relais schreiben, das vom tunnel verwendet wird. Stellen Sie einfach sicher, dass Ihr Relay-Dienst über dieselbe API wie der Piping-Server verfügt. Wenn Ihr Relay-Code Open Source ist, können Sie ihn gerne bei Diskussionen vorstellen.
gsocket ; ipfs p2p mit aktiviertem Circuit-Relay; go-piping-duplex ; pipeto.me ; Uplink; localhost.run ; ngrok ; lokaler Tunnel; sshreach.me ( kostenlose Testversion nur für begrenzten Zeitraum ); mehr
Hinweise:
tunnel und Piping-Server können Sie jedoch einfach Ihre eigene Relay-Instanz bereitstellen, deren öffentliche URL ein für alle Mal mit Ihren Kollegen teilen, dasselbe wie TUNNEL_RELAY in .bashrc export und schon kann es losgehen. Zur Redundanz stehen außerdem mehrere öffentliche Piping-Server zur Verfügung.IPFS (Fertig):
Die Verbindung zu IPFS wäre viel einfacher:
tunnel -k <secret> ipfs zum Offenlegen und tunnel -k <secret> <IPFS_peerID> zum Herstellen einer Verbindung.
Diese starten den IPFS-Daemon selbstständig, wenn sie offline sind. Der letztere Befehl stellt in Abständen von 30 Sekunden wiederholt eine Schwarmverbindung zum angegebenen Peer her. Die IPFS-Peer-ID wird als Knoten-ID verwendet, sodass Peers ihre Knoten-IDs nicht mehr separat teilen müssen. Nicht standardmäßige IPFS-Repo-Pfade können mit der Option -r übergeben werden. oder IPFS_PATH .
SSH:
Das Erstellen eines SSH-Tunnels zwischen dem lokalen und dem Peer-Port wäre so einfach wie:
tunnel -k <secret> ssh zum Offenlegen von &
tunnel -sk <secret> -b <local-port> <peerID>:<peer-port> zum Erstellen.
Beachten Sie, dass beim Herstellen einer Verbindung kein Anmeldename mehr angegeben werden muss. Standardmäßig wird der ${USER} des bedienenden Knotens als Anmeldename verwendet. Bei Bedarf kann jedoch jederzeit ein nicht standardmäßiger Anmeldename mithilfe einer Umgebungsvariablen oder -option übergeben werden.
GPG:
Virtuelle Maschinen, wie sie beispielsweise von Cloud-Shells und Dynos verwendet werden, verfügen nicht über dauerhafte, eindeutige Hardwareadressen. Die Node-ID ändert sich daher für eine solche VM von Sitzung zu Sitzung ständig. Zukünftige tunnel hätten eine -g Option, die einen privaten GPG-Schlüssel an tunnel übergeben würde. Die Knoten-ID würde aus dem Fingerabdruck dieses Schlüssels generiert, ähnlich wie IPFS. Dies würde auch tunnel sicherer machen.
Argon2:
Option [ -a ], um argon2 für das Hashing von TUNNEL_KEY vor der Verwendung zu verwenden, damit ein schwächeres Geheimnis nicht zu anfällig ist.
Bitte melden Sie Fehler bei Problemen. Veröffentlichen Sie Ihre Gedanken, Kommentare, Ideen, Anwendungsfälle und Funktionswünsche in der Diskussion. Lassen Sie mich wissen, wie Ihnen das geholfen hat, wenn es überhaupt geholfen hat.
Sie können mir auch gerne direkt über alles, was dieses Projekt betrifft, schreiben.
Wenn Ihnen dieses kleine Drehbuch von Nutzen ist, wäre ein Stern für mich eine große Ermutigung.
Danke ! ?
