et il se trouve que les NAT dit "symétriques" sont infranchissables sans avoir un relai extérieur
Ce n'est pas qu'ils sont réellement infranchissables, c'est que le couple (IP, port) public change pour chaque pair contacté en UDP. Donc il est impossible pour un noeud (terminologie P2P) présent derrière un NAT symétrique de renseigner a priori ses pairs sur la façon de le contacter. S'il était possible pour ce noeud d'interroger le NAT pour déterminer à l'avance le couple (IP, port) public d'un futur mapping, le problème serait résolu. Si je ne me trompe, c'est à quoi sert la norme uPNP créée/soutenue par Microsoft.
Par ailleurs il faut savoir que la majorité des équipements utilisés par les particuliers (machin-box et compagnie) ne sont pas de type "NAT symétrique" mais "full cone" ou "restricted cone". C'est-à-dire que le couple (IP, port) public en UDP ne dépend que du couple (IP, port) privé correspondant et non du pair avec lequel on échange des messages. Dans ce cas on peut communiquer le couple (IP, port) à ses pairs après l'avoir déterminé grâce à un serveur fixe prédéfini.
Un problème plus coriace se pose quand le noeud se trouve derrière plusieurs NATs en cascade (c'est le cas si on utilise un modem-routeur personnel derrière un FAI qui attribue des IP privées à ses abonnés... il paraît que c'est le cas dans certains pays d'Asie).
[^] # Re: Video sous Linux dans Skype
Posté par Antoine . En réponse à la dépêche Polices STIX, sources de Multics et Skype ajoute la vidéo sous Linux. Évalué à 4.
Ce n'est pas qu'ils sont réellement infranchissables, c'est que le couple (IP, port) public change pour chaque pair contacté en UDP. Donc il est impossible pour un noeud (terminologie P2P) présent derrière un NAT symétrique de renseigner a priori ses pairs sur la façon de le contacter. S'il était possible pour ce noeud d'interroger le NAT pour déterminer à l'avance le couple (IP, port) public d'un futur mapping, le problème serait résolu. Si je ne me trompe, c'est à quoi sert la norme uPNP créée/soutenue par Microsoft.
Par ailleurs il faut savoir que la majorité des équipements utilisés par les particuliers (machin-box et compagnie) ne sont pas de type "NAT symétrique" mais "full cone" ou "restricted cone". C'est-à-dire que le couple (IP, port) public en UDP ne dépend que du couple (IP, port) privé correspondant et non du pair avec lequel on échange des messages. Dans ce cas on peut communiquer le couple (IP, port) à ses pairs après l'avoir déterminé grâce à un serveur fixe prédéfini.
Un problème plus coriace se pose quand le noeud se trouve derrière plusieurs NATs en cascade (c'est le cas si on utilise un modem-routeur personnel derrière un FAI qui attribue des IP privées à ses abonnés... il paraît que c'est le cas dans certains pays d'Asie).