Exercices Traduction adresses IPV4 (NAT) TP NAT et voix sur IP

Exercice 1 : Traduction d’adresses IPV4 (NAT)

     La norme RFC 1631 (mai 1994) ('The IP Network Address Translator’), définit un principe général de traduction d’adresses IP. La dernière version, la plus récente de cette approche RFC 3002 (janvier 2001) améliore différents points. 

    La traduction d'adresses peut être appliquée par différents types d’appareils dont la caractéristique principale est d’être situés entre un réseau IPV4 privé et le réseau IPV4 global. Typiquement la traduction est effectuée par un routeur, mais on peut aussi appliquer la traduction dans un hôte quelconque ou dans un filtre (pare-feux ou ‘firewall’).

    La traduction au niveau des adresses IP s'applique à l'adresse source d'un datagramme IP en provenance du réseau privé (baptisé encore en NAT réseau interne) et à destination du réseau public (baptisé encore en NAT réseau externe). De manière symétrique, la traduction est effectuée sur les datagrammes en provenance du réseau public (ou externe) vers le réseau privé (ou interne). 

 

    La traduction d’adresse peut être réalisée de différentes façons qui sont examinées dans les questions suivantes. 

Question 1

Dans le mode NAT statique l’adresse IPV4 source privée est traduite en une adresse IPV4 source publique qui est toujours la même. La correspondance dans ce cas est bijective (biunivoque) c'est-à-dire qu’à une adresse privée est associée de manière statique une adresse publique (selon une table de correspondance statiquement définie par un administrateur réseau). 
 

Quelle utilisation peut-on faire d’un tel mode de traduction d’adresses IP ?
Quels sont les inconvénients ?

Question 2

Dans le mode NAT dynamique, la traduction d’une adresse source IPV4 privée est effectuée vers une adresse source IPV4 publique qui est prise dans un bloc d’adresses publiques disponibles. L’adresse publique utilisée n’est donc pas toujours la même. Par exemple si l’on suppose que l’hôte d’adresse 172.20.40.17 émet un datagramme à un instant donné vers l’Internet global, son adresse est traduite dans la première adresse disponible d’un bloc. Par exemple, si l’adresse 212.19.50.63 du bloc disponible 212.19.50.0 à 212.19.50.255 est non utilisée au moment de l’émission du datagramme, on l’utilisera et on traduira 172.20.40.17 en 212.19.50.63. Cette correspondance est enregistrée dans une table. De manière à éviter de bloquer indéfiniment une adresse attribuée dynamiquement, un temporisateur est utilisé pour révoquer l’attribution d’une adresse publique. A l’échéance, on récupère une adresse attribuée et l'on procède à une nouvelle attribution d’adresse si un nouvel échange à lieu (éventuellement on peut reprendre la même adresse pour un autre quantum). 

Quel avantage nouveau obtient-on d’un tel mode de traduction d’adresses IP ?


Question 3
  

Le troisième mode est connu sous différents noms (mode NAT avec surcharge NAT 'overloading' encore appelé NAT with PAT 'Port Address Translation'). Dans ce cas la traduction d’une adresse source IPV4 privée vers une adresse source IPV4 publique est complétée par la traduction du numéro de port. Le plus souvent, dans ce cas on suppose l'utilisation d'une seule adresse publique (par exemple une adresse publique comme 212.19.50.63 disponible). Si l’on suppose que l’hôte d’adresse 172.20.40.17 émet un datagramme selon le protocole TCP avec le numéro de port source 5032, alors son adresse IP est traduite en l’adresse IP publique (212.19.50.63) et le numéro de port source TCP est également traduit vers un numéro de port non
utilisé (par exemple 4097 si ce port n'est pas déjà attribué à une autre communication). Comme dans le cas du NAT dynamique, les attributions sont associées à un temporisateur avec récupération à échéance. Ce mode de fonctionnement est le plus utilisé.  

 

Quels en sont les avantages et les inconvénients ?

Exercice 2 : NAT et voix sur IP

   L’approche NAT (‘Network Address Translation’) présente dans le cadre du protocole IPV4 de nombreux avantages. NAT pose aussi différents problèmes avec certaines applications Internet en particulier des applications d’actualité comme les communications de voix sur IP (VoIP ‘Voice over IP’). 

   En communication de voix sur IP on cherche à réaliser des communications vocales en utilisant le réseau Internet. L’analogue du numéro de téléphone est une adresse IPV4 d’interface d’accès à un appareil (un poste de travail qui possède un micro et un écouteur ou un téléphone IP). Cependant il n’a pas été retenu d’utiliser directement des adresses IP  pour désigner un correspondant comme on le fait des numéros de téléphone. On rappelle que l'attribution d'adresse IP peut être statique ou dynamique.

Question 1

On s'intéresse au cas d'une attribution statique des adresses IP. Un émetteur peut-il utiliser l’adresse IP directement pour appeler un correspondant comme on le fait avec un numéro de téléphone (justifiez votre réponse)? 

Question 2

On se place maintenant dans le cas d'une attribution dynamique (DHCP). Quel(s) problème(s) se posent en utilisation d’adresses IP dynamiques pour appeler un correspondant ?

Question 3

Dans le cas où l'on se trouve dans un réseau privé avec un routeur NAT,  peut-on directement utiliser les adresses IP pour appeler un correspondant comme on le fait avec un numéro de téléphone ?

Dans les protocoles de voix sur IP on utilise une gestion d’annuaires. Les annuaires sont placés dans l’Internet public et accessibles en ligne en mode client-serveur. C’est le cas en SIP (‘Session Initiation Protocol’ un protocole de signalisation sur réseau IP) ou en SKYPE (système de téléphonie ‘gratuite’ utilisant la voix sur IP). Rappelez le rôle d’un serveur d’annuaire (quelles sont les trois opérations principales réalisées par un serveur d’annuaire ?). 

Question 4

Dans le cas de la voix sur IP à quoi correspondent les noms logiques et les adresses physiques et à quel moment sont réalisées les opérations d’annuaire?

Question 5

Dans certains protocoles d’application de l’Internet, certains messages protocolaires contiennent l’adresse IP V4 source de l’émetteur dans l'entête du datagramme IP mais aussi dans la partie donnée du message (dans la charge utile). Par exemple, en voix sur IP, dans quel cas peut-on trouver une adresse IP dans un message? 

 Quel problème pose l’utilisation de NAT pour de tels protocoles ?

Question 6

Différentes solutions ont été proposées pour résoudre le problème précédent (adresses IP dans une charge utile). Une solution consiste à faire en sorte que les applications qui font de la voix sur IP reçoivent des adresses IP fixes publiques ou des traductions en adresses IP fixes publiques. 

Discutez cette solution (évaluez les avantages et les inconvénients, la faisabilité de la solution) ?

Question 7

Une autre solution consiste à faire en sorte que les routeurs NAT connaissent la structure des messages des protocoles de voix sur IP comme SIP ou Skype. 

Précisez et discutez cette solution ?

Question 8

   Une troisième solution consiste à utiliser un protocole client  serveur baptisé STUN (‘Simple Traversal of UDP Through NAT’ RFC 3489 mars 2003). Ce protocole a été conçu pour répondre aux problèmes des adresses IP contenues dans la partie donnée des messages.

   Un client STUN est un utilisateur de l’Internet qui souhaite connaître son adresse IP et son numéro de port. Un serveur STUN est situé dans l’Internet global (celui des adresses publiques). Il possède un port de numéro réservé (port ‘bien connu’). Dans un message de requête un client STUN (typiquement un téléphone IP) émet une demande de son adresse IP et de son numéro de port vers un serveur STUN situé dans l’Internet global. Le serveur STUN analyse le datagramme reçu et répond en retournant au client l’adresse IP et le port public du client dans le message. 

   On se  place dans le cas ou les adresses sont traduites en sortie d’un domaine (traduction des adresses et port source sur les datagrammes en sortie et des adresses et ports destination sur les datagrammes en entrée). On fait l’hypothèse que le routeur NAT effectue toujours la même traduction pour tous les datagrammes ayant un couple adresse, numéro de port donné. Comment le serveur STUN peut-il connaître l'adresse IP et le numéro de port du demandeur dans l'Internet global?  

 

Expliquez comment le client utilise les informations reçues pour résoudre le problème des adresses IP contenues dans les messages ?

Question 9

De nombreux routeurs NAT effectuent une traduction d’adresse IP et de numéro de port source qui dépend de la destination. Tous les datagrammes ayant même source et même destination sont traduits de la même façon. Deux datagrammes ayant même source (adresse IP et numéro de port) et deux destinations différentes (adresse IP ou numéro de port) voient l'adresse IP et le numéro de port source traduits de deux façons différentes. 

Expliquez pourquoi dans ce cas, le protocole STUN ne marche plus.