Diagnostic : Faire votre diagnostic Réseau en quelques points clés

< Publications | Réseau

Un article des techniciens de Céleste.

Faire l'état des lieux

Dans ce cas de figure, nous allons nous placer dans le cas d'un poste client classique ne parvenant pas à accéder à un site WEB.

Un problème de réseau peut-être assimilé dans la majorité des cas à un point A qui n'arrive pas à communiquer avec un point B.

Première étape, faire un état des lieux afin d'avoir un maximum d'élément sur lesquels travailler.

1. Qui : Caractéristique de A et B ( A est un poste Windows utilisant internet exporer, B est un site web sur un serveur Web apache ) . Nous prenons ce cas de figure, cependant les possibilités sont multiples.
2. Quoi : Ressentie du problème ( A n'arrive pas à afficher la page du site web B )
3. Où : Localisation de A et B ( A se trouve derrière une connexion ADSL classique, B se trouve sur Internet ) .
4. Quand : Quand le problème a-t-il eu lieu, durant combien de temps, est-il chronique.
5. Comment : Comment la communication doit elle s'établir ( l'affichage d'une page WEB sollicite de manière générale le protocole HTTP fonctionnant sur le port 80)
6. Combien : Combien de personne/poste de travail/clients/lignes sont impactés ( 1 ou plusieurs) . Eventuellement voir les points communs entre les postes impactés.
7. Pourquoi : la démarche qui suit doit nous permettre d'y répondre

Deuxième étape, prendre en compte tous les éléments, et segments réseaux traversés qui peuvent donc avoir une impacte sur la communication entre le point A et le point B.

Matériel : routeur (box), switch, cable

Service : proxy, nat, firewall, Qos

Liaison : ADSL, SDSL, fibre optique

Logiciel : navigateur, antivirus

Troisième étape, synthétiser le scénario de communication entre le point A et le point B, éventuellement faire un schéma afin de ne rien oublier.

Schéma :

Scénario :

Le poste A ouvre son navigateur WEB (Internet Explorer, Firefox...).

Les DNS du poste A tente d'effectuer la résolution de nom (www.google.fr -> adresse_IP).

Le navigateur, le site étant trouvé, transmet la requete au serveur WEB concerné.

Le serveur WEB transmet la page au navigateur.

Le poste A affiche le site Web B.

Diagnostiquer et résoudre le problème

La communication sur un réseau s'appuie principalement sur le modèle OSI. Nous allons cependant nous appuyer sur le modèles TCP/IP qui est plus synthétique et plus adapté afin d'effectuer les contrôles qui nous permettrons de localiser puis solutionner notre problématique.

Modèle TCP/IP :

Modèle en 4 couche

Couche hôte-réseau

Couche internet

Couche transport

Couche application

Nous allons donc tout d'abord nous axer sur la couche hôte-réseau.

Cette couche regroupe les couches physiques et liaison de données du modèle OSI. L'implémentation de cette couche dépend de la technologie utilisée sur les réseaux traversés, dans notre cas il s'agit de l'Ethernet.

Les contrôles seront effectués en majorité sur le réseau local de poste A, qui est généralement la seule partie que nous maitrisons.

On pourra distinguer deux segments de tests, manuels et visuels plus axés sur la partie physique et des tests de configuration plus axés sur la partie liaison de donnée.

Premiers contrôles :

• Le poste A est bien sous tension.
• Le serveur WEB du site B est bien sous tension (si contrôle possible). Attention, toujours s'appuyer sur l'état des lieux, si le problème est mono-poste, et que le site est accessible pour d'autres postes, il est peu probable que la problématique vienne de là.
• Le switch réseau est bien sous tension.
• Le modem/routeur (box) est bien sous-tension.
• Les voyants lumineux confirmant le bon câblage sont bien présents. Pour cela partir de la carte réseau du poste A et s'assurer que les témoins lumineux sont allumés sur tous les segments traversés, entre le poste et le switch ,puis entre le switch et le routeur et pour finir entre le routeur et le modem. Il arrive souvent que le modem et le routeur soit regroupé dans un seul et même boitier.

Grâce à ces contrôles, nous pouvont déjà éliminer tous les problèmes matériels. Si des problèmes sont constatés, un reboot ou un changement de matériel (switch, cable, carte réseau) suffiront à résoudre notre problème.

Seconds contrôles :

• La carte réseau du poste A est présente et active. Ce contrôle se fait via votre interface ligne de commande (DOS sous Windows, Terminal sous Linux...)Commande nécessaire :

Linux :

mii-tool : permet de s'assurer que le câble branché dans la carte réseau est détecté au niveau logiciel.

ifconfig : permet de s'assurer que le carte réseau est UP et de contrôler par la suite le bon adressage IP.

Windows :

ipconfig : permet de s'assurer que le câble branché dans la carte réseau est détecté au niveau logiciel et que la carte réseau est UP. Les informations remontées permettront aussi de contrôler le bon adressage IP.

• Adresse IP présente sur le poste A. Que votre poste soit en IP fixe ou en DHCP, la présence d'une adresse IP est indispensable au bon fonctionnement de votre réseau. Sur un même réseau, une adresse IP est unique et permet donc aux différents périphériques réseau (PC, imprimante, box ou modem/routeur) de communiquer entre eux. Dans le cas du DHCP cette adresse est attribuée au poste A de manière dynamique par un serveur (généralement votre box ou modem/routeur). Un problème de DHCP pourra être constaté si le poste A possède une adresse en 169.x.x.x, ce qui signifie que le serveur DHCP est en défaut ,mal paramétré ou injoignable.

• Contrôler les voyants de connexion du modem/routeur, présence de la synchronisation et de la connexion Internet.

Ces contrôles permettent d'éliminer un problème de configuration de périphérique (carte réseau, box). Cependant, si le problème vient de l'état du modem/routeur, une ouverture de ticket sera nécessaire chez votre fournisseur d'accès.

Il faut ensuite contrôler la couche internet. Cette couche comme son nom l'indique permet l'interconnexion de réseau, elle est généralement liée au protocole IP.

• Le poste A peut-il joindre le site Web B. Pour cela toujours via l'interface de commande, utiliser la commande ping. Une résolution de nom est d'abord faite sur l'URL entrée puis des paquets sont envoyés.

Ex : ping www.siteB.frCette commande, envoi des paquets du point A vers le point B puis les paquets reviennent du point B vers le point A. Pour schématiser c'est comme envoyer une balle contre un mur.

• Dans la mesure ou le poste A n'arrive pas à joindre le site Web B. Il faut ensuite reduire le segment posant problème, n'ayant à notre niveau que la main sur notre réseau local, effectuer un ping vers notre modem/routeur.

• Il est envisageable de faire un traceroute du site Web B, cependant nous allons donc tester des segments externes à notre réseau local, nous ne pouvons donc pas connaître les caractéristiques des noeuds (équipements réseaux) traversés, les résultats des tests ne seront donc pas forcément pertinents. Grâce à cette commande nous obtiendrons les adresses IP des noeuds traversés et nous pourrons donc les tester un à un afin de voir ou le trafic bloque (comme indiqué précédemment certains noeuds sont configurés pour ne pas répondre aux pings, les résultats ne seront donc pas forcément exploitables).

• Pour finir, les mêmes tests depuis une autre connexion, voir depuis les tests ping sur Internet peuvent compléter les résultats précédents.

Il peut être bon de préciser, que dans la mesure du possible, il peut être utile d'écouter sur les interfaces réseaux des équipements traversés à l'aide de la commande tcpdump ou à l'aide de logiciel de capture des paquets. Pour simplifier, ces outils permettent de voir ce qui transite sur les interfaces réseaux, vous pourrez donc suivre le trajet de votre ping sur les points que vous maîtrisez (poste A, modem/routeur, voir le serveur du site Web B).

• Il est possible que la communication se fasse mais soit très mauvaise. La commande ifstat (linux) permettra de voir si votre bande-passante n'est pas surchargée, ainsi que tout autre logiciel de mesure de la bande-passante. La saturation de la bande-passante provoque en effet des hausses du temps de réponse ainsi que des pertes de paquets qui peuvent être très impactant.

Suite à ces tests, nous pourrons situer sur quel segment les paquets bloquent.

Si la résolution de nom ne se fait pas, l'utilisation d'autres serveurs DNS pourra résoudre la problématique. Si avec d'autres serveurs, la résolution ne se fait pas, il y a de grandes chances pour que le problème vienne de l'hébergeur du site Web B.

Si le ping ne répond pas entre le poste A et le modem/routeur, le problème viendra d'un problème IP, table de routage incorrect, conflit d'adresse IP ou firewall bloquant.

Si le ping ne répond pas au-delà du modem/routeur, et que via les tests sur Internet vous avez le même problème, dans la mesure ou le site est censé répondre au ping, il faudra signaler le problème à l'hébergeur du site Web B.

Si le ping ne répond pas au-delà du modem/routeur, et que via les tests sur Internet vous n'avez pas le même problème, il faudra signaler le problème à votre fournisseur d'accès.

Si le ping répond mais est très mauvais (perte ou délai élevé), le ifstat permettra de confirmer la saturation, associé à un tcpdump, nous pourrons ensuite déceler le trafic consommant la bande-passante et le stopper.

Une fois ces tests finis, nous pouvons passer à la couche transport. Cette couche permet le bon acheminement des paquets entre le poste A et site WEB B. Elle est généralement liée aux protocoles TCP et UDP, le premier étant plus fiable que le second.

• Le poste A peut-il joindre le site Web B en port 80. Pour ce test nous utiliserons la commande telnet (pourtant lié à la couche application) toujours via l'interface de commande.

Ex : telnet www.siteB.fr 80Cette commande envoie des requêtes à destination du port 80 en TCP. Nous simulons donc une communication HTTP avec une couche application simplifiée (Internet Explorer, Firefox étant fortement paramétrable, leur configuration peut être à l'origine de problème).

Tout comme pour les tests ping, il peut être utile d'écouter sur les interfaces réseaux des équipements traversés à l'aide de la commande tcpdump ou à l'aide de logiciel de capture des paquets.

Grâce à ce test nous pourrons éliminer les problèmes de filtrage lié à des firewalls ou un problème de configuration du serveur Web. Un firewall peut en effet bloqué le trafic en port 80 ou le serveur Web hébergeant le site Web B peut être mal configuré et ne pas écouté sur le bon port.

Les tests sur cette couche sont les plus complexes, et nécessitent pour beaucoup l'analyse des paquets transmis (analyse du dialogue, retour d'erreur, taille des paquets, MSS/MTU).

Nous finirons avec la couche application. Cette couche est liée à l'utilisation des logiciels.

• Contrôler la configuration du navigateur utilisé (cookie, niveau de sécurité, proxy...)

• Faire le test avec un autre navigateur

• Contrôler voir désactiver l'antivirus. Ces tests permettront d'éliminer tous les problèmes de configuration logiciel. Il pourra être nécessaire de baisser le niveau de sécurité, le niveau de gestion des cookies ou désactiver un proxy filtrant le site Web B. De plus, l'antivirus peut bloquer l'accès à certains site ou demander une autorisation.

Cette méthode ne couvre malheureusement pas tous les problèmes pouvant être rencontré, mais permet à quelequ'un n'ayant que des connaissances en réseau de résoudre tout de même une grande partie de ces problèmes.

Cette méthode peut être appliquée à une grande majorité des cas de figure. Nous avons pris pour fil conducteur le cas d'un poste informatique ne pouvant accéder à un site Web, mais les tests sont aisément transposables sur des problèmes de transferts FTP ou de VPN par exemple.

La majorité des problèmes réseaux pouvant être réduit à un problème de communication entre deux points, il faut donc, comme l'indique cette méthode, tester tout les segments traversés, localiser le problème et le corriger.

Christophe Delyon
Responsable Production