Comment utiliser le poinçonnage UDP pour un tunnel / session SSH

Je souhaite déployer un Raspberry Pi dans mon chalet de week-end. Le Raspberry Pi est là pour enregistrer les températures et les envoyer à un serveur distant qui a un IP fixe, enregistre les données et l'affiche sur un site Web simple.

Cependant, il se peut que la situation me permette de changer quelque chose sur le Raspberry Pi. Par exemple, les mises à jour du système ou une modification du programme qui envoie les données au serveur ou autre.

Avec la configuration proposée, je ne pourrai pas me connecter au Raspberry Pi de l'extérieur de son LAN.

REMARQUE: je ne veux pas changer le réseau, et le routeur existant n'a pas la capacité de renvoi de port, dynDNS ou VPN.

J'ai récemment lu les perforations UDP. L'idée de base est que le client envoie un paquet UDP à une adresse de serveur connue (c'est-à-dire avec un IP public ou dynDNS activé). Le client B qui voudrait se connecter au client A demande au serveur le numéro public et le numéro de port du client A.

Il peut ensuite se connecter au client A directement sur son IP public et son port qui est dynamique. Parce que le client A est d'abord connecté au serveur sur le port maintenant utilisé, le NAT transmettra les paquets au client A.

J'espère que j'ai résumé l'idée correctement, plus ou moins …

Tout cela semble bien, mais le problème est que ce n'est pas nécessaire de travailler avec une connexion TCP, car le routeur est capable de "comprendre" la prise de contact de la connexion TCP et s'il n'est pas correctement configuré, il ne reviendra pas Les paquets.

Alors, comment puis-je ouvrir une session SSH du client B au client A, sans le client A assis derrière un routeur avec dynDNS, une IP publique fixe ou la possibilité de renvoi de port? L'utilisation d'un serveur central avec un public, une solution d'IP ou un nom de domaine pourrait être difficile.

pwnat


"… il n'est pas trivial de lancer une connexion à un pair derrière NAT " .

"… presque toutes les implémentations NAT refusent de transmettre le trafic entrant qui ne correspond pas à une demande sortante récente. "


"… pwnat outil pwnat est une implémentation autonome GNU / Linux, autonome, de la traversée NAT autonome. Après avoir contacté le serveur derrière le NAT, il établit un canal avec une sémantique TCP, utilisant des paquets UDP. Il prend en charge le client et le serveur derrière NAT (si l'un des NAT permet de transmettre les faux messages [personnalisés] ICMP ). Cette implémentation vise les utilisateurs finaux. "


  
 Utilisation: ./pwnat <-s |  -c> <args>

   -c mode client
     <Args>: [local ip] <port local> <hôte proxy> [port proxy (def: 2222)] <hôte distant> <port distant>

   -s mode serveur
     <Args>: [local ip] [port proxy (def: 2222)] [[hôte autorisé]: [port autorisé] ...]

   -6 utilise IPv6  
   -v afficher la sortie de débogage (jusqu'à 2)  
   -h montrer l'aide et sortir  

 Exemples:  

     Côté serveur permettant à quiconque de proxy:
       ./pwnat -s

     Client désireux de se connecter à google.com:80:
       ./pwnat -c 8000 <pwnat.server.com> google.com 80
     Ensuite, accédez à http: // localhost: 8000 pour visiter le google!  


Pwnat; Diagramme de flux de signal de réseau


"L'idée clé pour permettre au serveur d' apprendre l'adresse IP du client consiste à envoyer périodiquement un message à une adresse IP fixe et connue. L'approche la plus simple utilise les messages ICMP ECHO REQUEST vers une adresse IP non allouée, telle que 1.2.3.4 . Puisque 1.2.3.4 n'est pas attribué, la DEMANDE ICMP ne sera pas acheminée par des routeurs sans itinéraire par défaut. "

"À la suite des messages envoyés au 1.2.3.4, le NAT permettra le routage des réponses, en réponse à cette demande. Le client de connexion sera alors faussement une telle réponse. Plus précisément, le client transmettra un message ICMP indiquant TTL_EXPIRED . Un message pourrait légitimement être transmis par un routeur Internet et l'adresse de l'expéditeur ne devrait pas correspondre à l'IP cible du serveur. "

" Le serveur écoute les réponses (fausses) ICMP et, lors de la réception, lance une connexion à l'adresse IP de l'expéditeur spécifiée dans la réponse ICMP. Si le client utilise une adresse IP globalement routable, ceci n'est pas problématique et TCP et UDP peuvent être utilisés Pour établir une connexion bidirectionnelle si le client écoute un port pré-convenu. "

"(Dans les cas où il n'y a pas de port pré-convenu, un numéro de port peut dans la plupart des cas être communiqué dans le cadre de la charge utile de la réponse ICMP ECHO)".


Source: http://samy.pl/pwnat.pdf
https://github.com/samyk/pwnat

Voici quelques solutions:

Vous pouvez configurer votre Raspberry Pi pour vous connecter à un serveur OpenVPN et vous pourrez y accéder en permanence.

Vous pouvez jeter un oeil à PageKite. Vérifiez https://pagekite.net/wiki/Howto/SshOverPageKite/

C'est une solution plutôt sale mais simple, mais qu'en est-il de l'utilisation de netcat? Sur le Raspberry Pi, vous pouvez créer un script qui boucle la commande:

 nc <public_ip> <port1> | sh | nc <public_ip> <port2> 

Sur votre hôte local, faites:

 nc -l <port1> 

Et:

 nc -l <port2> 

Vous pourrez saisir une commande dans la première instance et voir la réponse dans la seconde.