Comment utiliser la perforation UDP pour un tunnel / session SSH

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.

networking router ssh udp Christian
la source

Vous avez un appareil connecté à Internet qui est capable de perforer UDP mais pas TCP? Obtenez un meilleur appareil NAT.

cpt_fink

Je n'ai pas fait de ssh avec udp mais voici un lien dessus zarb.org/~gc/html/udp-in-ssh-tunneling.html

barlop

Je ne sais pas mais j'ai demandé à un gourou ssh, ils ont dit que ssh peut transmettre udp, mais seulement s'il agit comme un vpn, et qu'il y a un interrupteur pour cela, il a dit que c'était -wmais il a dit udp sur tcp (peut-être par ce qu'il inclut toute tentative de transfert d'udp avec ssh), implique des problèmes tels qu'une latence élevée et la retransmission de choses que vous ne voulez plus. Je suppose que c'est quand même une chose intéressante à essayer. Je vois ce vpn via ssh et -w mentionné ici aussi wiki.archlinux.org/index.php/VPN_over_SSH

barlop

Je suis curieux de savoir pourquoi vous ne voulez pas ouvrir un port entrant? - cela ne ressemble pas à un scénario qui nécessite une sécurité super impressionnante ... Alternativement, vous pouvez demander au client A de maintenir une connexion SSH sortante avec une liaison de port inverse à un serveur auquel le client B a accès. De cette façon, vous pouvez vous connecter via le serveur intermédiaire. Cependant, ces types d'arrangements sont susceptibles d'échouer et ne sont donc pas souhaitables étant donné l'accès physique limité pour le trier en cas de problème.

kabadisha

Réponses:

`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

voix
la source

pwnat est à peine fonctionnel, même pour les connexions localhost à localhost. Je peux envoyer et recevoir des paquets, mais pour établir des connexions robustes, ce n'est pas très utile.

Scott

@Scott Eh bien, c'est un hack intéressant, mais c'est vraiment juste une preuve de concept basée sur l'utilisation abusive et abusive de protocoles réseau comme ICMP. Je ne m'y fierais pas. Il est vieux et non entretenu et je ne recommanderais pas de l'utiliser. Je ne l'aurais même pas mentionné si la question ne stipulait pas spécifiquement l'holepunching UDP. Si vous voulez fiable, connectez un tunnel VPN.

voix

Je ne me plains pas, mais je pense que "cette solution n'est pas destinée à être utilisée dans un environnement de production" est une information utile pour quiconque vient ici à la recherche d'une solution potentiellement stable.

Scott

@Scott Ce n'est pas, pas pour une utilisation dans tel ou tel environnement. De nombreux produits propriétaires utilisent ces techniques. Quoi qu'il en soit, il y a suffisamment d'informations ici pour que les gens puissent prendre leurs propres décisions. Je ne le recommande pas. Mais j'utilise des tunnels VPN. D'un autre côté, certains réseaux filtrent le trafic VPN, vous devez donc prendre les choses au cas par cas. Avez-vous besoin d'aide pour passer par un routeur NAT?

voix

J'ai une solution actuellement utilisable utilisant des tunnels ssh inversés pour relier deux machines NAT. Cependant, cela nécessite une machine "intermédiaire" qui a une IP statique ou pour laquelle je peux configurer la redirection de port sur le routeur. Cela m'aurait permis de supprimer cet intermédiaire. Tant pis.

Scott

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/

Obay
la source

Comment est-ce lié à la "perforation UDP" ?

voix

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.