Je veux 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 une adresse IP fixe, enregistre les données et les affiche sur un simple site Web.

Cependant, la situation peut survenir que je souhaite changer quelque chose sur le Raspberry Pi. Par exemple des mises à jour du système ou un changement sur le programme qui envoie les données au serveur ou autre.

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

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

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

Il peut ensuite se connecter au client A directement sur son IP publique et son port qui est dynamique. Étant donné que le client A s'est d'abord connecté au serveur sur le port maintenant utilisé, le NAT transmet les packages au client A.

J'espère avoir résumé l'idée plus ou moins correctement…

Tout cela semble agréable, mais le problème est que cela n'est pas garanti pour fonctionner avec une connexion TCP, car le routeur est capable de «comprendre» la prise de contact de la connexion TCP et si elle n'est pas établie correctement, elle ne sera pas transférée les colis.

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

pwnat

"..il n'est pas trivial d'établir une connexion avec un pair derrière NAT. "

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

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

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

  -c mode client
    <args>: [IP locale] <port local> <hôte proxy> [port proxy (par défaut: 2222)] <hôte distant> <port distant>

  -s mode serveur
    <args>: [IP locale] [port proxy (par défaut: 2222)] [[hôte autorisé]: [port autorisé] ...]

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

Exemples:  

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

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

« L'idée clé pour permettre au serveur d' apprendre l'adresse IP du client est pour le serveur d' envoyer périodiquement un message à un fixe, l' adresse IP connue. L'approche utilise le plus simple des messages ICMP ECHO REQUEST à une adresse IP non alloué, tels que 1.2.3.4 . Étant donné que 1.2.3.4 n'est pas alloué, la DEMANDE ICMP ne sera pas acheminée par les routeurs sans route 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 se connectant simulera alors une telle réponse. Plus précisément, le client transmettra un message ICMP indiquant TTL_EXPIRED. Une telle le message pourrait être légitimement transmis par n'importe quel routeur Internet et l'adresse de l'expéditeur ne devrait pas correspondre à l'adresse IP cible du serveur. "

" Le serveur écoute les (fausses) réponses ICMP et, à réception, établit une connexion avec l'adresse IP de l'expéditeur spécifiée dans la réponse ICMP. Si le client utilise une adresse IP routable globalement, cela ne pose aucun problème et TCP ou UDP peuvent être utilisés d'établir une connexion bidirectionnelle si le client écoute sur un port convenu à l'avance. "

"(Dans les cas où il n'y a pas de port convenu à l'avance, 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 RESPONSE)."

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

Voici quelques solutions:

Vous pouvez configurer votre Raspberry Pi pour vous reconnecter à un serveur OpenVPN et vous y aurez accès tout le temps.

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

C'est une solution un peu sale mais facile, 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 taper une commande dans la première instance et voir la réponse dans la seconde.