Pour résoudre le problème il faudrait connaître
l’adresse et le port publics que le routeur NAT a
assigné à la machine se trouvant dans le réseau
local. Soit en effectuant des requêtes au routeur
NAT ou bien par un autre élément du réseau.
Les solutions suivantes sont considérées comme
étant des protocoles UNSAF. En effet d’après
la RFC 3581 et IAB qui a développé ce protocole.
Le protocole UNSAF est un protocole qui permet de fournir
à un client derrière un NAT de connaître
l’adresse IP et numéro de port que le NAT a
alloué pour la transaction.
Divers solutions existent pour solutionner ce problème
classer dans deux catégories une de façon
directe permettant de traverser le routeur NAT et l’autre
en passant par un relais.
Solutions
directes
UPNP
(Universal Plug & Play)
Cette solution est un protocole réalisé
par Microsoft (entre autre) qui permet aux applications
du client de découvrir et configurer automatiquement
des éléments du réseau, y compris
les routeurs NAT.
En utilisant cette technologie, un client questionne le
NAT par l'intermédiaire d’une requête
UPnP afin de connaître quel mapping utilisé
pour recevoir des paquets sur un numéro de port.
Ainsi le routeur NAT transmettre l'adresse et le numéro
de port à la machine qui souhaite communiquer avec
la machine du réseau.
Ceci est réalisable uniquement pour des machines
situées sur un même sous réseau c’est
pourquoi dans le cas de NAT en cascade UPnP ne fonctionnera
pas. De plus il est nécessaire de faire des modifications
au niveau applicatif pour les applications qui communiquent
avec les dispositifs UPnP.
Le problème se pose sur la sécurité,
en effet avec cette technique c'est le client UPnP qui
commande dynamiquement l'ouverture des trous d'épingle
au monde extérieur.
Solutions
par relais
Le client pourra déterminer l'adresse
IP et numéro de port attribué par le routeur
NAT en effectuant des requêtes à un serveur
situé sur le réseau public.
STUN
(Simple Traversal of UDP Through Network Address Translator)
Le serveur STUN permet d’identifier l’adresse
IP et le numéro de port d’une machine natée
par le routeur NAT et connaître également
la nature du NAT utilisé. En effet une cascade
de requêtes et de réponses entre ce serveur
et la machine va permettre d’établir une
connexion avec la machine voulue. Ceci concerne des communications
sur le protocole de transport UDP. Voir RFC 3489. L’inconvénient
est que cette technique ne fonctionne pas pour un NAT
Symétrique.
TURN
(Traversal Using Relay NAT)
TURN est un protocole qui permet à l’aide
d’une machine relais d’établir une
connexion à des machines situées derrières
un NAT. Ce protocole est un complément du STUN
et des endroits la sonde dans le conduit signalisation
et de médias. C’est en fait un serveur qui
sert de relais aux machines désirant communiquer
entre elle et qui est situé sur un réseau
atteignable par ces machines. Cette technique permet de
réaliser des appels entrants et sortants sut tous
types de NAT qui est facile à implémenter
sans demandé de modification de l’architecture
du réseau existant.
Cette technique n'offre pas une sécurité
optimale.
RSIP
(Realm Specific Internet Protocol)
RSIP est une technique de traduction d'adresse IP qui
résout les problèmes NAT. En effet, RSIP
fonctionne comme un routeur NAT les adresses sont attribuées
par un serveur RSIP. Ces ordinateurs pouvant fonctionner
comme un client ou un serveur pour n'importe application
Internet et possèdent ainsi un nom DNS permanent
assigné par un serveur DNS modifié. Ce serveur
alloue une adresse publique temporaire à un nom
de DNS dont il a reçu la demande.
ICE
(Interactive Connectivity Establishment)
Afin d'essayer de traiter les questions NATS, l'IETF
a défini une norme nommée ICE qui réunit
la solution STUN et TURN afin de déterminés
toutes les connexions éventuelles des différents
postes SIP du réseau.
ICE va tout d’abord réalisé des requêtes
STUN au serveur STUN/TURN pour déterminer les transmissions
média entre les machines et le réseau public.
Puis ICE va créer une liste d’adresses IP
par laquelle les machines peuvent communiquer et enfin
va adopter la meilleure communication en définissant
des transmissions de média entre deux machines.
Dans le cas ou la communication n’est pas faisable
ICE emploiera le serveur TURN.
Cette solution nécessite le déploiement
de serveur STUN et TURN et est adaptable à tous
type de topologie.
Prenons un exemple
Alice va initialiser un appel et va ainsi recueillir l'adresse
IP et numéros de port public assignés par
le NAT en utilisant l'information de la configuration locale
à l'aide des mécanismes STUN , TURN et RSIP.
Ensuite Alice va envoyé un message à Mohadina
avec son adressage (Envoie d'un message initié).
Mohadina, à son tour va subir le même procédé
et va transmettre son adressage à Alice (réponse
du message initié).
Les messages précédemment échangés
sont envoyés en indiquant l'ordre de priorité
par lequel la machine souhaite être contactée.
Dans le cas ou une adresse est inaccessible, la machine
tentera d'établir une communication sur la prochaine
adresse.
Une fois la signalisation fondée, dans notre exemple
Mohadina va envoyer un média sur l'adresse ayant
la priorité la plus élevée. Mais Mohadina
va envoyer également des requêtes STUN sur
le média paquet envoyé, donc à Alice.
Des réponses STUN retournés ici une venant
d'Alice qui sera utilisée pour le paquet média
suivant.
