Perforation symétrique NAT et UDP

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.

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.

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.