Perforation symétrique NAT et UDP


8

J'ai lu cette question , mais l'explication du NAT symétrique n'était pas suffisamment détaillée.

S'il vous plaît quelqu'un pourrait-il m'aider à comprendre les paragraphes suivants?

J'ai lu ceci sur NAT symétrique :

Chaque requête provenant de la même adresse IP et du même port internes vers une adresse IP et un port de destination spécifiques est mappée vers une adresse IP et un port source externes uniques, si le même hôte interne envoie un paquet même avec la même adresse source et le même port mais vers un autre destination, un mappage différent est utilisé. Seul un hôte externe qui reçoit un paquet d'un hôte interne peut renvoyer un paquet.

http://en.wikipedia.org/wiki/Network_address_translation#Types_of_NAT

Et à propos de la perforation UDP :

La perforation UDP ne fonctionnera pas avec les périphériques NAT symétriques (également appelés NAT bidirectionnels) qui ont tendance à être trouvés dans les grands réseaux d'entreprise. Dans le NAT symétrique, le mappage du NAT associé à la connexion au serveur STUN bien connu est limité à la réception de données du serveur bien connu, et donc le mappage NAT que le serveur bien connu voit n'est pas une information utile pour le point de terminaison.

http://en.wikipedia.org/wiki/UDP_hole_punching

Mais je ne l'absorbe pas vraiment. J'ai l'impression que cela me dit que (dans une application client-serveur où le client initie la communication), un serveur ne peut pas communiquer dans l'autre sens, sauf s'il est explicitement autorisé par le périphérique NAT. Je ne comprends pas pourquoi c'est ce qu'il dit. Si c'est possible, pourriez-vous me simplifier légèrement cette description?

Nous avons un problème dans notre environnement où un outil d'assistance à distance bien connu ne peut pas être utilisé par un éditeur de logiciels également bien connu pour nous fournir une assistance. Le client est compatible proxy, mais pour certains utilisateurs, il pense que ce serait une bonne idée de ne pas l'utiliser et de faire quelque chose de complètement différent via UDP sur le port 1153.


1
Avant de répondre, voulez-vous simplement savoir pourquoi la perforation UDP ne fonctionne pas avec le NAT symétrique ou posez-vous des questions sur votre problème particulier? Parce que votre problème ne semble pas nécessairement lié à l'un ou l'autre, je suis donc curieux.
TheCleaner

OK, peut-être pourriez-vous expliquer les deux? Je veux dire, pourquoi cela ne fonctionne pas et pourquoi mon problème ne semble pas lié.
john

Commençons par une salle de chat si vous voulez en créer une ... J'ai un peu de temps et ça pourrait être plus facile. Je vais couper / coller mon explication à partir de là comme réponse ici plus tard.
TheCleaner

Réponses:


6

De notre chat ... afin que d'autres ne puissent pas avoir la conversation complète, mais les bases sont ici.

NAT de base = source address:port >> external address:port >> NAT>> new source address:port >> external address port

avec NAT symétrique c'est un mappage statique et le même à chaque fois et pour la source ET la destination.

Exemple: 192.168.100.5:34983 going to 4.2.2.2:53 then REQUIRE it to be 216.222.222.222:44444 with destination 8.8.8.8:333333

"dans une application client-serveur où le client initie la communication), un serveur ne pouvait pas communiquer dans l'autre sens, sauf s'il était explicitement autorisé par le périphérique NAT."

cette partie que vous dites incorrecte devrait se lire:

dans une application client-serveur où le client initie la communication), un serveur PEUT communiquer en sens inverse APRÈS que la source établisse la session SUR les ports utilisés dans la session.

Cela signifie que si 2.2.2.2:43424 passe à 5.5.5.5:80, puis 5.5.5.5:80 renvoie les informations à 2.2.2.2:43424 une fois la session établie. Dans votre phrase ... la session ne serait jamais que la source communiquant à destination avec destination ne répondant jamais avec des paquets / info / graphiques / quoi que ce soit.

