Sécurité : Pare-feu Cisco IOS

Dépannage des configurations de Cisco IOS Firewall

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document fournit des informations que vous pouvez employer afin de dépanner des configurations de Pare-feu de ½ du ¿  de Cisco IOSïÂ.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Dépannez

Remarque: Reportez-vous à Informations importantes sur les commandes de débogage avant d'émettre des commandes debug.

  • Afin de renverser (retirer) une liste d'accès, mettez « non » devant l'ordre d'access-group dans le mode de configuration d'interface :

    int <interface>
    no ip access-group # in|out
    
  • Si trop de trafic est refusé, étudiez la logique de votre liste ou essai pour définir une plus large liste supplémentaire, et puis appliquez-la à la place. Exemple :

    access-list # permit tcp any any
    access-list # permit udp any any
    access-list # permit icmp any any
    int <interface>
    ip access-group # in|out
    
  • La commande de show ip access-lists affiche quelles Listes d'accès sont appliquées et quelles trafic est refusé par elles. Si vous regardez le compte de paquet refusé avant et après l'exécution défectueuse avec la source et l'adresse IP de destination, des augmentations de ce nombre si les blocs de liste d'accès trafiquent.

  • Si le routeur n'est pas fortement chargé, le débogage peut être fait à un niveau de paquet sur la liste d'accès étendue ou d'ip inspect. Si le routeur est fortement chargé, le trafic est ralenti par le routeur. Discrétion d'utilisation avec des commandes de débogage.

    N'ajoutez temporairement l'aucune commande d'ip route-cache à l'interface :

    int <interface>
    no ip route-cache
    

    Puis, en mode d'enable (mais pas config) :

    term mon
    debug ip packet # det
    

    produit la sortie semblable à ceci :

    *Mar 1 04:38:28.078: IP: s=10.31.1.161 (Serial0), d=171.68.118.100 (Ethernet0), 
       g=10.31.1.21, len 100, forward
    *Mar 1 04:38:28.086: IP: s=171.68.118.100 (Ethernet0), d=9.9.9.9 (Serial0), g=9.9.9.9, 
       len 100, forward
  • Des Listes d'accès étendues peuvent également être utilisées avec l'option de « log » à la fin des diverses déclarations :

    access-list 101 deny ip host 171.68.118.100 host 10.31.1.161 log
    access-list 101 permit ip any any
    

    Vous voyez donc des messages sur l'écran pour le trafic permis et refusé :

    *Mar 1 04:44:19.446: %SEC-6-IPACCESSLOGDP: list 111 permitted icmp 171.68.118.100 
       -> 10.31.1.161 (0/0), 15 packets
    *Mar  1 03:27:13.295: %SEC-6-IPACCESSLOGP: list 118 denied tcp 171.68.118.100(0) 
       -> 10.31.1.161(0), 1 packet
  • Si la liste d'ip inspect est suspecte, la commande de <type_of_traffic> d'ip inspect de débogage produit la sortie telle que cette sortie :

    Feb 14 12:41:17 10.31.1.52 56: 3d05h: CBAC* sis 258488 pak 16D0DC TCP P ack 3195751223 
       seq 3659219376(2) (10.31.1.5:11109) => (12.34.56.79:23)
    Feb 14 12:41:17 10.31.1.52 57: 3d05h: CBAC* sis 258488 pak 17CE30 TCP P ack 3659219378 
       seq 3195751223(12) (10.31.1.5:11109) <= (12.34.56.79:23)

Pour ces commandes, avec l'autre information de dépannage, référez-vous au Seveur mandataire d'authentification de dépannage.


Informations connexes


Document ID: 13897