Dépannage NAT

Dépannage NAT

Dépannage NAT: Lorsqu’il y’a des problèmes de connectivité dans un environnement NAT , il est souvent très difficile de déterminer la cause du problème. 

Voici des étapes pour vérifier si le nat fonctionne (Dépannage NAT) :

• |Tout d’abord il faudrait commencer par vérifier, si les translations se déroulent sans problème:
  • |La commande « show IP nat translations » affiche la table nat du routeur.
  • | « debug IP nat » permet de vérifier les translations en direct.
  • | « show access-list » vérifie que l’ ACL associée à la commande NAT comprend bien l’ensemble des réseaux qui doivent être nattés !
    
  • |Et la commande « show IP nat statistics » permet de vérifier que les interfaces du routeur sont correctement définies en inside et outside. Elle affiche aussi des informations :
    • -sur le nombre total de translations actives.
    • -des paramètres de configuration NAT
    • -du nombre d’adresses dans le pool
    • – et de combien, il y’en a, d’attribuer. 
      

Si certains périphériques ont une connectivité internet et d’autres non, il s’agirait peut-être du pool de NAT qui ne comprend pas toutes les adresses !

• |Ensuite si des translations se produisent, et qu’il n’y a toujours aucune connectivité, il faudrait vérifier les itinéraires de retour avec la commande : |show IP route

La commande |clear IP nat translation, avec une * permet d’effacer toutes les entrées des adresses translatées dynamiquement. Par défaut, elle s’efface après 24 heures.

Les commandes du type « show » sont très utiles sur de petits réseaux. Mais dans des environnements plus complexes, il est nécessaire d’utiliser des commandes « debug » sur le routeur pour afficher le comportement des translations directement !

Par contre, ce type de commande est à utiliser avec prudence, car elle consomme pas mal de ressource CPU de l’équipement. Il faut donc faire très attention, surtout sur des machines en prod !

|Après avoir dépanné, il faut toujours veiller à désactiver toutes les commandes debug en faisant un no debug all.

|La commande « debug IP nat » affiche des informations sur chaque paquet que le routeur traduit, ce qui est super pour vérifier le bon fonctionnement du NAT. 

Dans cette sortie :

• |L’ astérisque à côté du mot « NAT » indique que la traduction s’est produite par le cache. 
  Le premier paquet d’une translation est toujours switché par le process, ce qui est plus lent. 
  Et après que l’équipement ait mis le chemin en caches, les paquets traverseront le routeur beaucoup plus rapidement, car ils feront appel au cache pour trouver leurs chemins..
• |Le S correspond à l’adresse IP source.
• |Suivi de l’adresse traduite.
• |Le D = corresponds à l’adresse IP de destination.
• |Et le chiffre [21] entre parenthèses est le numéro d’identification IP. Cette information peut être utile pour le débogage, car elle permet une corrélation avec d’autres paquets IP , notamment quand on utilise un outil qui analyse les trames comme |wireshark.

Pendant une recherche de panne, il faut bien s’assurer aussi que l’ACL correspond bien à tous les réseaux qui doivent être nattés.

De ne pas oublier aussi que les ACL utilisent des |masques inversés et non des masques de sous-réseau.

Par exemple à l’examen, il y’a une question sous forme de TP, ou il faut découvrir la panne sur le nat, et la réponse, est qu’il ont paramétré un masque de sous réseau au lieu d’un masque inversé !

|Pour revenir au dépannage, si, malgré toutes ses vérifications, les translations ne se produisent toujours pas, il faudrait alors vérifier que le routeur distant possède bien vers l’adresse qui est traduite !

Retrouvez tous nos cours pour réussir votre CCNA sur la chaîne YouTube de Formip.