"Nous avons un problème dans notre environnement où un outil de support à distance bien connu ne peut pas être utilisé par un éditeur de logiciels tout aussi connu pour nous fournir une assistance. Le client est sensible au proxy, mais pour certains, il pense qu'il pourrait être un bonne idée de ne pas l'utiliser et de faire quelque chose de complètement différent via UDP sur le port 1153. "

Cela pourrait être dû au fait qu'ils bloquent simplement Logmein / Teamviewer / quoi que ce soit au niveau du port car ils demandent à utiliser un port différent ... alors ils pensent que si vous autorisez ou communiquez sur 1153, cela contournera leurs propres restrictions informatiques ... Je peux penser sans savoir en détail quelle application ou tous les détails. Rien à voir avec la perforation symétrique NAT ou UDP vraiment ... du moins en ce qui concerne le problème qu'ils soulèvent.

Je recommanderais de discuter avec leur équipe d'assistance de l'outil de support à distance avec lequel ils travaillent OU de travailler avec eux pour déterminer une façon d'utiliser l'outil que vous aimez. Si cela signifie certains NAT / règles de port, vous devrez travailler avec eux et votre équipe de mise en réseau pour comprendre cette partie.

J'espère que tout aide.


L'outil d'assistance à distance est Log Me In et est utilisé par quelques-uns de nos fournisseurs tiers pour l'assistance. Nous avons autorisé le trafic sur le pare-feu de notre entreprise et avons pu voir le trafic passer par le pare-feu. Mais rien n'est revenu. C'est presque comme s'il n'y avait aucun moyen de revenir à travers le pare-feu, ou le serveur distant n'a pas pu déterminer où envoyer la communication de retour.
john

Nous avons également des procurations, il est donc possible que celles-ci interfèrent d'une manière ou d'une autre.
john

Si vous avez une «stratégie d'autorisation» sortante, cela devrait fonctionner si votre côté initie le trafic et que le trafic atteint la partie distante avec les bonnes informations NAT. Voir ici aussi: help.logmein.com/… mais vous pourriez avoir besoin de conseil ou de plus d'expertise sur place pour éliminer cela ...
TheCleaner

4

entrez la description de l'image ici

entrez la description de l'image ici

Regardez ces photos prises à partir de la page Wikipedia "Traduction d'adresse réseau".

Dans "Full Cone NAT"

  1. Une fois qu'une adresse interne (iAddr: iPort) est mappée à une adresse externe (eAddr: ePort), tous les paquets provenant d'iAddr: iPort sont envoyés via eAddr: ePort.
  2. Tout hôte externe peut envoyer des paquets à iAddr: iPort en envoyant des paquets à eAddr: ePort.

En NAT symétrique

  1. Chaque demande provenant de la même adresse IP interne et du même port vers une adresse IP et un port de destination spécifiques est mappée sur une adresse IP et un port source externes uniques; si le même hôte interne envoie un paquet même avec la même adresse source et le même port mais vers une destination différente, un mappage différent est utilisé.
  2. Seul un hôte externe qui reçoit un paquet d'un hôte interne peut renvoyer un paquet.

Voyons maintenant pourquoi la perforation UDP ne peut pas fonctionner en NAT symétrique. Disons que Server1 est un serveur STUN et que le serveur 2 est un périphérique NAT d'un réseau privé différent. Dans la perforation UDP, le client se connecte à Server1 et le mappage de port est créé sur le périphérique NAT. Mais lorsque ce client se connecte à l'hôte derrière Server2, le périphérique NAT crée un autre mappage de port comme indiqué dans l'image 2. Server1 partage le mappage de port client avec l'hôte derrière Server2 et avec ce mappage de port, Server2 ne peut pas établir de connexion et Server2 n'est pas au courant du second mappage de port créé par le périphérique NAT.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.