tunnel
1.0.0
Redirection de port TCP/UDP sécurisé et multiplexé utilisant le serveur de tuyauterie de @nwtgck comme relais. Conçu principalement pour les connexions p2p entre pairs derrière (plusieurs) NAT/pare-feu.
Pour le cas particulier de IPFS , voir #examples ci-dessous.
ID : chaque nœud reçoit un identifiant unique (base64) -
tunnel -iL'ID est lié au matériel (adresse MAC) et aux variables d'environnement USER, HOME et HOSTNAME. Partagez-le avec vos pairs une fois pour toutes. Remarque : deux utilisateurs sur la même machine reçoivent des ID de nœud distincts car leurs variables USER et HOME diffèrent.
Mode serveur : exposez votre port local aux pairs avec lesquels vous partagez une chaîne secrète -
tunnel [options] [-u] [-k < shared-secret > ] < local-port >Mode client : transférez votre port local vers le port local exposé du homologue -
tunnel [options] [-u] [-k < shared-secret > ] [-b < local-port > ] [-I < IP > ] < peer-ID:peer-port > Si aucun port local n'est fourni à l'aide de l'option -b , tunnel utilise un port aléatoire inutilisé. Le port utilisé est toujours signalé sur la sortie standard.
L'option -I est pratique lorsque le client s'exécute sur un ordinateur portable qui se connecte occasionnellement au réseau local sur lequel se trouve le serveur. Lorsque le serveur peut être trouvé sur le réseau local avec une adresse IP privée = <IP> , tunnel se connecte via le réseau local.
Le client et le serveur doivent utiliser le même secret pour pouvoir se connecter. La chaîne secrète peut également être transmise à l'aide de la variable d'environnement TUNNEL_KEY . Le secret transmis avec -k est prioritaire.
L'indicateur -u indique l'utilisation d'UDP au lieu du TCP par défaut. S'il est utilisé, il doit être utilisé par les deux pairs.
Tous les journaux sont à stderr par défaut. Avec l'option -l <logfile> , cependant, on peut lancer tunnel en arrière-plan ( mode démon ) avec les journaux vidés sur <logfile> . L'ID du processus démon est montré à l'utilisateur lors du lancement afin qu'il puisse tuer le démon à tout moment avec
tunnel -K < procID >Possibilités :
Pour une liste complète des options, voir : tunnel -h
Téléchargez avec :
curl -LO https://raw.githubusercontent.com/SomajitDey/tunnel/main/tunnelRendez-le exécutable :
chmod +rx ./tunnelEnsuite, installez à l'échelle du système avec :
./tunnel -c install Si vous ne disposez pas du privilège sudo , vous pouvez installer localement :
./tunnel -c install -lPour mettre à jour à tout moment après l'installation :
tunnel -c update Ce programme est simplement un script bash exécutable dépendant des outils GNU standard, notamment socat , openssl , curl , mktemp , cut , awk , sed , flock , pkill , dd , xxd , base64 etc. qui sont facilement disponibles sur les distributions Linux standard.
Si votre système ne dispose pas de l'un de ces outils et que vous ne disposez pas du privilège sudo requis pour l'installer à partir du référentiel de packages natif (par exemple sudo apt-get install <package> ), essayez de télécharger un binaire portable et installez-le localement sur ${HOME}/.bin .
SSH :
Le homologue A expose le port SSH local -
tunnel -k " ${secret} " 22Le homologue B se connecte -
tunnel -b 67868 -k " ${secret} " -l /dev/null " ${peerA_ID} :22 " # Daemon due to -l
ssh -l " ${login_name} " -p 67868 localhost IPFS :
Laissez le homologue A avoir IPFS-peer-ID : 12orQmAlphanumeric . Son démon IPFS écoute sur le port TCP 4001 par défaut. Elle l'expose avec -
tunnel -k " ${swarm_key} " ipfs swarm_key est n'importe quelle chaîne secrète que le homologue A peut utiliser pour contrôler qui peut se connecter à elle en utilisant tunnel .
Le homologue B se connecte désormais au homologue A pour le partage de fichiers ou pubsub ou p2p -
tunnel -k " ${swarm_key} " 12orQmAlphanumericCe dernier essaim de commandes se connecte au homologue A via le relais du serveur de tuyauterie et continue de se connecter en essaim toutes les quelques secondes en arrière-plan pour maintenir la connexion active.
tunnel démarre le démon IPFS en arrière-plan s'il n'est pas déjà actif.
Le chemin d'accès au référentiel IPFS peut être transmis avec l'option -r . Sinon, la variable d'environnement IPFS_PATH ou le chemin par défaut ~/.ipfs est utilisé comme d'habitude. Exemple : tunnel -r ~/.ipfs -i donne l'ID du homologue IPFS.
Coque distante :
Supposons que vous ayez régulièrement besoin de lancer des commandes sur votre machine Linux de travail à partir de votre ordinateur personnel. Et vous ne voulez/ne pouvez pas utiliser SSH sur tunnel pour une raison quelconque.
Sur l'ordinateur du lieu de travail, exposez un port TCP local aléatoire, par exemple 49090, et connectez un shell à ce 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 'De retour à votre domicile :
tunnel -l " /dev/null " -b 5000 -k " your secret " " node_id_of_workplace:49090 "
rlwrap nc localhost 5000Utiliser rlwrap n'est pas une nécessité. Mais cela rend certainement l'expérience plus douce car il utilise GNU Readline et mémorise l'historique des entrées (accessible avec les touches fléchées haut/bas similaires à vos sessions bash locales).
Rédis :
Besoin de vous connecter à une instance Redis distante hébergée par un homologue ou par vous-même ? Sur l'hôte distant, exposez le port TCP sur lequel redis-server s'exécute (par défaut : 6379), avec tunnel .
Sur votre ordinateur local, utilisez tunnel pour transférer un port TCP vers le port distant. Pointez votre redis-cli vers le port local transféré.
Vous trouverez ci-dessous quelques cas d'utilisation aléatoires auxquels je pourrais penser pour tunnel . D'une manière générale, tout ce qui implique une traversée NAT/pare-feu (par exemple WebRTC sans TURN) ou la connexion à un réseau local distant devrait trouver tunnel utile. Certaines des idées suivantes sont plutôt sommaires, n'ont pas été testées du tout et peuvent ne pas fonctionner, mais sont néanmoins documentées ici, du moins pour le moment, juste à titre d'inspiration. Si vous avez trouvé l'un de ces éléments utiles ou inutiles, ou si vous avez trouvé des applications entièrement nouvelles pour tunnel , veuillez le publier lors des discussions. Les cas que j'ai testés sont étiquetés comme « fonctionnels ».
tunnel .tunnel sur Heroku (gratuitement) et transférez le port stocké dans la variable d'environnement PORT vers votre port local que vous souhaitez exposer. Et votre URL publique est la suivante : https://your-app-name.herokuapp.com.tunnel . tunnel chiffre tout le trafic entre un homologue et le relais avec TLS, si le relais utilise https. Il n’existe pas de chiffrement de bout en bout en soi entre les pairs eux-mêmes. Cependant, le relais du serveur de tuyauterie serait sans stockage .
Un homologue client peut se connecter à un homologue serveur uniquement s'il utilise la même clé secrète (TUNNEL_KEY). La clé est principalement utilisée pour la découverte d’homologues au stade du relais. Pour chaque nouvelle connexion au port local transféré, le client envoie une clé de session aléatoire au homologue serveur. Les homologues forment ensuite une nouvelle connexion à un autre point relais sur la base de cette clé aléatoire pour que le transfert de données proprement dit se produise. Les étrangers, à savoir. les mauvais acteurs qui ne connaissent pas TUNNEL_KEY ne devraient pas pouvoir perturber ce flux.
Cependant, un homologue malveillant peut effectuer les opérations suivantes. Parce qu'il connaît le TUNNEL_KEY et l'ID de nœud du homologue serveur, il peut usurper l'identité de ce dernier. Les données provenant d’un homologue se connectant sans méfiance seraient donc transmises à l’imitateur, affamant ainsi le véritable serveur. Les futures mises à jour/implémentations du tunnel devraient gérer cette menace en utilisant le chiffrement à clé publique. [Dans ce cas, la clé de session aléatoire générée pour chaque nouvelle connexion à transférer serait déchiffrable par le seul serveur authentique].
Étant donné que tunnel est essentiellement la couche de transport, les points ci-dessus ne devraient pas être décourageants, car la plupart des applications telles que SSH et IPFS chiffrent les données au niveau de la couche application. Le chiffrement tunnel de bout en bout pour tous les transferts de données ne ferait qu’ajouter à la latence. Cependant, vous pouvez toujours créer un tunnel SSH après avoir établi le peering de bas niveau avec tunnel , si vous le souhaitez.
Le relais par défaut utilisé par tunnel est https://ppng.io. Vous pouvez également utiliser un autre relais public de cette liste ou héberger votre propre instance sur des services gratuits tels que ceux proposés par Heroku. Inutile de préciser que pour se connecter, deux pairs doivent utiliser le même relais.
Si vous le souhaitez, vous pouvez également écrire votre propre relais à utiliser par tunnel à l'aide d'outils simples comme Sertain. Assurez-vous simplement que votre service de relais dispose de la même API que le serveur de tuyauterie. Si votre code de relais est open source, vous êtes invités à le présenter lors des discussions.
gsocket ; ipfs p2p avec circuit-relais activé ; aller-tuyauterie-duplex ; pipeto.me ; liaison montante ; localhost.run ; ngrok ; tunnel local ; sshreach.me ( essai gratuit pour une durée limitée uniquement ) ; plus
Remarques :
tunnel et piping-server, cependant, vous pouvez simplement déployer votre propre instance de relais, partager une fois pour toutes son URL publique avec vos pairs, export la même chose que TUNNEL_RELAY dans .bashrc et vous êtes prêt à partir. En outre, plusieurs serveurs de tuyauterie publics sont disponibles pour la redondance.IPFS (Terminé) :
La connexion à IPFS serait beaucoup plus simple :
tunnel -k <secret> ipfs pour exposer et tunnel -k <secret> <IPFS_peerID> pour se connecter.
Ceux-ci lanceront le démon IPFS d'eux-mêmes, s'ils sont hors ligne. Cette dernière commande se connectera à plusieurs reprises au homologue donné à des intervalles de 30 secondes. L'IPFS-peer-ID sera utilisé comme ID de nœud, de sorte que les pairs n'auront plus besoin de partager leurs ID de nœud séparément. Les chemins de dépôt IPFS autres que ceux par défaut peuvent être transmis avec l'option -r . ou IPFS_PATH .
SSH :
Créer un tunnel SSH entre le port local et le port homologue serait aussi simple que :
tunnel -k <secret> ssh pour exposer &
tunnel -sk <secret> -b <local-port> <peerID>:<peer-port> à créer.
Notez que lors de la connexion, il n’est plus nécessaire de fournir un nom de connexion. Le ${USER} du nœud de desserte est pris comme nom de connexion par défaut. Cependant, si nécessaire, un nom de connexion autre que celui par défaut peut toujours être transmis à l'aide d'une variable ou d'une option d'environnement.
GPG :
Les machines virtuelles, telles que celles utilisées par les cloud-shells et les dynos, n'ont pas d'adresses matérielles persistantes et uniques. L'ID du nœud ne cesse donc de changer de session en session pour une telle VM. Le futur tunnel aurait une option -g qui transmettrait une clé privée GPG au tunnel . L'ID du nœud serait généré à partir de l'empreinte digitale de cette clé, comme le fait IPFS. Cela rendrait également tunnel plus sécurisé.
Argon2 :
Option [ -a ] pour utiliser argon2 pour hacher TUNNEL_KEY avant utilisation, afin qu'un secret plus faible ne soit pas trop vulnérable.
Veuillez signaler les bogues lors des problèmes. Publiez vos réflexions, commentaires, idées, cas d'utilisation et demandes de fonctionnalités lors de la discussion. Faites-moi savoir comment cela vous a aidé, si cela vous a aidé.
N'hésitez pas également à m'écrire directement pour tout ce qui concerne ce projet.
Si ce petit scénario vous est utile, une étoile me serait extrêmement encourageante.
Merci ! ?
