vendredi 23 octobre 2015

TSHOOT Général – Etude de cas 2

A travers cet article, nous allons voir un deuxième cas de Troubleshooting sur une topologie complète.
Dans cette topologie, un problème s’est glissé.
Celui-ci peut être à n’importe quel niveau (routeur, switch, PC, etc…).

Il faudra donc adopter la bonne approche, pour trouver le problème rapidement.

1) Scénario et topologie


Depuis ce matin, les clients se plaignent de ne pas avoir accès au réseau.
Il semblerait qu’une intervention ait été réalisée hier au soir.
Le problème vient probablement de là.
Malheureusement, les personnes ayant modifié le réseau ne sont pas présentes.

Voici la topologie à votre disposition.

L’accès à internet est simulé par un accès à WEB Serveur

2) TSHOOT


Commençons par constater le problème.

En demandant à un client de vous montrer le problème, il vous présente ceci :
Panne WEB
Il en est de même sur FTP Serveur.

Testons avec une requête de Ping.
Sur Client 1 :
Ping
Sur FTP Serveur :
Ping
Déjà, FTP Serveur peut joindre le serveur, mais pas en HTTP.

Client 1 ne peut pas le joindre.

Dans le message de retour, 10.1.1.1 nous indique que 172.17.0.100 n’est pas joignable.

10.1.1.1 est l’IP de R1.

Si R1 indique à Client 1 que le serveur n’est pas joignable, mais que FTP Serveur peut le joindre, et qu’en plus le HTTP est bloqué, il y a fort à parier qu’une ACL est en place.

Vu les messages de retour, il n’est pas nécessaire pour le moment de vérifier la liaison Client – R1.
En effet, le problème ne semble pas se situer avant R1.

Allons voir si R1 possède des ACL.
Show ip access-list
La première ACL, d’après son nom sert à la redistribution.

La deuxième est probablement utilisée pour filtrer le trafic.

Vérifions si elle est appliquée.
Show run
L’ACL est appliquée sur l’interface Serial 0/0.2 en entrée.

Elle filtre donc le trafic venant des « réseaux internes » vers le WEB Serveur.

Il faut à présent analyser cette ACL en détail.

Elle est divisée en plusieurs parties :
  • Autorisation de l’ICMP
  • Autorisation du Telnet
  • Autorisation du SSH
  • Autorisation du HTTPS
  • Autorisation du FTP
  • Autorisation du DNS
  • Autorisation du SMTP
  • Autorisation du POP3
  • Autorisation de l’OSPF

Au passage, notez que sans l’entrée pour l’OSPF, R1 et R2 n’auraient pas de relations de voisinage entre eux.
Pensez donc à vérifier que les protocoles de routage sont autorisés dans les ACL, si une relation de voisinage doit se former à travers l’interface concernée.

Revenons à notre ACL.
Les réseaux pris en compte sont les suivants :
  • 2.0.0 /28
  • 1.0.0 /16
  • 168.0.0 /18

Pour savoir si cela est bon, il nous faut les IP des VLAN.
Show ip interface brief
J’utilise cette commande car elle résume bien les IP.
(Bien entendu, il faudrait aussi vérifier les masques).

Cela met en évidence un problème au niveau de l’ACL.
Dans l’ACL, le réseau 10.2.0.0 /28 n’englobe pas tous les VLAN.

Ce qui explique pourquoi FTP Serveur peut joindre WEB Serveur, et pourquoi Client ne peut pas.

Sur FTP Serveur :
Ipconfig
L’IP de FTP Serveur est prise en compte par l’ACL.

Sur Client 1 :
Ipconfig
Son IP n’est pas prise en compte par l’ACL.

Deuxième problème dans l’ACL, le HTTP n’est pas autorisé.
Seul le HTTPS est autorisé.
Ce qui explique que personne n’ai accès au WEB Serveur.

Modifions donc l’ACL en tenant compte de ces observations.
no ip access-list exte FiltreWEB
ip access-list exte FiltreWEB

permit icmp 10.2.0.0 0.0.15.255 any
permit icmp 10.1.0.0 0.0.255.255 any
permit icmp 192.168.11.128 0.0.31.255 any
permit tcp 10.2.0.0 0.0.15.255 any eq 23
permit tcp 10.1.0.0 0.0.255.255 any eq 23 
permit tcp 192.168.11.128 0.0.31.255 any eq 23
permit tcp 10.2.0.0 0.0.15.255 any eq 22 
permit tcp 10.1.0.0 0.0.255.255 any eq 22
permit tcp 192.168.11.128 0.0.31.255 any eq 22
permit tcp 10.2.0.0 0.0.15.255 any eq 80 
permit tcp 10.1.0.0 0.0.255.255 any eq 80 
permit tcp 192.168.11.128 0.0.31.255 any eq 80
permit tcp 10.2.0.0 0.0.15.255 any eq 443 
permit tcp 10.1.0.0 0.0.255.255 any eq 443 
permit tcp 192.168.11.128 0.0.31.255 any eq 443
permit tcp 10.2.0.0 0.0.15.255 any eq 20
permit tcp 10.2.0.0 0.0.15.255 any eq 21
permit tcp 10.1.0.0 0.0.255.255 any eq 20
permit tcp 10.1.0.0 0.0.255.255 any eq 21
permit tcp 192.168.11.128 0.0.31.255 any eq 20
permit tcp 192.168.11.128 0.0.31.255 any eq 21
permit udp 10.2.0.0 0.0.15.255 any eq 53
permit udp 10.1.0.0 0.0.255.255 any eq 53
permit udp 192.168.11.128 0.0.31.255 any eq 53
permit tcp 10.2.0.0 0.0.15.255 any eq 25
permit tcp 10.1.0.0 0.0.255.255 any eq 25
permit tcp 192.168.11.128 0.0.31.255 any eq 25
permit tcp 10.2.0.0 0.0.15.255 any eq 110
permit tcp 10.1.0.0 0.0.255.255 any eq 110
permit tcp 192.168.11.128 0.0.31.255 any eq 110
permit ospf any any

Vérifions le résultat.
Sur Client 1 :
Ping
Panne WEB

Sur FTP Serveur :
Ping
Panne WEB
La connexion a été rétablie pour les deux.

Aucun commentaire:

Enregistrer un commentaire