Comment se connecter directement aux appareils derrière NAT depuis Internet?
Nous avons une adresse IP sur Internet mondial: "A"
Nous n'avons accès qu'à "A".
Nous avons un réseau derrière un routeur qui fait NAT: 192.168.1.0/24
Il y a un client derrière ce NAT: "B"
Nous n'avons pas accès à "B" et au routeur "NAT".
Objectif: atteindre le "B" directement avec "A".
Nous ne pouvons pas utiliser la redirection de port ou UPnP, etc.
Question: quelle est l'astuce pour atteindre "B"? Une astuce qui pourrait être évitée si le routeur avait un pare-feu dynamique, pas seulement NAT!
Nous pensons que lorsque "B" naviguera sur le Web, il ira sur Internet. Lorsqu'il reçoit des réponses, le routeur qui fait le NAT a besoin de décider quelle IP NAT possède "B"? (il pourrait y avoir plus de machines derrière le réseau NAT). Pour cela, le routeur NAT utilise également les informations de port. Peut-être que si nous/ils utilisent UDP, nous pouvons essayer tous les ports non privilégiés avec l'IP "A" pour envoyer un paquet à "B"?
Le routeur NAT n'est qu'un simple routeur soho. (problème d'origine: essayer de prouver que NAT n'est pas un pare-feu, mais nous avons besoin d'une preuve pour cela)
Dans une réponse simple (si je comprends bien), oui. Vous pouvez accomplir cela en utilisant le tunneling SSH inverse.
Vous devrez configurer le tunnel sur "B" en utilisant d'abord le proxy de chaussettes (peut être fait via PuTTY), puis vous devrez acheminer votre trafic via "A" pour les demandes.
Lorsque les réponses reviendront, elles seront dirigées vers "A", puis vers "B"; atteignant essentiellement "B directement avec A".
Voici quelques ressources supplémentaires pour y parvenir: http://www.thegeekstuff.com/2013/11/reverse-ssh-tunnelhttps://unix.stackexchange.com/questions/46235/how-does-reverse-ssh-tunneling-work
En fait, votre plan pourrait fonctionner, selon le fonctionnement de l'appareil NAT.
En règle générale, les périphériques NAT mappent l'IP interne et le port source à l'IP et au port de destination afin qu'il ne permette à cette IP et à ce port de communiquer qu'avec l'IP interne. Cela fait NAT un pare-feu avec état très grossier et pauvre.
Mais cette fonction n'est pas une partie obligatoire du NAT, ce qui signifie que tout fournisseur peut choisir de mettre en œuvre cette approche, ou non.
Cela signifie qu'il est théoriquement possible de pouvoir scanner les ports d'un appareil NAT et découvrir le réseau interne si les périphériques du réseau interne répondent aux tentatives de connexion . C'est une grande série de "si". Mais cela en vaut la peine.
Donc, oui, NAT seul est insuffisant, car vous ne savez pas comment NAT a été implémenté. Un pare-feu avec état fournit une défense- en profondeur pour couvrir ce trou inconnu potentiel. NAT n'est pas une technologie de sécurité et ne doit pas être traité comme un mécanisme de protection.
vous pouvez utiliser AnyDesk (version 5.2+) qui vous permet de configurer la connexion TCP entre les clients).
Je l'ai utilisé pour connecter mon PC client à un Team Foundation Server (TFS) via Internet. Le serveur et le client sont derrière NAT. J'ai défini les ports locaux et distants sur '8080' et je peux me connecter au serveur à partir du client en utilisant cette adresse sur le client: ' http: // localhost: 8080/tfs / '
Référence: TCP-Tunneling-AnyDesk