Introduction
Ce document décrit le besoin d'utilitaires de traversée de session pour les serveurs NAT (STUN), les types de configurations de traduction d'adresses de réseau (NAT) par rapport aux serveurs STUN, comment la NAT cause un problème dans cette configuration et la solution.
Informations générales
L'objectif principal des périphériques NAT est de permettre aux périphériques dotés d'adresses IP privées dans un réseau local (LAN) de communiquer avec des périphériques dans des espaces d'adressage publics, tels qu'Internet. Cependant, bien que les périphériques NAT soient censés permettre aux hôtes internes de se connecter à l'espace public, lorsqu'il s'agit d'applications point à point (P2P) telles que la VoIP, les jeux, WebRTC et le partage de fichiers, où les utilisateurs finaux doivent agir à la fois comme client et comme serveur pour maintenir une communication bidirectionnelle de bout en bout, la NAT rend difficile l'établissement de ces connexions UDP. Les techniques de traversée NAT sont généralement requises pour que ces applications fonctionnent.
Nécessité de la traversée NAT
Les communications vocales et vidéo en temps réel sur Internet sont courantes aujourd'hui avec plusieurs messageries instantanées (IM) populaires qui prennent en charge les appels VoIP. L'un des principaux obstacles à l'adoption initiale de la VoIP était le fait que la plupart des ordinateurs ou autres périphériques se trouvent derrière des pare-feu et utilisent des adresses IP privées. Plusieurs adresses privées (adresse IP et port) dans le réseau sont mappées à une adresse publique unique par un pare-feu avec NAT. Mais le périphérique final ne connaît pas son adresse publique et ne peut donc pas recevoir de trafic vocal de la partie distante sur l'adresse privée qu'il annonce dans sa communication VoIP.
Les processus UNSAF (Unilateral Self-Address Fixing) sont des processus par lesquels certains points d'extrémité d'origine tentent de déterminer ou de fixer l'adresse (et le port) par lesquels ils sont connus d'un autre point d'extrémité - par exemple, pour être en mesure d'utiliser des données d'adresse dans l'échange de protocole ou d'annoncer une adresse publique à partir de laquelle ils reçoivent des connexions.
Les connexions P2P en cours de discussion sont donc des processus UNSAF. Les applications P2P peuvent établir des sessions d'appairage et rester compatibles NAT lorsqu'elles utilisent un serveur de rendez-vous adressable publiquement à des fins d'enregistrement et de découverte d'homologue.
Utilitaires de traversée de session pour NAT
Conformément à la RFC 5389, STUN fournit un outil qui traite des NAT. Il permet à un point d'extrémité de déterminer l'adresse IP et le port attribués par un périphérique NAT qui correspondent à son adresse IP privée et à son port. Elle permet également à un point de terminaison de maintenir une liaison NAT active.
Types d'implémentations NAT
Il a été observé que le traitement NAT du protocole UDP varie selon les mises en oeuvre. Les quatre traitements observés dans les mises en oeuvre sont :
Full Cone : une NAT full cone est une NAT dans laquelle toutes les requêtes provenant de la même adresse IP interne et du même port sont mappées à la même adresse IP externe et au même port. En outre, tout hôte externe peut envoyer un paquet à l'hôte interne et il envoie un paquet à l'adresse externe mappée.
Restricted Cone : une fonction NAT de cône restreint est une fonction dans laquelle toutes les requêtes provenant de la même adresse IP interne et du même port sont mappées à la même adresse IP externe et au même port. Contrairement à une fonction NAT à cône plein, un hôte externe (avec l’adresse IP X) ne peut envoyer un paquet à l’hôte interne que si l’hôte interne a déjà envoyé un paquet à l’adresse IP X.
Port Restricted Cone : une NAT de cône à port restreint est similaire à une NAT de cône restreint, mais la restriction inclut des numéros de port. Plus précisément, un hôte externe peut envoyer un paquet, avec l'adresse IP source X et le port source P, à l'hôte interne uniquement si l'hôte interne a déjà envoyé un paquet à l'adresse IP X et au port P.
Symétrique : une NAT symétrique est une NAT dans laquelle toutes les requêtes provenant de la même adresse IP interne et du même port vers une adresse IP de destination et un port spécifiques, sont mappées vers la même adresse IP externe et le même port. Si le même hôte envoie un paquet avec la même adresse source et le même port, mais vers une destination différente, un mappage différent est utilisé. En outre, seul l’hôte externe qui reçoit un paquet peut renvoyer un paquet UDP à l’hôte interne.
Considérez une topologie dans laquelle la source (A, Pa) (où A est l'adresse IP et Pa est le port source) communique avec la destination (B, Pb) et (C, PC) via un périphérique NAT.
| Type de mise en oeuvre NAT |
Source publique à destination de (B, Pb) |
Source publique à destination de (C, Pc) |
La destination (par exemple : (B, Pb) ) peut-elle envoyer du trafic à (A, Pa) ? |
| Cône Plein |
(X1, Px1) |
(X1, Px1) |
Oui |
| Cône Restreint |
(X1, Px1) |
(X1, Px1) |
Uniquement si (A, Pa) avait envoyé le trafic à B |
| Cône à accès limité |
(X1, Px1) |
(X1, Px1) |
Uniquement si (A, Pa) a envoyé le trafic à (B, Pb) pour la première fois |
| Symétrique |
(X1, Px1) |
(X2, Px2) |
Uniquement si (A, Pa) a envoyé le trafic à (B, Pb) pour la première fois |
Problèmes avec NAT Traversal et NAT symétrique
Les serveurs STUN répondent aux requêtes de liaison STUN envoyées par les clients STUN et fournissent l'adresse IP/port public du client. Maintenant, cette combinaison adresse/port est utilisée par le client STUN dans sa signalisation de communication peer-to-peer. Cependant, maintenant que l'hôte d'extrémité utilise la même adresse privée/le même port (supposons que est lié à l'adresse IP/le port public fourni dans la réponse STUN) le périphérique NAT le traduit en la même adresse IP mais un port différent si l'implémentation NAT symétrique est utilisée. Ceci interrompt la communication UDP parce que la signalisation avait établi la connexion sur la base du port précédent.
L'implémentation NAT des routeurs Cisco IOS® lorsqu'il effectue la PAT est symétrique par défaut. Par conséquent, vous devez voir des problèmes de connexion UDP avec ces routeurs qui exécutent la NAT.
Cependant, l'implémentation NAT des routeurs Cisco IOS-XE lorsqu'il exécute la PAT n'est pas symétrique. Lorsque vous envoyez deux flux différents avec la même adresse IP source et le même port mais vers des destinations différentes, la source obtient NATED vers la même adresse IP globale interne et le même port.
La solution au problème
D'après cette description, il est clair que le problème peut être résolu si vous effectuez un mappage indépendant du point de terminaison.
Conformément à la norme RCFC 4787 : avec le mappage EIM (Endpoint-Independent Mapping), la NAT réutilise le mappage de port pour les paquets suivants envoyés à partir de la même adresse IP interne et du même port (X : x) vers n'importe quelle adresse IP externe et port.
À partir d'un client, lorsque l'hôte d'extrémité exécute les commandes nc -p 23456 10.0.0.4 4000 et nc -p 23456 10.0.0.5 5000, sur deux fenêtres de terminal différentes, voici les résultats des traductions NAT si vous utilisez EIM :
Pro Inside global Inside local Outside local Outside global
tcp 10.0.0.1:23456 192.168.0.2:23456 10.0.0.4:40000 10.0.0.4:40000
tcp 10.0.0.1:23456 192.168.0.2:23456 10.0.0.5:50000 10.0.0.5:50000
Ici, vous pouvez voir que différents flux de trafic qui ont la même adresse source et le même port sont traduits vers la même adresse/port, quel que soit le port/l'adresse de destination.
Sur les routeurs Cisco IOS, vous pouvez activer l'allocation de port agnostique de point d'extrémité avec la commande ip nat service enable-sym-port.
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configuration/15-mt/nat-15-mt-book/iadnat-fpg-port-alloc.html
Résumé
L'implémentation NAT de Cisco IOS est symétrique par défaut lorsque vous utilisez la traduction d'adresses de port (PAT) et peut provoquer des problèmes lorsqu'elle transmet du trafic UDP P2P qui nécessite des serveurs tels que STUN pour la traversée NAT. Vous devez configurer explicitement EIM sur le périphérique NAT pour que cela fonctionne.
Commentaires