Diagnostic d'un réseau1

ROYAUME DU MAROC

OFPPT

Office de la Formation Professionnelle et de la Promotion du Travail

RÉSUMÉ T HÉORIQUE HÉORIQUE & GUIDE DE T RAVAUX RAVAUX PRATIQUES MODULE N°20:

DIAGNOSTIC D'UN

RÉSEAU

SECTEUR : NTIC SPÉCIALITÉ : TMSIR NIVEAU : T

1

Résumé de Théorie et Guide de travaux pratique

Diagnostic d'un réseau

Document élaboré par : Nom et prénom

EFP

DR

DRAOUI Hassan

ISGI Laayoune

Provinces sud

Révision linguistique

Validation

-

OFPPT/DRIF

2



Sommaire Classification...................... .............................................. ............................................... ............................................... ........................................... .....................10 10 Test...................... ............................................. ............................................... ............................................... ............................................... ................................... ...........10 10 Transmission..................... ............................................. ............................................... ............................................... ........................................... ..................... ..10 10 Rapport..................... ............................................ ............................................... ............................................... ............................................. ............................ ........ ..10 10 Utilisateurs finaux...................... ............................................. ............................................... ............................................... .............................. ............. ......11 11 Spécialistes du support support technique...................... .............................................. ....................................... ..................... ............ ............ ........11 11 Ingénieurs du support support technique...................... .............................................. ....................................... ..................... ............ ............ ......... ...11 11 Responsables et planificateurs ....................................................................................11 ....................................................................................11 Consignation du problem problem...................... .............................................. ............................................... ....................................... ...................... ......... ...12 12 Collecte des informations informations..................... ............................................ ............................................ ........................... ............ ............ ............ .......... ....13 13 Développement d'un plan d'action (planification)...................... .............................................. .................................. ............14 Implémentation du plan d'action..................... ............................................. ....................................... ..................... ............ ............ .......... ....14 14 Documentation de la resolution....................... ............................................... ............................................... .............................. ............. ........15 15 Nécessité d’une compatibilité entre tous types d’architecture :................................... : ...................................17 17 Un modèle de référence: le modèle OSI en 1977...................... .............................................. .................................. ............ ..17 17 Avantages de cette modélisation :........................ ............................................... ............................................... ................................. .........17 17 La couche physique: couche couche 1.................... ............................................ ............................................... ................................. ................ ......... ...18 La couche liaison de données : couche 2..................... ............................................ ....................................... ...................... ......... ...18 18 La couche Réseaux : couche 3...................... .............................................. ............................................... .................................... ................. ....18 18 La couche Transport: Transport: couche 4..................... ............................................. ............................................... .............................. ............. .......... ....19 19 La couche session: couche 5....................... .............................................. ............................................... ........................................... ...................20 20 La couche presentation: presentation: couche 6....................... ............................................... .................................... .................. ............ ............ ......... ...20 20 La couche d’application : couche 7...................... .............................................. ............................................. ........................... ............ ......20 20 Support physiques: couche 1 du modèle OSI................................................................ OSI................................................................ 21 Méthode d’accès au support:...................... .............................................. ............................................... .................................... ................... ......21 21 Protocoles couches couches basses: couches 3 et et 4....................... ...................................... ..................... ............ ............ ............ ......... ...21 21 Protocoles couches hautes : couche 5 (FTP, TFTP, Telnet)......... Telnet). ................. ................. .......................... ..................21 21 Applications : couches 6 et 7 (Netscape, Eudora, WS_FTP). WS_FTP)........................................... .......................................... 21

MODULE :

Diagnostic d'un réseau Durée : 75 H 35% : théorique 55% : pratique 10% : évaluation OBJECTIF OPERATIONNEL DE PREMIER NIVEAU DE COMPORTEMENT

OFPPT/DRIF

3



COMPORTEMENT ATTENDU

Pour démontrer sa compétence, le stagiaire doit diagnostiquer les performances ou le dysfonctionnement d'un réseau local d'entreprise selon les conditions, les critères et les précisions qui suivent : CONDITIONS D’EVALUATION

Individuellement. Travail effectué à partir : - d’une mise en situation situation ou d’un scénario scénario de pannes - de directives fournies par le formateur Travail effectué à l’aide : - d’un poste de travail travail fonctionnel, pouvant pouvant recevoir un système système d’exploitation réseau réseau et jouer le rôle de serveur; - d’un poste de travail travail utilisant des systèmes systèmes d’exploitation variés variés et jouant le rôle de la station de travail à relier au réseau; - d’un routeur - d’un commutateur commutateur ou d’un concentrateur concentrateur - d’accessoires de câblage - d’un système d'exploitation courant pour poste de travail : - d’un système système d'exploitation réseau courant courant - de logiciels réseaux, réseaux, d’outils et d’utilitaires dédiés dédiés au dépannage dépannage - de documents pertinents pertinents : manuels de référence appropriés, guide guide d’utilisation et schémas. CRITERES GENERAUX DE PERFORMANCE

Au terme de ce module, le stagiaire aura acquis les compétences nécessaires et la maîtrise d’outils et de techniques qui lui permettront d’évaluer le réseau dont il a la charge et de trouver rapidement et efficacement une solution aux problèmes que l’utilisateur rencontre. Il sera en mesure de réaliser les tâches suivantes : - Disting Distinguer uer en suivant suivant le modèle modèle OSI les différen différents ts types de problèm problèmes es que l’on retrouve en général dans les réseaux r éseaux locaux, et plus précisément : Analyser une situation problématique Identifier les sources d’un problème; Bâtir et appliquer une solution de qualité; Documenter adéquatement le problème et la solution Analyser les protocoles de la famille TCP/IP à l’aide d’un analyseur de protocoles - Distinguer les éléments à prendre en en compte dans l’évaluation de la performance performance du réseau. - Déterminer un cadre de référence pour l’évaluation de la performance performance du réseau. OFPPT/DRIF

4



- Distinguer les différents éléments éléments intervenant dans dans l’optimisation du réseau. réseau. Ce modu module le perm permet ettr tra a auss aussii aux aux stag stagiai iaire ress de déve dévelo lopp pper er leur leur capa capaci cité té à bien bien documenter toutes les étapes de leurs interventions i nterventions dans un processus de dépannage.

OFPPT/DRIF

5



OBJECTIF OPERATIONNEL DE PREMIER NIVEAU DE COMPORTEMENT PRECISIONS SUR LE COMPORTEMENT ATTENDU

A. . Analyser la demande

CRITERES PARTICULIERS DE PERFORMANCE •

•

•

•

1. Décrire les critères de performance d'un réseau

•

•

• •

• • •

B. Préparer l’analyse du réseau

• •

•

C. Analyser le réseau

•

•

• •

• •

OFPPT/DRIF

Processus de traitement d’une demande de résolution de problèmes. Catégorisation des problèmes soulevés sur l’utilisation du réseau. Identifier la nature du problème : Problèmes matériels Problèmes logiciels Problèmes humains. Prioriser les problèmes à corriger. Rappel sur les outils de diagnostic conventionnels et leur limitation respective. Notions relatives à l’utilisation de logiciels de type : analyseurs de protocoles, analyseur et inspecteur de réseaux. Notion d’éthique et aspect légal. Outils de surveillance en différé ou instantanée de l’utilisation et des accès réseaux. Périodicité des mesures. Indicateurs de performance réseaux. Outils propriétaires de suivi de performance. Outils de gestion propriétaire et générique. Base de données propriétaires et normalisés d’information de gestion des équipements réseaux. Technique de production de rapport de résultats d’analyse et de surveillance. Importance de la connaissance des procédures d’intervention existantes. Démonstration sur l’utilisation d’outils d’analyse et de monitoring réseau. Établissement d’un baseline du réseau. Familiarisation aux protocoles de gestion à l’aide d’outils simple puis plus complexe. Utilisation et interprétation des résultats. Configuration d’éléments logiciels et 6



•

•

•

•

•

D. Proposer une série de mesures visant à optimiser les performances du réseau

•

•

•

•

OFPPT/DRIF

matériels afin de permettre la gestion et le dépannage à distance. Utilisation et configuration d’analyseurs de protocoles et de réseau. Mises en situation permettant de mettre en évidence les facteurs critiques. Relevé d’indicateurs de performance à l’aide de mises en situation. Procédures de surveillance du réseau : sécurité; facteurs environnementaux; - performances. - principes d’intervention - procédures d’escalade. Les différents éléments intervenant dans l’optimisation du réseau. La mise à jour des composantes du réseau en vue d’un rendement optimal. Évaluation de la faisabilité et des impacts de la demande sur les changements à apporter : - À L’infrastructure du réseau : 1. Média de transport, 2. Re-segmentation du réseau, 3. Équipements dédiés. - Aux systèmes d’exploitation : 1. Mise à jour, 2. Migration à un autre système d’exploitation, - Aux logiciels d’application : 1. Mise à jour des logiciels existants, 2. Installation de nouveaux logiciels. - Aux services du réseau : 1. Reconfiguration des services existants, 2. Activation de nouveaux services. - À la sécurité : 1. Nouvelle politique de sécurité. - Aux serveurs et stations : 1. Modification des éléments physiques, 2. Modification de la configuration. Consultation des personnes concernées par les changements.

7


PRÉSENTATION

DU


MODULE

Pour répondre aux besoins des utilisateurs, le gestionnaire de réseaux doit leur fournir un réseau qui n’est pas seulement fonctionnel, mais aussi performant. On peut considérer que les besoins des utilisateurs sont en évolution au même rythme que la technologie. Par conséquent, le gestionnaire doit optimiser l’utilisation des ressources dont le réseau dispose. Pour ce faire nous allons procéder comme suit : -

Découvrir une méthodologie générale pour la résolution des

problèmes -

Maitriser le rôle de chaque couche du modèle OSI

-

Découvrir les différents outils de diagnostics conventionnels

Énumérer et dépanner les différents problèmes pour les trois premières couches du modèle OSI -

Énumérer et dépanner les différents problèmes pour les autres couches du modèle OSI -

-

Savoir utiliser les analyseurs de protocoles dans différents OS

Pour bien assimiler les concepts cités dans ce résumé il faut: Installer le logiciel de simulation Boson Netsim ou prévoir l’utilisation d’autres simulateurs (par exemple Paquet Tracer) Allouer le temps nécessaire à la partie théorique avant d’attaquer sa pratique Apporter un résumer des résultats des commandes de di agnostic dans un réseau sain

OFPPT/DRIF

8



Module : Diagnostic d'un réseau RESUME THEORIQUE

OFPPT/DRIF

9


I. 1.


METHODOLOGIE DE RESOLUTION DES PROBLEMES Méthodologie générale de résolution des problèmes

On peut affirmer que toute méthodologie de résolution des problèmes fait appel à des processus et procédures communs, quel que soit le domaine : informatique, plomberie ou mécanique automobile. Tout incident parcourt une série de processus conçus pour résoudre les problèmes aussi rapidement et efficacement que possible. Classification

Lorsqu'un utilisateur final rencontre un problème informatique et vous le signale, cela déclenche une série de processus de classification. Au cours de ceux-ci, vous collectez des informations auprès de l'utilisateur pour tenter d'établir la nature et l'étendue du problème. La classification vous permet de déterminer l'étendue et l'impact des problèmes en vue d'établir leur priorité. Même si vous êtes en mesure de résoudre le problème tout de suite, vous devez le consigner en vous conformant à la méthodologie en vigueur. Test

Une fois que vous avez établi la priorité d'un problème et consigné l'incident, la phase de test débute. Au cours de celle-ci, vous faites appel à plusieurs processus pour déterminer la cause probable du problème. Vous pouvez commencer par dresser la liste des causes possibles, généralement, en les divisant et en les isolants. Dans le domaine des systèmes informatiques, cela peut vouloir dire établir une distinction entre les problèmes de serveur et de station de travail, de matériel et de logiciel, et de système d'exploitation et d'applications. De cette manière, vous pouvez éliminer les causes possibles pour déterminer les causes probables. Lorsque vous avez réduit la liste des causes possibles à un nombre gérable, vous pouvez démarrer le processus de test. Ce processus vise à déterminer la cause probable parmi les causes possibles restantes. Transmission

Si vous ne pouvez pas trouver de résolution pendant la phase de test initiale, vous devez consulter la documentation supplémentaire ou transmettre le problème, soit au fabricant du composant suspecté, soit au sein de votre organisation si vous disposez de ressources internes. Un processus de transmission d'incident au personnel de support technique de deuxième niveau devrait être en place au sein de votre organisation. Rapport

Lorsque l'incident a été résolu, vous devez documenter sa résolution. Il est important d'enregistrer les modifications apportées à la configuration de votre système informatique. En outre, les problèmes ont tendance à se produire plusieurs fois. S'ils ont été documentés correctement, vous gagnerez du temps la prochaine fois que vous serez amené à résoudre des occurrences similaires du problème. 2.

Utilisateurs d'une méthodologie de résolution des problèmes

OFPPT/DRIF

10



Les services de support fonctionnent au sein d'une structure hiérarchique précise. Lorsque des utilisateurs finaux signalent des incidents aux techniciens du support technique, à savoir le premier niveau du support technique, et que ceux-ci ne peuvent pas les résoudre, ils les transmettent au support technique de deuxième niveau. Les ingénieurs de ce service ont des connaissances et des compétences plus spécialisées pour résoudre les problèmes. Lorsque cela est nécessaire, les ingénieurs du support technique peuvent remonter à leur tour le problème au support de troisième niveau. Le problème est alors pris en charge par des ingénieurs système experts dotés de compétences très ciblées. Les architectes système, les concepteurs et les planificateurs occupent le quatrième niveau de la structure. Les ingénieurs système peuvent faire appel aux architectes système et planificateurs de niveau 4 pour concevoir et planifier des modifications importantes à apporter à une infrastructure dues à la résolution d'un problème. Une méthodologie de résolution des problèmes bien conçue peut bénéficier à un nombre de personnes au sein de votre organisation, et pas seulement aux techniciens d'un service de support technique. Utilisateurs finaux

Une formation sur le matériel et les logiciels qu'ils utilisent et la mise à disposition de documents d'auto-assistance aux utilisateurs finaux constitue une partie importante de la méthodologie de résolution des problèmes. L'utilisateur a les moyens de résoudre certains problèmes sans contacter le support technique. Spécialistes du support technique

Les spécialistes du support technique fournissent le premier niveau d'assistance aux utilisateurs finaux. En tant que premier point de contact des utilisateurs finaux. Les spécialistes du service de support technique ont en général plus de compétences en matière de support technique que les ingénieurs du support technique. Ingénieurs du support technique

Les ingénieurs du support technique assurent le support de deuxième niveau au sein d'une organisation. En général, ils travaillent sur les problèmes que les spécialistes du support technique leur ont transmis. Certains ingénieurs du support technique se spécialisent dans un domaine de l'infrastructure informatique de l'organisation, alors que d'autres fournissent une assistance générale plus détaillée que ne proposent pas les spécialistes du support technique. Par exemple, un ingénieur du support technique peut se spécialiser dans les problèmes de réseau ou d'infrastructure de messagerie. Responsables et planificateurs

Une documentation à jour et exacte fournit aux planificateurs et aux responsables une base solide sur laquelle prendre leurs décisions relatives à l'infrastructure informatique. 3.

Étapes types d'une méthodologie de résolution des problèmes

OFPPT/DRIF

11



Lorsque vous commencez à résoudre un problème, il est important de savoir clairement quelles étapes vous allez exécuter. Consignation du problem

À ce stade, vous devez enregistrer les détails du problème et poser des questions pertinentes à l'utilisateur en vue de déterminer l'étendue du problème. Les réponses à ces questions peuvent vous aider à déterminer la priorité du problème. 

Processus de consignation des problèmes

Il est important de veiller à ce qu'un processus bien maîtrisé existe au sein de votre organisation pour que les problèmes soient consignés comme il faut. Problème détecté L’utilisateur final détecte un problème de matériel informatique, de système d'exploitation ou d'application. Auto-assistance Contacter le support technique Pendant cette phase, consignez les détails du problème. Classification et support initial Après que l'utilisateur a contacté le support technique, essayez de classifier le problème et d'en déterminer l'importance et l'urgence . Pour ce faire, vous pouvez poser des questions très spécifiques à l'utilisateur. Au cours de cette phase, vous pouvez déterminer une cause probable du problème signalé , mais ne tirez pas de conclusions trop hâtives. Vous risquez autrement de gaspiller beaucoup de temps et de ressources. Votre objectif pendant cette phase est de définir le problème correctement.

Transmission Lorsqu'un problème doit être transmis à un service de support technique de niveau supérieur ou à des fournisseurs externes, veillez à consigner suffisamment de détails en vue de les transmettre. Il est très utile qu'une procédure de transmission soit clairement définie pour un maximum d'efficacité. La procédure peut stipuler d'inclure les informations suivantes : • une description précise du problème signalé ; • un enregistrement de tous les indicateurs associés au problème (message d’erreurs…) ; • un enregistrement des tentatives de résolution faites par les membres du support technique ainsi que le résultat de chaque tentative ; • un enregistrement concernant tous les outils de diagnostic utilisés par les membres du support technique ; • la durée pouvant s'écouler avant qu'il y ait obligation de transmettre un problème. Vous pouvez considérer de transmettre le problème aux fournisseurs externes dans les cas suivants : • vous ne pouvez résoudre le problème ; • vous ne disposez pas de suffisamment de ressources internes pour résoudre le problème ; • votre organisation n'a pas les compétences requises pour résoudre le problème ; • vous avez identifié la cause probable du problème et elle provient d'un composant tiers spécifique.

OFPPT/DRIF

12



Chaque fois que vous remontez un problème, restez-en toujours le propriétaire et utilisez l'enregistrement de base de données pour suivre la progression vers une résolution. Assurez-vous également que vous fournissez toute l'assistance nécessaire aux autres niveaux d'assistance et aux fournisseurs externes. Résolution Une fois que vous avez déterminé la cause probable d'un problème et avez développé un plan d'action, vous devez évaluer ce plan. Après avoir évalué le plan d'action proposé, vous pouvez le mettre en œuvre. Au cas où le plan d'action ne résout pas le problème, envisagez de restaurer les modifications apportées suite à l'évaluation du plan d'action. Vous devez également repenser la phase de classification, car il est possible que le diagnostic et la classification initiaux étaient erronés. Problème clos Après avoir résolu le problème, vous devez le fermer. Pour cela, mettez à jour l'enregistrement de base de données en rapport avec le problème pour indiquer que vous avez résolu le problème de manière permanente, puis fermez l'enregistrement. Collecte des informations

Si vous ne parvenez pas à résoudre immédiatement le problème, vous devez rassembler le plus d'informations possibles à propos du problème dans le but d'identifier les causes possibles. Vous pouvez utiliser des outils d'analyse, consulter des journaux des événements ou simplement poser des questions supplémentaires à l'utilisateur pour recueillir davantage d'informations. 

Processus de collecte initiale des données

La phase de collecte des informations relatives à un problème signalé est très importante. En suivant une série d'étapes précise et logique, vous pouvez définir clairement la nature du problème et parvenir à déterminer une cause précise. Questionner En tant que membre du service du support technique, vous devez poser des questions claires et précises à l'utilisateur sur les symptômes du problème afin de pouvoir commencer à en définir la cause. Écouter Lorsqu'un utilisateur final vous signale un problème, écoutez-le attentivement. Il arrive souvent que lorsqu’un utilisateur répond à vos questions et relate l'historique d'un problème, celui-ci en révèle involontairement la cause. Consulter Lorsque vous avez enregistré toutes les informations pertinentes fournies par l'utilisateur, la tâche suivante consiste à déterminer la cause du problème signalé. Commencez par consulter la documentation concernant les problèmes connus que vous avez à disposition. Rechercher Si la documentation existante ne vous permet pas d'établir de causes probables, vous devez mener quelques recherches dans diverses sources. Par exemple, vous pouvez effectuer des recherches dans la Base de connaissances de support Microsoft® ou dans des forums en ligne. Développer Une fois que vous avez déterminé une cause probable du problème, vous devez développer un plan d'action.

OFPPT/DRIF

13



Développement d'un plan d'action (planification)

Quelle que soit l'approche pour laquelle vous optez, l'objectif de cette étape est d'isoler la cause du problème. Lorsque vous pensez l'avoir déterminée, vous devez tester vos hypothèses. Si les tests s'avèrent concluants, continuez jusqu'à ce que vous ayez déterminé la cause réelle. Une fois que vos tests ont révélé la cause d'un problème, vous devez planifier les actions suivantes. Par exemple, si le problème implique le remplacement d'un disque du serveur, vous devez commander le nouveau disque, déterminer une heure appropriée pour effectuer le remplacement, sauvegarder les données présentes sur le disque à remplacer, arrêter le serveur, installer physiquement le nouveau disque et exécuter une restauration des données sur celuici. 

Méthodes conseillées de développement d'un plan d'action

Les problèmes simples sont faciles à résoudre rapidement et leur plan d'action peut ne pas demander beaucoup de réflexion. Analyser les données disponibles Avant de commencer à modifier la configuration, analysez les données disponibles pour vous assurer que vous avez déterminé la cause probable du problème signalé. Consulter la documentation Consultez toute la documentation relative au correctif que vous envisagez de mettre en œuvre. Créer un environnement de test Si le correctif envisagé ou la solution de contournement implique une reconfiguration significative ou si des problèmes surviennent pendant la mise en œuvre du correctif, la productivité des utilisateurs pourrait s'en trouver affectée. Il est important que vous créiez un environnement de test qui ressemble étroitement au système de production et l'utilisiez pour tester votre plan d'action. Les technologies de virtualisation (telle que Microsoft Virtual PC) offrent un moyen pratique de créer des environnements de test sans requérir d'investissements majeurs dans du matériel ou des logiciels supplémentaires. Considérer l'impact des modifications Vous pouvez être amené à effectuer un important travail de reconfiguration pour résoudre des problèmes complexes. Les modifications que vous envisagez peuvent avoir une incidence sur de nombreux éléments de votre organisation. En outre, vous devez vérifier que les modifications proposées ne nuiront pas aux autres applications ou services. Prévoir une restauration Si vous implémentez un correctif ou solution de contournement qui ne résout pas le problème, vous pouvez envisager de revenir en arrière. L'exécution d'une restauration n'est pas nécessaire, mais peut être souhaitable dans des circonstances particulières. Implémentation du plan d'action

Après avoir mis au point un plan d'action, vous devez l'implémenter. Lorsque vous implémentez un plan d'action en vue de résoudre des problèmes graves, vous devez considérer l'impact des modifications que vous prévoyez d'apporter sur la disponibilité des services. 

Processus d'implémentation d'un plan d'action

OFPPT/DRIF

14



En général, votre plan d'action se composera des étapes suivantes. Toutefois, n'oubliez pas que les étapes spécifiques de votre plan d'action peuvent varier en raison de la complexité ou des circonstances d'un problème donné. Implémenter dans un environnement de test Avant de tenter de mettre en œuvre un correctif sur le système de production, implémentez votre plan d'action dans un environnement de test. Gardez à l'esprit que le processus de modification de quelques aspects de la configuration d'un ordinateur peut résoudre un problème spécifique, mais peut introduire d'autres problèmes. Analyser l'impact possible Vous devez vous assurer que toutes les modifications que vous envisagez d'implémenter ne nuiront pas au reste de l'infrastructure informatique. Par exemple, il est possible que sur un ordinateur spécifique, un nouveau pilote de périphérique pour un composant matériel suspect soit à l'origine de conflits entre périphériques qui provoquent des problèmes de démarrage de l'ordinateur. Se reporter à la gestion des modifications Les grandes organisations implémentent des procédures de gestion des modifications pour garantir que le personnel de support technique apporte des modifications à l'infrastructure informatique conformément aux instructions et qu'il les documente suffisamment une fois effectuées. Résoudre le problème Les spécialistes du support technique peuvent souvent résoudre rapidement les problèmes les plus courants, sans faire appel aux spécialistes des produits. Les problèmes moins courants ou plus complexes requièrent souvent l'intervention de spécialistes de support technique ou de fournisseurs externes, et parfois la création d'une équipe spécialisée regroupant les compétences nécessaires à la résolution d'un problème particulier. Lorsque cela est possible, considérez l'utilisation des outils et des utilitaires d'administration à distance, car ceux-ci permettent souvent de trouver des solutions plus rapidement. Surveiller et évaluer Si un correctif ou une solution de contournement est susceptible de prendre plusieurs heures et d'impliquer plusieurs étapes, vous devez surveiller la progression du processus de résolution du problème. Rendre compte et documenter Qu'un problème soit complètement résolu ou non, vous devez documenter toutes les étapes que vous avez effectuées pour le résoudre ou tenter de le résoudre. Si vous avez consigné l'incident dans une base de données pour suivre son état, vous devez mettre à jour l'enregistrement pour indiquer que le problème a été résolu ou non et si l'incident est clos ou non. La rubrique suivante traite plus particulièrement du processus de consignation d'une résolution d'un problème. Documentation de la resolution

Beaucoup d'organisations s'appuient sur la documentation pour fournir des informations relatives à la configuration de leurs systèmes informatiques. Si vous avez procédé à une reconfiguration pour résoudre un problème, vous devez mettre à jour la documentation de support pour refléter les modifications apportées. En outre, lors de la phase de collecte des informations, il est souvent utile de consulter les journaux d'incident, qu'un problème similaire ait été signalé ou non par quelqu'un d'autre. Savoir si un autre technicien a documenté des problèmes similaires n'est possible que si, à la clôture de l'incident, vous documentez ce que vous avez fait pour résoudre le problème. OFPPT/DRIF

15





Processus de consignation de la résolution

Dans la plupart des organisations de support, un processus existe pour enregistrer et documenter un problème signalé par un utilisateur. En général, le personnel du support technique consigne l'incident signalé dans une base de données. Lorsqu'un problème est résolu, vous devez clore l'incident et en informer l'utilisateur qu'il l'a signalé. Mettre à jour la documentation actuelle Si le problème a révélé des failles dans l'infrastructure informatique actuelle, dans les méthodes de travail ou dans d'autres domaines, vous devez mettre à jour la documentation actuelle pour faire état de ces failles et des correctifs ou solutions de contournement appropriés. Créer une nouvelle documentation Les problèmes graves et complexes entraînent souvent des modifications d'infrastructure majeures. Vous devez créer la documentation nécessaire pour prendre en charge ces modifications Consigner la résolution Vous devez mettre à jour tous les enregistrements de base de données associés à un incident. La mise à jour doit inclure la résolution et toute autre information pertinente relative au correctif ou à la solution de contournement utilisé pour résoudre le problème. Vous ne devez pas considérer un problème comme résolu tant que la résolution n'a pas été documentée de façon à être utile pour la résolution d'incidents ultérieurs. Enfin, vous devez clore l'enregistrement d'incident. Communiquer avec l'utilisateur final Vous devez permettre à l'utilisateur final qui a signalé le problème de savoir que vous avez résolu le problème. Si l'utilisateur doit prendre des mesures spéciales ou doit contourner le problème, vous devez l'en informer. Si vous avez apporté des modifications significatives à l'infrastructure, les utilisateurs peuvent avoir besoin de recevoir une formation. Consigner des mesures préventives Un problème ayant tendance à se répéter, il est essentiel que vous le documentiez ainsi que sa cause et les étapes qui ont permis de le résoudre. Une documentation adéquate garantit que les ingénieurs de support technique qui seront confrontés au même problème puissent découvrir une cause probable et une solution recommandée tôt dans le processus de résolution.

OFPPT/DRIF

16


II.


LE MODELE OSI : 1.

Décomposition en couches :

Nécessité d’une compatibilité entre tous types d’architecture :

* pour échanger des infos et partager des périphériques, * pour assurer compatibilité entre tous les niveaux d’une architecture informatique, * les associations de grands fabricants mondiaux ont tenté d’établir des règles, * il est alors possible à n’importe quel ordinateur de se connecter sur tout serveur. Un modèle de référence: le modèle OSI en 1977

* le modèle utilise des termes spécifiques afin de décrire les différentes parties, * ces parties appelées « couches » du modèle OSI réalisent une fonction précise, * architecture en trois niveaux : ⇒ Les couches qui sont des subdivisions de l’architecture OSI, ⇒ Les services : capacité que possède la couche N et fournie à la couche N+1, ⇒ Les protocoles : règles et formats (sémantique et syntaxique) déterminant les caractéristiques entre les couches de même niveau.

Couches hautes Traitement Couches basses Transmission

7 6 5 4 3

Applications Présentation Session Transport Réseaux

2 Liaison 1 Physique

Applications Présentation Service a Session Transport PROTOCOLE Réseaux (a) Liaison Physique Support Physique

7 6 5 4 3 2 1

n+1 n n-1

Avantages de cette modélisation :

* Chaque système est composé d’un ensemble hiérarchisé de couches verticales, * le support physique permet les échanges entre les systèmes ouverts, * limitation du nombre d’interfaces qu’un élément primaire doit connaître, * l’élément de la couche n du système k doit connaître : ⇒ Les couches n+1 et n-1 de son système k, ⇒ Les couches n de même niveau du système auquel il est connecté (k+1), * Les couches de même niveau s’échangent des informations de protocoles, * chaque couche n fournit des services à la couche n+1. 2.

Rôle des 7 couches du modèle OSI :

OFPPT/DRIF

17



La couche physique: couche 1

* fournit les procédures et les fonctions mécaniques, électriques ou électroniques : ⇒ Pour établir maintenir et libérer les connexions physiques entre équipements, ⇒ Représente tout ce qui constitue le support physique de l’info. * Assure la transmission de données sous forme de signaux électriques (bits) : ⇒ Selon une connexion permanente ou dynamique, ⇒ En l’alternat ou en bidirectionnel, ⇒ En série ou en parallèle, ⇒ Selon une ou plusieurs extrémités : point à point ou multipoint. * Assure la compatibilité des interfaces : ⇒ Pour le codage de la bande de base ou de la modulation, ⇒ Pour l’amplification du signal, ⇒ Pour le multiplexage de plusieurs signaux provenants de sources différentes. * Selon des règles de connexion physiques reconnues par l’ISO ou l’UIT : ⇒ Norme V.24 ou RS232 pour les modems. La couche liaison de données : couche 2

* Établit, maintient et libère les connexions liaison de données (méthode d’accès), * Une connexion LD est bâtie sur des connexions physiques établies ou non, * contrôle le trafic des données lors des transferts sur les connexions électriques ce qui correspond à effectuer un contrôle de flux d’informations : ⇒ L’émetteur et le récepteur doivent se synchroniser afin de ne pas perdre l’info, ⇒ Le récepteur doit traiter les blocs d’informations et les délivre à la couche supérieure, ⇒ Il faut mettre dans l’ordre les blocs arrivants à la couche 3 (séquencement des blocs). * responsable de l’acheminement sans erreurs des blocs d’information sur la ligne, d’où des mécanismes de protection d’erreur et de reprise sur erreurs, * le taux d’erreur résiduel TER doit alors être négligeable, * les blocs d’informations sont appelés Trames ou LPDU (Link Protocol Data Unit), * différents types de trames selon les normes (Ethernet, HDLC, SDLC). * Dans certains cas, la couche 2 est divisée en 2 sous couches : ⇒ La couche basse MAC (Medium Access Control) = contrôle d’accès au support partagé, ⇒ La couche haute LLC (Logical Link Control) = contrôle de la qualité de la transmission. La couche Réseaux : couche 3

* Responsable de l’acheminement des données pour arriver à bonne destination, * un adressage permettant d’identifier de manière unique chaque utilisateur, * définir un format de paquet et se donne les moyens de détection d’erreur, * contrôle le flux afin d’éviter les pertes de paquets par engorgement des chemins, OFPPT/DRIF

18



* les paquets peuvent traverser plusieurs noeuds du réseau suivant la topologie, * un routage est nécessaire pour gérer les problèmes d’acheminement, ⇒ Permet le transport des paquets de manière transparente, ⇒ Choisir une voie d’acheminement appropriée et commute les données en conséquence. * Les erreurs non-récupérables sont spécifiées à la couche supérieure, * livraison en séquence des paquets reçus par la couche supérieure, * différents types de protocoles selon les normes (IP, ICMP, ARP, RARP, X25), ⇒ Datagrammes : paquets que la couche réseau émet de manière autonome (IP). Les paquets d’un même message peuvent prendre des routes différentes. ⇒ Circuits Virtuels : demande une connexion explicite entre les @ réseaux ou NSAP. Plus grande complexité de gestion mais pas de contrôle de flux. Pas de reprise sur erreur (X.25). La couche Transport: couche 4

* Frontière entre le transport physique des données et le système informatique utilisé, * lien entre les couches basses (1-2-3) et les couches hautes (5-6-7), * responsable du contrôle du transport des informations au travers du réseau. * Opération sur les messages : ⇒ Messages appelés TPDU (Transport Protocol Data Unit), ⇒ segmentation du message en paquets de la taille imposée par le réseau (Ethernet, TR ), ⇒ Envoi des messages concernant plusieurs communications : Multiplexage, ⇒ Maintient en séquence des paquets et des messages : démultiplexage et réassemblage. * La couche Transport identifie de manière unique chacun de ses interlocuteurs : ⇒ En les désignant par son adresse de transport ou TSAP (Transport Service Access Point), ⇒ Les utilisateurs de la couche transport doivent ouvrir des connexions « transport », ⇒ Ces connexions sont déterminées par une association de deux adresses de transport, ⇒ Un service de diffusion doit ouvrir autant de liaisons que de stations à desservir. * Le niveau transport est normalisé, par les recommandations X.214 et X.224, * différents types de protocoles selon les normes (TCP, UDP, NVP), * reçoit des messages SPDU (Session Protocol Data Unit) qu’il peut accepter ou non, * remet à la couche session les messages TSDU corrects, * gère les points d’accès et les flux, * fragmente les messages en paquet NSDU qu’il transmet à la couche réseau, * Ce protocole doit s’adapter à la qualité des services fournis par les couches basses. - Cinq classes de protocoles : couche 4 * classes définies par les organismes ISO8073 ou X224, * cinq classes qui s’adaptent : OFPPT/DRIF

19



Aux services rendus par les trois couches inférieures, ⇒ À la qualité de service qui a pu être demandée par l’utilisateur. * Classe 0 : minimum nécessaire à la réalisation d’un service de transport : ⇒ Pas de multiplexage et pas de reprise d’erreur, ⇒ Mise en place de connexions de transport. ⇒

* Classe 1 : classe de base + reprise sur erreurs signalées par la couche réseaux, ⇒ Transport des données utilisants la segmentation et numérotation des TPDU, 7 ⇒ Format Normal : champ de numérotation sur 7 bits (modulo 2 pour le réassemblage). * Classe 2 : Classe de base + multiplexage + contrôle de flux, ⇒ Pas de reprise sur erreurs signalées, ⇒ Possibilité à plusieurs connexions transport d’emprunter la même connexion réseau, 31 ⇒ Multiplexage : numérotation en format étendu sur 31 bits (modulo 2 ). * Classe 3 : offre les possibilités des classe 1 et 2. * Classe 4 : Classe 3 + propriété de détection d’erreurs avec reprise, ⇒ Reprise sur erreurs non signalées par la couche réseau, ⇒ Opération de récupération pour les TPDU perdues, dupliquées ou hors séquence. La couche session: couche 5

* Normalisée par l’ISO et l’UIT ⇒ IS8326 ou X215 définissent le service orienté connexion rendu par la couche session. ⇒ IS832700 ou X225 spécifiant le protocole session orienté connexion. ⇒ IS9548 définissant un protocole de session dans un mode sans connexion. * Active, synchronise et contrôle le dialogue entre deux taches distantes. * Ouvre et ferme les sessions entre les utilisateurs sans s’intéresser à la transmission. * La session fournit l’authenticité et l’identification des services. * Les contrôles sont assurés par des mécanismes de jetons. La couche presentation: couche 6

* Normalisée par l’ISO et l’UIT : basé sur la syntaxe ASN1 (Abstract Syntaxe Notation 1). ⇒ IS8824 ou X208 définissent la syntaxe ASN1, ⇒ IS8825 ou X209 précisant les règles d’encodage, ⇒ IS 8326, IS8327 et IS9548 définissant la même chose que la couche 5. * Unité présentant les données sous un format compréhensible par l’utilisateur, * Responsable de la présentation des données échangées par des applications afin d’obtenir une compatibilité entre tout matériel raccordé au réseau (hétérogène). La couche d’application : couche 7

* Donne au processus le moyen d’accéder à l’environnement OSI, * normalisé par l’IS9545 ou X207 décrivant sa structure, OFPPT/DRIF

20



* gère l’exécution du processus et le dialogue avec la couche application distante, * s’occupe de la sémantique de l’information et complète la syntaxe déjà réalisée. * Le lien entre les couches 6 et 7 constitue le système d’exploitation (Windows, Unix). - Deux grandes classes d’applications : * Connectés : ⇒ Demande une présence effective des utilisateurs aux 2 extrémités, ⇒ Mode concernant les applications en temps réel tels que les transferts de fichier. * Non-connectés : ⇒ Le temps a peu d’importance, ⇒ Le destinataire peut être remplacé par une boîte aux lettres (Messagerie, Email). - Conclusion : bits-trames-paquets (fragment)-messages-tâches-processus * Toutes les couches ne sont pas nécessairement utilisées, * le passage d’une couche à une autre s’effectue en ajoutant des bits supplémentaires, 3.

Intervention des couches dans un LAN :

Support physiques: couche 1 du modèle OSI

* 10 base 2 : câble coaxial avec répéteur tout les 180m (Ethernet fin), * 10 base T : paire torsadée (Twisted Pair) avec des câbles UTP ou STP, * 10 base F : fibre optique monomode ou multimode. Méthode d’accès au support:

* 802.3 : Méthode Ethernet (débit de 10M à 100Mbps) la plus employée, * 802.5 : Méthode Token-Ring (débit de 4M ou 100Mbps) tend à disparaître, * FDDI : Méthode du jeton sur F0 (>100Mbps sur 100 kms) la plus chère. Protocoles couches basses: couches 3 et 4

* TCP/IP : monde UNIX. * IPX : Monde Novell sous l’environnement Netware. Protocoles couches hautes : couche 5 (FTP, TFTP, Telnet). Applications : couches 6 et 7 (Netscape, Eudora, WS_FTP).

OFPPT/DRIF

21


III.


OUTILS DE DIAGNOSTIC COURANTS

Les réseaux informatiques sont par nature complexes car leur administration demande des compétences sur un grand nombre de domaines. Par ailleurs la multiplicité des protocoles, des systèmes d'exploitation et des équipements rend leur gestion compliquée. Ainsi la plupart des systèmes d'exploitation proposent des outils d'administration réseau rudimentaires permettant d'effectuer les quelques tests indispensables lors de la mise en réseau d'une nouvelle machine ou lors d'une panne globale du réseau, permettant de déterminer d'où proviennent les éventuels problèmes. Il faut métriser ces utilitaires dans un réseau sain et surtout comprendre chaque élément figurant dans leurs résultats pour bien les utiliser dans le diagnostic des problèmes Tester la configuration IP a) Sous Windows : ipconfig 1.

Avant toute chose, il est recommandé de vérifier la configuration IP de l'ordinateur. Les systèmes Windows proposent un outil en ligne de commande, appelé ipconfig permettant de connaître la configuration IP de l'ordinateur. La sortie de cette commande donne la configuration IP pour chaque interface, ainsi un ordinateur possédant deux cartes réseau et un adaptateur sans fil possède 3 interfaces possédant chacun leur propre configuration. Pour visualiser la configuration IP de votre ordinateur, il suffit de saisir la commande suivante (Démarrer / exécuter) : cmd /k ipconfig /all

La sortie d'une telle commande ressemble à ceci : Configuration IP de Windows Nom de l'hôte . . . . . . . . . . : TMSIR

Suffixe DNS principal . . . . . . : Type de nœud . . . . . . . . . . : Diffusion Routage IP activé . . . . . . . . : Non Proxy WINS activé . . . . . . . . : Non Carte Ethernet Connexion réseau sans fil : Suffixe DNS propre à la connexion : Description . . . . . . . . . . . : Intel(R) PRO/Wireless LAN 2100 3A Mini PCI Adapter Adresse physique . . . . . . . . .: 00-0C-F1-54-D5-2C DHCP activé. . . . . . . . . . . : Non Adresse IP. . . . . . . . . . . . : 192.168.1.3 Masque de sous-réseau . . . . . . : 255.255.255.0 Passerelle par défaut . . . . . . : 192.168.1.1 Serveurs DNS . . . . . . . . . . : 193.19.219.210 193.19.219.211 Carte Ethernet Connexion au réseau local : Statut du média . . . . . . . . . : Média déconnecté Description . . . . . . . . . . . : Broadcom 570x Gigabit Integrated Controller Adresse physique . . . . . . . . .: 0F-0F-1F-CB-99-87

OFPPT/DRIF

22



La sortie ci-dessus indique que l'ordinateur possède deux interfaces réseau, dont une sans fil. Le nom de la machine sur le réseau est TMSIR . L'interface Ethernet reliée au réseau local (carte réseau) n'est pas active car le câble est débranché, en revanche l'adaptateur sans fil est configuré. Les machines d'un même réseau doivent utiliser une même plage d'adresses (avec des adresses différentes) et un même masque réseau. Dans le cas d'un réseau local, reliant des machines n'ayant pas d'adresses IP routables, des plages d'adresses dites privées doivent être utilisées. La passerelle par défaut désigne, le cas échéant, l'adresse IP de la machine offrant un accès à internet. Les serveurs DNS doivent correspondre aux serveurs DNS de l'organisation, la plupart du temps il s'agit des serveurs DNS du fournisseur d'accès. b) Sous Linux : ifconfig c) Sous Cisco : show start-up config (ou show running config) 2.

L'outil Ping

Pour tester le bon fonctionnement d'un réseau, il existe un utilitaire très pratique fourni en standard avec la plupart des systèmes d'exploitation, il s'agit de l'utilitaire ping. Ping permet d'envoyer un paquet de donnée à un ordinateur du réseau et permet d'évaluer le temps de réponse. «Ping» (acronyme de Packet INternet Groper ) est sans nul doute l'un des outils d'administration de réseau le plus connu. Il s'agit pourtant de l'un des outils les plus simples puisqu'il permet, grâce à l'envoi de paquets, de vérifier si une machine distante répond et, par extension, qu'elle est accessible par le réseau. Sa mise en œuvre de base nécessite l'ouverture d'une fenêtre invite de commande, comme la plupart des outils de diagnostic réseau. L'outil ping permet ainsi de diagnostiquer la connectivité réseau grâce à une commande du type : ping machine

Machine : représente l'adresse IP de la machine ou bien son nom. Il est généralement préférable dans un premier temps de tester avec l'adresse IP de la machine. a) Fonctionnement de ping Ping s'appuie sur le protocole ICMP, permettant de diagnostiquer les conditions de transmissions. Il utilise ainsi deux types de messages du protocole (sur les 18 proposés par ICMP) :

OFPPT/DRIF

23

Résumé de Théorie et Guide de travaux pratique • •


Le type 0 correspondant à une commande "echo request", émis par la machine source ; Le type 8 correspondant à une commande "echo reply", émis par la machine cible

A intervalles réguliers (par défaut chaque seconde), la machine source (celle sur laquelle la commande ping est exécutée) envoie une commande "echo request" à la machine cible. Dès réception du paquet " echo reply", la machine source affiche une ligne contenant un certain nombre d'informations. En cas de non réception de la réponse, une ligne indiquant "délai dépassé" s'affichera. b) Résultat d'une commande ping Suivant le système d'exploitation, l'affichage de la sortie d'une commande ping pourra être légèrement différent. Voici le résultat d'une telle commande sous un système GNU/Linux : ping www.tmsir.ofppt PING www.tmsir.ofppt (163.5.255.85): 56 data bytes

64 bytes from 163.5.255.85: icmp_seq=0 ttl=56 64 bytes from 163.5.255.85: icmp_seq=1 ttl=56 64 bytes from 163.5.255.85: icmp_seq=2 ttl=56 64 bytes from 163.5.255.85: icmp_seq=3 ttl=56 64 bytes from 163.5.255.85: icmp_seq=4 ttl=56 64 bytes from 163.5.255.85: icmp_seq=5 ttl=56 64 bytes from 163.5.255.85: icmp_seq=6 ttl=56 64 bytes from 163.5.255.85: icmp_seq=7 ttl=56 --- www.tmsir.ofppt ping statistics --8 packets transmitted, 8 packets received, 0% round-trip min/avg/max = 5.3/6.1/7.7 ms

time=7.7 time=6.0 time=5.5 time=6.0 time=5.3 time=5.6 time=7.0 time=6.0

ms ms ms ms ms ms ms ms

packet loss

Voici le résultat d'une telle commande sous un système Windows : ping www.tmsir.ofppt

Envoi d'une requête 'ping' sur www.tmsir.ofppt [163.5.255.85] avec 32 octets de données : Réponse de 163.5.255.85 : octets=32 temps=34 ms TTL=54 Réponse de 163.5.255.85 : octets=32 temps=37 ms TTL=54 Réponse de 163.5.255.85 : octets=32 temps=32 ms TTL=54 Réponse de 163.5.255.85 : octets=32 temps=33 ms TTL=54 Statistiques Ping pour 163.5.255.85 : Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%), Durée approximative des boucles en millisecondes : Minimum = 32ms, Maximum = 37ms, Moyenne = 34ms

La sortie de la commande ping permet ainsi de connaître : • • •

L'adresse IP correspondant au nom de la machine distante ; Le numéro de séquence ICMP ; La durée de vie du paquet ( TTL, Time To Live ). Le champ de durée de vie (TTL) permet de connaître le nombre de routeurs traversés par le paquet lors de l'échange entre les deux machines. Chaque paquet IP possède un champ TTL positionné à une valeur relativement grande. A chaque passage d'un routeur, le champ est décrémenté. S'il arrive que le champ arrive à zéro, le routeur interprétera que le paquet tourne en boucle et le détruira. ;

OFPPT/DRIF

24

Résumé de Théorie et Guide de travaux pratique •

•


Le temps de propagation en boucle (round-trip delay) correspondant à la durée en millisecondes d'un aller-retour entre la machine source et la machine cible. Un paquet doit en règle générale posséder un temps de propagation inférieur à 200 ms ; Le nombre de paquets perdus.

c) Procédure de test de la connectivité avec ping Pour tester le réseau en profondeur, il suffit d'ouvrir une fenêtre de ligne de commande, puis d'effectuer successivement les étapes suivantes : •

ping sur l'adresse de boucle (127.0.0.1), représentant votre ordinateur : ping -t 127.0.0.1

•

ping sur les adresses IP des ordinateurs du réseau, par exemple : ping -t 192.168.0.3

•

ping sur les noms d'ordinateur, par exemple : ping -t Hassan

•

ping sur l'ordinateur servant de passerelle sur le réseau local, c'est-à-dire l'ordinateur partageant sa connexion à internet. Par convention il possède généralement l'adresse 192.168.0.1 : ping -t 192.168.0.1

•

•

•

ping sur la passerelle du fournisseur d'accès. L'adresse de la passerelle du fournisseur d'accès peut être récupéré grâce à la commande ipconfig sur l'ordinateur servant de passerelle sur le réseau local ; ping sur les serveurs de noms du fournisseur d'accès. L'adresse des serveurs DNS du fournisseur d'accès peut être récupéré grâce à la commande ipconfig sur l'ordinateur servant de passerelle sur le réseau local ; ping sur une machine du réseau internet, par exemple : ping -t 193.19.219.210

•

ping sur un nom de domaine, par exemple : ping -t www.tmsir.ofppt

Si tout cela fonctionne, votre réseau est apte à être utilisé ! 3.

L'outil Traceroute

Traceroute est un outil de diagnostic des réseaux, présents sur la plupart des systèmes d'exploitation, permettant de déterminer le chemin suivi par un paquet. La commande traceroute permet ainsi de dresser une cartographie des routeurs présents entre une machine source et une machine cible. La commande traceroute diffère selon les systèmes d'exploitation. OFPPT/DRIF

25

Résumé de Théorie et Guide de travaux pratique •


Sous les systèmes UNIX/Linux (y compris Cisco), la commande traceroute est la suivante : traceroute machine

•

Sous les systèmes Windows, la commande traceroute est la suivante : tracert machine

a) Sortie d'une commande traceroute La commande traceroute fournit une sortie décrivant les noms et adresses IP des routeurs successifs, précédés d'un numéro d'ordre et du temps de réponse minimum, moyen et maximum : Détermination de l'itinéraire avec un maximum de 30 sauts : 1 33 ms 32 ms 33 ms [81.57.234.254] 2 33 ms 33 ms 33 ms [213.228.4.254] 3 33 ms 33 ms 33 ms [212.27.50.46] 4 33 ms 33 ms 33 ms [212.27.50.41] 5 32 ms 34 ms 34 ms [212.27.50.34] 6 34 ms 32 ms 33 ms [213.228.15.67] 7 35 ms 35 ms 35 ms 8 36 ms 36 ms 35 ms [130.117.16.22] 9 36 ms 36 ms 36 ms 10 34 ms 34 ms 35 ms 11 36 ms 35 ms 37 ms 12 36 ms 36 ms 36 ms

vers www.tmsir.ofppt [163.5.255.85] raspail-2-81-57-234-254.fbx.proxad.net vlq-6k-2-a5.routers.proxad.net vlq-6k-2-v802.intf.routers.proxad.net th1-6k-2-v806.intf.routers.proxad.net cbv-6k-2-v802.intf.routers.proxad.net ldc-6k-1-a0.routers.proxad.net cogent.FreeIX.net [213.228.3.187] NeufTelecom.demarc.cogentco.com V3994.c1cbv.gaoland.net [212.94.162.209] V4080.core3.cbv.gaoland.net [212.94.161.129] 212.94.164.210 nestor.www.tmsir.ofppt [163.5.255.85]

Itinéraire déterminé.

b) Fonctionnement de traceroute Traceroute appuie son fonctionnement sur le champ TTL des paquets IP. En effet chaque paquet IP possède un champ durée de vie ( TTL, Time To Live ) décrémenté à chaque passage d'un routeur. Lorsque ce champ arrive à zéro, le routeur, considérant que le paquet tourne en boucle, détruit ce paquet et envoie une notification ICMP à l'expéditeur. Ainsi, traceroute envoie des paquets à un port UDP non privilégié, réputé non utilisé (le port 33434 par défaut) avec un TTL valant 1. Le premier routeur rencontré va supprimer le paquet et renvoyer un paquet ICMP donnant notamment l'adresse IP du routeur ainsi que le temps de propagation en boucle. Traceroute va ainsi incrémenter séquentiellement le champ durée de vie, de manière à obtenir une réponse de chacun des routeurs sur le chemin, jusqu'à obtenir une réponse « port ICMP non atteignable» (« ICMP port unreachable») de la part de la machine cible. 4.

L'outil Netstat

OFPPT/DRIF

26



Netstat est un outil permettant de connaître les connexions TCP actives sur la machine sur laquelle la commande est activée et ainsi lister l'ensemble des ports TCP et UDP ouverts sur l'ordinateur. La commande « netstat » permet également d'obtenir des statistiques sur un certain nombre de protocoles (Ethernet, IPv4, TCP, UDP, ICMP et IPv6). a) Paramètres de la commande netstat Utilisée sans aucun argument, la commande netstat affiche l'ensemble des connexions ouvertes par la machine. La commande netstat possède un certain nombre de paramètres optionnels, sa syntaxe est la suivante : netstat [-a] [-e] [-n] [-o] [-s] [-p PROTO] [-r] [intervalle]

Utilisée avec l'argument -a, la commande netstat affiche l'ensemble des connexions et des ports en écoute sur la machine. Utilisée avec l'argument -e, la commande netstat affiche les statistiques Ethernet. Utilisée avec l'argument -n, la commande netstat affiche les adresses et les numéros de port en format numérique, sans résolution de noms. Utilisée avec l'argument -o, la commande netstat détaille le numéro du processus associé à la connexion. Utilisée avec l'argument -p suivi du nom du protocole (TCP, UDP ou IP), la commande netstat affiche les informations demandées concernant le protocole spécifié. Utilisée avec l'argument -r , la commande netstat permet d'afficher la table de routage. Utilisée avec l'argument -s, la commande netstat affiche les statistiques détaillées par protocole. Enfin un intervalle optionnel permet de déterminer la période de rafraîchissement des informations, en secondes. Par défaut ce paramètre vaut 1 seconde. 5.

L'outil nslookup

Nslookup ( Name System Look Up ) est un outil permettant d'interroger un serveur de noms afin d'obtenir les informations concernant un domaine ou un hôte et permet ainsi de diagnostiquer les éventuels problèmes de configuration du DNS. Invoqué sans argument, la commande nslookup affiche le nom et l'adresse IP du serveur de noms primaire et affiche une invite de commande pour l'interrogation. Il suffit de taper le nom d'un domaine à l'invite afin d'en afficher les caractéristiques. Il est également possible de demander les informations sur un hôte en indiquant son nom à la suite de la commande nslookup : OFPPT/DRIF

27



nslookup host.name

Par défaut la commande nslookup interroge le serveur de noms primaire configuré sur la machine. Il est toutefois possible d'interroger un serveur de noms spécifique en le spécifiant à la suite de la commande précédé du signe "-" : nslookup host.name -serveur.de.nom

Il est possible de modifier le mode d'interrogation de la commande nslookup grâce à la clause set : •

•

•

• • •

set type=mx permet de recueillir les informations concernant le ou les serveurs de messagerie d’un domaine. set type=ns permet de recueillir les informations concernant le serveur de noms associé au domaine set type=a permet de recueillir les informations concernant un hôte du réseau. Il s'agit du mode d'interrogation par défaut. set type=soa permet d'afficher les informations du champ SOA (Start Of Authority ). set type=cname permet d'afficher les informations concernant les alias. set type=hinfo permet, lorsque ces données sont renseignées, d'afficher les informations concernant le matériel et le système d'exploitation de l'hôte.

Pour sortir de la commande nslookup , il suffit de taper exit . 6.

L’outil ARP

ARP est un protocole clé de TCP/IP utilisé pour déterminer l'adresse physique correspondant à une adresse IP. Chaque machine située sur un réseau TCP/IP maintient un cache ARP : Une table de correspondance entre les adresses IP et les adresses physiques. La commande arp permet de visualiser le contenu de la machine locale ou d'une autre machine. Les entrées dans le cache ARP sont, par défaut, dynamiques. Les entrées du cache commencent à expirer dès lors qu'elles sont entrées. Ne soyez pas surpris qu'il n'y ait pas ou peu d'entrées dans le cache ARP 1.

L’outil Telnet

a) Présentation de Telnet Telnet est un protocole permettant d'émuler un terminal à distance, cela signifie qu'il permet d'exécuter des commandes saisies au clavier sur une machine distante. L'outil Telnet est une implémentation du protocole Telnet, cela signifie qu'il s'agit de la traduction des spécifications en langage informatique pour créer un programme permettant d'émuler un terminal. Telnet fonctionne dans un environnement client/serveur, c'est-à-dire que la machine distante est configurée en serveur et par conséquent attend qu'une machine lui demande un service. Ainsi, étant donné que la machine distante envoie les données à afficher, l'utilisateur a l'impression de travailler directement sur la machine distante. Sous UNIX, le service est OFPPT/DRIF

28



fourni par ce que l'on appelle un démon, une petite tâche qui fonctionne en arrière-plan. Le démon Telnet s'appelle Telnetd . b) Protocole et implémentation Telnet est aussi un protocole, c'est-à-dire un ensemble de règles et de procédures qui ont été définies afin de standardiser la communication sous Telnet. Ainsi, Telnet a rapidement été implémenté (adapté à partir des spécifications du protocole) sous de nombreuses plateformes. c) Exécution de Telnet Telnet est fourni en standard sous diverses plateformes, dont UNIX, Windows95, WindowsNT, Linux... La commande pour initier une session Telnet est généralement la suivante : telnet nom_du_serveur nom_du_serveur représente

bien évidemment le nom de la machine distante à laquelle on désire se connecter. Il est aussi possible de donner son adresse IP, par exemple : telnet 125.64.124.77 Enfin il est également possible de préciser le port à utiliser en faisant suivre l'adresse IP ou le nom du serveur par le numéro de port : telnet 125.64.124.77 80 d) Commandes sous Telnet Une fois que vous vous connectez à la machine distante, un nom d'utilisateur (login) et un mot de passe (password) vous seront demandés pour des raisons de sécurité afin de restreindre l'accès aux seules personnes autorisées. En effet, Telnet est un protocole puissant puisqu'il permet l'exécution de commandes à distance. Les commandes pouvant être exécutées sous une session Telnet sont définies par l'administrateur réseau. Il s'agit généralement de commandes UNIX étant donné que la plupart des serveurs Telnet fonctionnent sous UNIX. Les commandes standard sont les suivantes :

Commande Description ? Affiche l'aide close Termine la session Telnet display Affiche à l'écran les paramètres de la connexion (type de terminal, port) environ Permet de définir les variables d'environnement du système d'exploitation logout Permet de se déconnecter Bascule entre les modes de transfert ASCII (transfert d'un fichier en mode texte) mode et BINARY (transfert d'un fichier en binaire) open Permet de lancer une autre connexion à partir de la connexion en cours quit Quitte l'application Telnet OFPPT/DRIF

29


set unset 2.


Modifie les paramètres de la connexion Charge les paramètres de connexion par défaut TP découverte

1. Créer une maquette constituée de plusieurs routeurs, switchs et postes de travail, 2. .Ajouter au minimum un serveur DHCP et un serveur DNS. 3. Tester et analyser toutes les commandes étudiées ci-dessus.

OFPPT/DRIF

30


IV.


METHODOLOGIE PRATIQUE SIMPLE 1.

Utilisation d’une approche structurée du dépannage

Le dépannage est un processus qui permet à un utilisateur de localiser les problèmes sur un réseau. Ce processus de dépannage devrait être basé sur des normes de gestion de réseau mises en place par un administrateur réseau. La création d’une documentation est très importante pour le processus de dépannage. Les étapes de ce modèle sont les suivantes: Étape 1:

Collecte de toutes les données disponibles et analyse des causes d’échec

Étape 2:

Localisation du problème au sein d’un segment de réseau, d’une unité ou d’un module, ou au niveau utilisateur

Étape 3:

Imputation du problème à un matériel ou à un logiciel spécifique au sein de l’unité, du module ou du compte réseau d’un utilisateur

Étape 4:

Recherche et correction du problème

Étape 5:

Confirmation de la résolution du problème

Étape 6:

Rédaction d’une documentation sur le problème et sa solution

La figure illustre une autre approche du dépannage. Le dépannage ne se limite pas à ces deux méthodes. Toutefois, le recours à un processus structuré est d’une importance capitale pour le fonctionnement efficace et sans coupure d’un réseau.

OFPPT/DRIF

31



Par le biais d’une approche structurée du dépannage, chaque membre d’une équipe de support de réseau peut connaître les opérations que chacun a réalisées pour résoudre un problème. Si diverses solutions de dépannage sont testées sans aucune organisation ni documentation, la résolution des problèmes n’est pas efficace. Même si un problème est résolu dans le cadre d’une approche non structurée, il sera probablement impossible de reproduire la solution lorsque des problèmes similaires surviendront ultérieurement 2.

TP0

Tp0

OFPPT/DRIF

32


V.


PROBLEMES ET SOLUTIONS SELON OSI

Test sur la base des couches OSI : La phase de test doit commencer au niveau de la couche 1 du modèle OSI, jusqu’à la couche 7 si nécessaire. 1.

La couche 1 a) Problèmes de la couche 1

Les erreurs identifiées au niveau de la couche 1 peuvent être les suivantes: Câbles rompus Câbles déconnectés Câbles raccordés à des ports inappropriés Connexions instables Câbles inappropriés pour la tâche à accomplir (les câbles console, les câbles croisés et les câbles droits doivent être employés à bon escient) Problèmes d’émetteur-récepteur Problèmes de câblage ETCD Problèmes de câblage ETTD Unités hors tension

• • • • •

• • • •

b) Dépannage de la couche 1 -

Dépannage de la couche 1 à l’aide des témoins lumineux :

Les témoins lumineux sont utiles au dépannage. La plupart des interfaces ou des cartes réseau comportent des témoins lumineux qui indiquent si la connexion est valide. Ces témoins lumineux sont souvent appelés voyants de liaison. L’interface peut également disposer de témoins lumineux pour indiquer si le trafic est en cours de transmission (TX) ou reçu (RX). Si l’interface comporte des témoins lumineux indiquant que la connexion n’est pas valide, mettez l’unité hors tension et replacez la carte d’interface. Un voyant de liaison peut également indiquer une mauvaise connexion ou l’absence de liaison à cause d’un câble inapproprié ou défectueux. Vérifiez que tous les câbles sont connectés aux ports appropriés. Vérifiez que toutes les interconnexions sont raccordées au bon emplacement à l’aide du câble et de la méthode appropriés. Vérifiez que tous les ports de concentrateur et de commutateur sont associés au réseau VLAN ou au domaine de collision approprié, et que les options de Spanning Tree correspondantes, entre autres, sont définies correctement. Vérifiez que le câble approprié est utilisé. Un câble croisé peut être requis pour des connexions directes entre deux commutateurs ou concentrateurs, ou entre deux hôtes, tels que des PC ou des routeurs. Vérifiez que le câble de l’interface source est correctement connecté et en bon état. En cas de doute sur la connexion, replacez le câble et vérifiez la sécurité de la connexion. Essayez de remplacer le câble par un câble de travail connu. Si ce câble est connecté à une prise murale, utilisez un testeur de câble pour vérifier que la prise est correctement raccordée.

OFPPT/DRIF

33



Vérifiez également le type, la connexion et la configuration de tout émetteur-récepteur utilisé. Si le remplacement du câble ne résout pas le problème, essayez de remplacer l’émetteurrécepteur si vous en utilisez un. Assurez-vous également que l’unité est bien sous tension. Contrôlez toujours les composants de base avant d’exécuter des diagnostics ou de tenter un dépannage plus complexe. -

Les problèmes de média :

Un problème de Hub, de Switch, de câble n'est pas réellement un problème TCP/IP. Cependant, vous pouvez encore utiliser des utilitaires de diagnostic TCP/IP pour détecter des problèmes de média. En général, si le réseau s'arrête brusquement, un problème de média en est sûrement la cause. Assurez-vous que tous les câbles réseau sont correctement enfichés. Les cartes réseau, les Hubs, les switches, les routeurs disposent de LED indiquant que l'équipement est en service et prêt à recevoir des données. Tester le câblage réseau avec un contrôleur ou un testeur de câble tel que FlukNetwork ou autres Utiliser l'utilitaire ping pour isoler les problèmes de média.

• •

•

•

Si une machine peut "lancer un Ping sur sa propre adresse, mais pas d'autres adresses du réseau, le défaut se situe dans le segment de câble connectant la machine au sous-réseau local. c) TP dépannage de la couche 1

Tp1 2.


Les erreurs identifiées au niveau de la couche 2 peuvent être les suivantes: Interfaces série configurées de façon incorrecte Interfaces Ethernet configurées de façon incorrecte Ensemble d’encapsulation inapproprié (HDLC est utilisé par défaut pour les interfaces série sous Cisco) Fréquence d’horloge inappropriée pour les interfaces série Problèmes de carte réseau (NIC)

• • •

• •

b) Dépannage de la couche 2



Dépannage de la liaison série (cas Cisco) -

OFPPT/DRIF

Présentation des communications série

34



Les technologies des réseaux WAN s'appuient sur une transmission série au niveau de la couche physique. Cela signifie que les bits d'une trame sont transmis un par un sur le support physique. Parmi les nombreuses normes de communication série, on trouve les suivantes: RS-232-E V.35 HSSI (High Speed Serial Interface

• • •

-

ETCD/ETTD

Une connexion série comporte un équipement terminal de traitement de données (ETTD) à une extrémité de la connexion et un équipement de communication de données (ETCD) à l'autre extrémité. La connexion entre les deux ETCD est le réseau de transmission du fournisseur du réseau WAN. Le CPE, généralement un routeur, constitue l'ETTD. Il peut également s'agir d'un terminal, d'un ordinateur, d'une imprimante ou d'un télécopieur. L'ETCD, généralement un modem ou une unité CSU/DSU, est l'équipement servant à convertir les données utilisateur de l'ETTD en une forme compatible avec la liaison de transmission du fournisseur d'accès au WAN. Le signal est reçu par l'ETCD distant, qui le décode en une séquence de bits. Cette séquence est ensuite signalée à l'ETTD. Le port série synchrone d'un routeur est configuré comme ETTD ou ETCD en fonction du câble qui y est relié, commandé comme ETTD ou ETCD pour correspondre à la configuration du routeur. Si le port est configuré en ETTD, le réglage par défaut, une horloge externe est requise au niveau de l'unité CSU/DSU ou d'un autre équipement ETCD -

Protocole HDLC

Cisco HDLC est la méthode d'encapsulation par défaut utilisée par les équipements Cisco sur des lignes série synchrones. Si l'interface série est configurée avec un autre protocole d'encapsulation et que l'encapsulation doit être replacée en HDLC, accédez au mode de configuration de l'interface série. Entrez ensuite la commande encapsulation hdlc pour spécifier le protocole d'encapsulation de l'interface. Cisco HDLC est un protocole point-à-point pouvant être utilisé sur des lignes louées entre deux équipements Cisco. Pour communiquer avec un équipement d'une autre marque que Cisco, le PPP synchrone constitue une option plus viable. -

OFPPT/DRIF

Dépannage d'une interface série 35



Les résultats de la commande show interfaces serial présentent des informations spécifiques aux interfaces série. Quand HDLC est configuré «Encapsulation HDLC» doit apparaître dans les résultats. Quand PPP est configuré, «Encapsulation PPP» doit apparaître dans les résultats. Cinq états de problème possibles peuvent être identifiés sur la ligne d'état de l'interface affichée par show interfaces serial: 1. L'interface série x est désactivée et le protocole de ligne est désactivé (Serial x is down, line protocol is down) 2. L'interface série x est activée et le protocole de ligne est désactivé 3. L'interface série x est activée et le protocole de ligne est activé (en boucle) 4. L'interface série x est activée et le protocole de ligne désactivé 5. L'interface série x est désactivée pour des raisons d'administration (administratively down) et le protocole de ligne est désactivé La commande show controllers est un autre outil de diagnostic important pour le dépannage des lignes série. Les résultats renvoyés par show controllers indiquent l'état des canaux de l'interface et signalent la présence ou l'absence d'un câble Des commandes de débogage, utiles pour résoudre les problèmes d''interface série et de WAN, sont présentées ci-dessous: debug serial interface – Vérifie si les paquets de veille HDLC s'incrémentent. S'ils ne s'incrémentent pas, il existe probablement un problème de synchronisation sur la carte d'interface ou le réseau. debug arp – Indique si le routeur envoie ou reçoit des informations relatives aux routeurs (avec des paquets ARP) de l'autre côté du nuage de réseau WAN. Utilisez cette commande quand certains nœuds d'un réseau TCP/IP répondent, mais d'autres non. debug frame-relay lmi – Récupère des informations sur l'interface LMI (Local Management Interface), afin de déterminer si un commutateur Frame Relay et un routeur envoient et reçoivent des paquets LMI. debug frame-relay events – Détermine si des échanges se produisent entre un routeur et un commutateur Frame Relay. debug ppp negotiation – Montre les paquets PPP ( Point-to-Point Protocol ) transmis au démarrage de PPP, au moment où les options PPP sont négociées. debug ppp packet – Montre les paquets PPP envoyés et reçus. Cette commande affiche les transferts de paquets à bas niveau. debug ppp – Montre les erreurs PPP, telles que les trames illégales ou déformées, associées à la négociation et à l'utilisation de la connexion PPP. debug ppp authentication – Montre les échanges de paquets PPP CHAP (Challenge Handshake Authentication Protocol ) et PAP ( Password Authentication Protocol ).

•

•

•

•

•

•

•

•

-

OFPPT/DRIF

Le protocole PPP

36



Les aspects configurables de PPP incluent les méthodes d'authentification, la compression, la détection d'erreurs et la prise en charge ou non de la multiliaison. La section ci-après décrit les différentes options de configuration de PPP : 

Configuration de PPP

L'exemple suivant permet l'encapsulation de PPP sur l'interface série 0/0: Router#configure terminal Router(config)#interface serial 0/0 Router(config-if)#encapsulation ppp 

Configuration de l’authentification PPP



Les étapes pour configurer

OFPPT/DRIF

37





Dépannage de la configuration de l'encapsulation série

La commande debug ppp authentication affiche la séquence d'échange d'authentification.

La figure illustre les résultats renvoyés par le routeur de gauche au cours de l'authentification CHAP avec le routeur de droite, quand debug ppp authentication est activée. Lorsque l'authentification bidirectionnelle est configurée, chaque routeur authentifie l'autre. Des messages s'affichent pour le processus authentifiant et le processus authentifié. Utilisez la

OFPPT/DRIF

38



commande debug ppp authentication pour afficher la séquence d'échange au moment où elle se produit.

La figure présente les résultats renvoyés par le routeur pour une authentification PAP bidirectionnelle. La commande debug ppp sert à afficher des informations sur le fonctionnement de PPP. La forme no de cette commande désactive l’affichage du message de débogage. Router#debug ppp {authentication | packet | negotiation | error | chap} Router#no debug ppp {authentication | packet | negotiation | error | chap} Travail à domicile : si vous êtes curieux essayer de décrire les étapes de dépannage des autres protocoles de la couche 2 : Frame Relay… c) TP dépannage de la couche 2

Tp2 3.


Les erreurs identifiées au niveau de la couche 3 peuvent être les suivantes: Protocole de routage non activé Protocole de routage incorrect activé Adresses IP incorrectes Masques de sous-réseau incorrects

• • • •

Si des erreurs apparaissent sur le réseau, le processus de test basé sur les couches OSI doit être déclenché. La commande ping est utilisée pour tester la connectivité au niveau de la couche 3. NB : La commande telnet peut être utilisée au niveau de la couche 7 pour vérifier le logiciel de la couche application entre des stations source et de destination. b) Dépannage de la couche 3 -

OFPPT/DRIF

Dépannage de la couche 3 à l’aide de la commande ping 39



La commande ping utilise le protocole ICMP (Internet Control Message Protocol) pour vérifier la connexion matérielle et l’adresse logique au niveau de la couche réseau.

Le tableau de la figure indique les différents types de message ICMP. Il s’agit d’un mécanisme de test des plus élémentaires pour la connectivité du réseau.

OFPPT/DRIF

40



Dans la figure, la cible 172.16.1.5 de la commande ping a répondu correctement aux cinq datagrammes envoyés. Il est intéressant d’utiliser la commande ping lorsque le réseau fonctionne correctement pour voir comment s’exécute cette commande dans des conditions normales et disposer d’un modèle de comparaison lors du dépannage. c) TP dépannage de la couche 3

Tp3

OFPPT/DRIF

41


VI. 1.


DEPANNAGE DE COUCHE 4 et PLUS Dépannage avec Telnet

L’utilitaire Telnet est un protocole de terminal virtuel qui fait partie de la pile de protocoles TCP/IP. Il permet de vérifier le logiciel de la couche application entre les stations d’origine et de destination. Il s’agit du mécanisme de test le plus complet qui soit. L’utilitaire Telnet est normalement utilisé pour connecter des unités distantes, collecter des informations et exécuter des programmes. L’application Telnet fournit un terminal virtuel pour la connexion aux routeurs exécutant TCP/IP. Dans le cadre du dépannage, il est utile de vérifier qu’une connexion peut être établie à l’aide de Telnet. Cela prouve qu’au moins une application TCP/IP est capable d’établir une connexion de bout en bout. Une connexion Telnet réussie indique que l'application de couche supérieure, ainsi que les services des couches inférieures, fonctionnent correctement. Si un administrateur peut envoyer une commande Telnet à un routeur mais pas à un autre, vérifiez la connectivité au niveau des couches inférieures. Si la connectivité a été vérifiée, l'échec de Telnet est vraisemblablement dû à des problèmes spécifiques d'adressage, d’attribution de noms ou d'autorisation d'accès. Ces problèmes peuvent exister sur le routeur de l’administrateur ou sur celui que vous avez tenté d’atteindre via Telnet. Si une commande Telnet vers un serveur donné échoue à partir d’un hôte, essayez de vous connecter à partir d’un routeur et de plusieurs autres unités. Lors des tentatives de connexion via Telnet, si aucune invite de connexion n’apparaît, vérifiez ce qui suit: •

•

•

2.

Une recherche DNS inverse sur l’adresse du client peut-elle être trouvée ? De nombreux serveurs Telnet n’autorisent pas les connexions à partir d’adresses IP qui ne disposent pas d’entrées DNS. Il s’agit d’un problème fréquent pour les adresses DHCP dans lesquelles l’administrateur n’a pas ajouté d’entrées DNS pour les groupes DHCP. Il est possible qu’une application Telnet ne puisse pas négocier les options appropriées et ne se connecte donc pas. NB : Sur un routeur Cisco, ce processus de négociation peut être visualisé à l’aide de la commande debugtelnet. Il est possible que l’utilitaire Telnet soit désactivé ou ait été déplacé vers un port autre que 23 sur le serveur de destination.

TP4

Tp4

OFPPT/DRIF

42


VII.


ANALYSEURS DE PROTOCOLE (DEPANNAGE DE LOGICIELS)

Ce sont des outils de diagnostic des flux de trames échangés sous un protocole donné. Un analyseur, ou analyseur de protocole, est un outil qui permet à un administrateur de réseau d'examiner les trames échangées entre deux dispositifs de réseau à des fins d'investigation (en cas d'affaiblissement des débits, notamment). L'analyseur est dit "de protocole", parce que pour intercepter, décoder et analyser une trame, il faut savoir de quel protocole elle relève. Ce logiciel s'exécute sur un micro-ordinateur et ne peut "voir" que les trames des protocoles de haut niveau gérées par la carte réseau de l'ordinateur. Les analyseurs qui permettent de descendre aux plus basses couches d'un réseau (voir Modèle OSI) comportent une partie matérielle : une sonde que l'on place entre les deux dispositifs dont on veut contrôler le dialogue et qui procède au décodage des trames, pour examen ultérieur à l'aide du logiciel approprié (la sonde peut comporter un disque dur). 1.

Analyseur et inspecteur de réseaux

Un « analyseur réseau » (appelé également analyseur de trames ou en anglais sniffer, traduisez « renifleur ») est un dispositif permettant d'« écouter » le trafic d'un réseau, c'est-àdire de capturer les informations qui y circulent. En effet, dans un réseau non commuté, les données sont envoyées à toutes les machines du réseau. Toutefois, dans une utilisation normale les machines ignorent les paquets qui ne leur sont pas destinés. Ainsi, en utilisant l'interface réseau dans un mode spécifique, il est possible d'écouter tout le trafic passant par un adaptateur réseau (une carte réseau ethernet, une carte réseau sans fil, etc.). 2.

Utilisation de composants logiciels pour capture de trames via une interface réseau a) Machine de type Unix : logiciel Ethereal

A- Installation du logiciel sur une distribution (exemple Redhat ) Il faut installer les deux paquetages rpm ethereal & ethereal gnome (visualisation via le GUI Gnome) se trouvant dans le menu Système, rubrique Outils de système. Après installation, vous pourrez lancer celui dans le menu Internet + Applications supplémentaires+ Ethereal (il vous sera demandé de spécifier l’interface réseau (ethx) que vous voulez « écouter ») B- Utilisation du logiciel -

Capture d’une série de trames

Après avoir lancé le logiciel Ethereal, suivre la séquence suivante pour capturer une série de 60 trames 1. Sélectionner Capture puis Start. 2. Entrer le nombre de trames à capturer dans la case Stop capture after. 3. Cliquer OK . OFPPT/DRIF

43

Résumé de Théorie et Guide de travaux pratique -


Analyse d’une capture

Vous obtenez après arrêt de la capture, l’écran suivant :

-

Filtrage d’une série

Une étape importante de l’analyse des flux réseau consiste à isoler un échange au milieu du trafic de l’ensemble du réseau. Cette opération est réalisée par filtrage en appliquant des règles avant ou après la capture. 

Avant capture

Ethereal reprend la syntaxe de filtrage d’un autre outil très connu : tcpdump. La documentation complète sur cette syntaxe s’obtient en tapant man tcpdump à la console Pour spécifier le type de paquets que l’on veut capturer, il suffit donc de saisir un filtre dans la case Filter: de la fenêtre Capture. Par exemple, pour ne capturer que les paquets IP il faut saisir : ip. 

Après capture

Une fois la capture terminée, il est possible d’isoler par filtrage les paquets transmis par une station. Isoler les paquets émis par un hôte

OFPPT/DRIF

44



1. Dans la fenêtre de capture, sélectionner un paquet émis ou reçu par la station recherchée avec le bouton gauche de la souris. 2. Dans la fenêtre de trame, développer le niveau Internet Protocol et pointer l’adresse de la station. 3. Cliquer sur le bouton droit de la souris et sélectionner Match selected. La fenêtre de capture n’affiche plus que les paquets où l’adresse de la station recherchée est présente. Isoler une connexion TCP

1. Dans la fenêtre de capture, sélectionner un message émis ou reçu par la station recherchée avec le bouton droit de la souris. 2. Sélectionner Follow TCP stream Une nouvelle fenêtre apparaît. Elle contient les données vues de la couche Transport. La fenêtre de capture n’affiche plus que les paquets correspondant à la connexion TCP : établissement, transfert et libération de connexion. Exercice : analyse d’une capture de trame lié au protocole ARP

-

A l’aide de la figure ci-dessus, répondez aux questions suivantes : Détail Ethernet : 1. 2. 3. 4.

L'adresse de destination est-elle une adresse physique ? Quelle est l'adresse source ? Quel est le type de trame Ethernet ? Quel est le protocole encapsulé ?

Détail Arp : OFPPT/DRIF

45


5. 6. 7. 8. 9.


Quelle est l'adresse matérielle de l'expéditeur ? Quelle est l'adresse de protocole de l'expéditeur ? Quelle est l'adresse matérielle de la cible ? Quelle est l'adresse de protocole de la cible ? Pourquoi l'adresse matérielle de la cible contient des ff ?

b) Machine de type Windows 200x Server : logiciel Moniteur réseau

A- Installation du Moniteur réseau sous Windows 200x Server Vous devez au préalable installer le composant pilote de moniteur réseau permettant au niveau de l’interface réseau considérée, de rediriger les trames vers le Moniteur réseau. Pour cela il faut installer le protocole «Pilote de moniteur réseau» pour votre (vos) interface(s) réseau. Ensuite, vous devez installer le programme qui est un composant de Windows 2000, rubrique Outils de gestion & d’analyse et sélectionner Outils d’analyse réseau. Via vos outils d’administration, pouvez dorénavant utiliser le Moniteur réseau. B- Utilisation du logiciel -

Capture de trames

Via l’icône , vous lancer votre capture. Pour arrêter la capture, il faut que vous cliquiez sur l’icône . -

Analyse d’une capture

Dès que le Moniteur réseau a capturé des trames, vous pouvez utiliser la fenêtre de l'Observateur de trames pour afficher leur contenu. Vous pouvez afficher les informations capturées dans la fenêtre de l'Observateur de trames :  en 

cliquant sur Arrêter et afficher dans le menu Capture pendant la capture des données ; en ouvrant un fichier de capture (.cap) existant. Pour ce faire, dans la fenêtre de capture ou la fenêtre de l'Observateur de trames, dans le menu Fichier, cliquez sur Ouvrir.

Pour activer l'affichage d'un volet de la fenêtre de l'Observateur de trames, sélectionnez le volet. L'utilisation de l'option Zoom du menu Fenêtre entraîne l'affichage plein écran du volet sélectionné dans la fenêtre de l'Observateur de trames. Pour rétablir la taille normale du volet, cliquez sur Zoom sur le volet dans le menu Fenêtre. La fenêtre de l'Observateur de trames comporte trois volets : Volet

Affiche

Détail

Contenu de la trame, y compris les protocoles utilisés pour l'envoyer.

Hex

Représentations hexadécimales et ASCII des données capturées.

OFPPT/DRIF

46



Résumé Informations générales relatives aux trames capturées dans l'ordre de leur capture. L'illustration suivante montre les éléments clés de la fenêtre de l'Observateur de trames.

Lorsque vous affichez une capture dans la fenêtre de l'Observateur de trames, la capture porte la mention « Capture », suivie du numéro identifiant l'ordre des fenêtres de capture actives. Lorsque vous ouvrez un fichier de capture (.cap) précédemment enregistré, la barre de titre affiche le chemin d'accès au fichier de capture. -

Filtrage

Via le menu Filtrage (touche F8) vous obtenez l’écran suivant:

OFPPT/DRIF

47



Pour réaliser un ou plusieurs filtres voici un ensemble d’informations fournies par la société Microsoft. Les commandes suivantes vous permettront d'effectuer des modifications dans l'arbre de décision du filtre d'affichage. Protocole == Branche de l'arbre de décision qui répertorie les protocoles que vous souhaitez afficher. Par défaut, cette branche a pour valeur Protocole == N'importe lequel. Pour modifier la liste des protocoles, double-cliquez sur la branche afin d'ouvrir la boîte de dialogue Expression. adresse

<-> adresse

Branche de l'arbre de décision qui répertorie les paires d'adresses d'ordinateurs que vous souhaitez afficher. Par défaut, cette branche a pour valeur N'importe laquelle <-> N'importe laquelle. Pour modifier la liste des paires d'adresses, double-cliquez sur la branche pour ouvrir la boîte de dialogue Expression. Ajouter Critères de l'arbre de décision. Expression Cliquez pour ouvrir la boîte de dialogue Expression que vous pouvez utiliser pour spécifier les paires d'adresses d'ordinateurs, les protocoles, ainsi que les propriétés de protocole que vous souhaitez afficher. Insérer Opérateurs logiques de l'arbre de décision. Vous pouvez utiliser jusqu'à 4 000 opérateurs d'arbre de décision. ET Cliquez pour ajouter une branche ET à la branche actuellement sélectionnée de l'arbre de décision. OU Cliquez pour ajouter une branche OU à l'arbre de décision. NON Cliquez pour ajouter une branche NON à l'arbre de décision, ou pour nier une branche de l'arbre. Modifier l'expression (Changer d'opérateur) Si vous sélectionnez une expression dans l'arbre de décision, l'étiquette figurant sur le bouton de ce groupe est Modifier l'expression. Cliquez sur ce bouton pour ouvrir la boîte de dialogue Expression que vous pouvez utiliser pour modifier les données sélectionnées. Si vous sélectionnez un opérateur logique dans l'arbre de décision, l'étiquette figurant sur le bouton de ce groupe est Changer d'opérateur. Cliquez sur ce bouton pour faire défiler les opérateurs logiques proposés pour la ligne sélectionnée. Supprimer Critères de décision que vous souhaitez supprimer de l'arbre. Ligne Cliquez pour supprimer la ligne sélectionnée de l'arbre de décision. OFPPT/DRIF

48



Branche Cliquez pour supprimer la branche actuellement sélectionnée de l'arbre de décision. Toutes Cliquez pour supprimer la totalité de l'arbre de décision. Charger Cliquez pour ouvrir la boîte de dialogue Ouvrir que vous pouvez utiliser pour remplacer le filtre d'affichage actif par un filtre d'affichage précédemment enregistré dans un fichier. Enregistrer Cliquez pour ouvrir la boîte de dialogue Enregistrer le filtre d'affichage que vous pouvez utiliser pour enregistrer le filtre d'affichage actif en tant que fichier (.df). Pour ouvrir ce filtre d'affichage ultérieurement, vous pourrez cliquer sur le bouton Charger afin d'ouvrir le fichier. Exemple: filtrage des échanges DNS Situation: On veut obtenir tous les échanges DNS entre notre station «Locale» et l’extérieur Les actions de filtrages à appliquer sont: Protocoles: DNS (uniquement) pour cela, il suffit de désactiver tous les protocoles puis de n’accepter que DNS Adresses :

Station 1: Local

Station 2 : ANY

Nous devons avoir l’écran suivant, après mise en place des filtrages:

c) TP5

Tp5

OFPPT/DRIF

49


VIII.


UTILISER LES OUTILS D’ANALYSE ET DE SURVEILLANCE

L’administration des grands réseaux se heurte à trois problématiques qui sont : La correction des erreurs. L’exploitation à distance. La complexité qui croît avec la taille du réseau. La correction des erreurs est difficile car le diagnostic doit se faire en considérant de nombreux paramètres stockés sur de nombreux matériels qui peuvent de plus être disséminés partout dans le monde. Dans la plupart du temps la correction qui donne suite au diagnostic devra se faire sur un site éloigné (remote). Considérant les contraintes précédentes, il n’est pas envisageable de déplacer les équipes réseaux et une exploitation à distance des réseaux s’avère indispensable. Cette exploitation va devoir s’effectuer sur un nombre important de moyens de transmission mais amène des économies importantes pour les grands réseaux. Gérer et superviser à distance un grand réseau est complexe et cette complexité va croître avec la taille du réseau. Des logiciels et des dispositifs installés sur les différents matériels vont aider l’administrateur dans cette tâche. On peut se poser à quoi correspond le concept d’administration de réseau. L’ISO (International Standard Organization) a cerné 5 axes : La gestion des anomalies (Fault Management). L’objectif de l’administration réseau est d’avoir un réseau opérationnel sans rupture de service (taux de disponibilité à 99,999 % par exemple soit quelques secondes d’indisponibilité par an), ce qui définit une certaine Qualité de Service (QoS) offerte. On doit être en mesure de localiser le plus rapidement possible toute panne ou défaillance. Pour cela, on surveille les alarmes émises par le réseau, on localise un incident par un diagnostic des alarmes, on journalise les problèmes... La gestion de la configuration réseau (Configuration Management). Il convient de gérer la configuration matérielle et logicielle du réseau pour en optimiser l’utilisation. Il est important que chaque équipement, chaque compteur... soit parfaitement identifié de façon unique à l’aide d’un nom ou identificateur d’objet OID (Object Identifier). La gestion des performances (Performance Management). Il convient de contrôler à tout moment le réseau pour voir s’il est en mesure d’écouler le trafic pour lequel il a été conçu. La gestion de la sécurité (Security Management). On gère ici les contrôles d’accès au réseau, la confidentialité des données qui y transitent, leur intégrité et leur authentification. La gestion de la comptabilité (Accounting Management). L’objectif est de gérer la consommation réseau par utilisateur en vue d’établir éventuellement une facture. En fait, on s’aperçoit qu’un administrateur système d’un réseau local d’une entreprise, d’un campus, d’une école administre aussi son réseau. Il le fait sans trop de problèmes mais les difficultés s’amoncellent dès que la taille du réseau devient importante. La solution est alors de rationaliser, de normaliser les choses et l’on a proposé des normes d’administration de réseau. OFPPT/DRIF

50



L’ISO a proposé dans les années 80 la norme CMIS/CMIP (Common Management Information Service ISO 9595, Common Management Information Protocol ISO 9596) comme protocole d’administration de réseau et définit un cadre général au niveau architecture (ISO 7498). En parallèle, l’IAB (Internet Activities Board) approuve le protocole SNMP (Simple Network Management Protocol) comme solution à cours terme et CMOT (CMIP Over TCP) à plus long terme. Au début des années 90, SNMP, plus simple, devient alors standard de fait et est adopté par de nombreux constructeurs. 1.

Les outils de diagnostic conventionnels et leur limitation respective.

Les outils de diagnostic conventionnels se basés principalement sur la capacité de l’administrateur réseau de configurer des topologies, contrôler les accès, visionner les performances, résoudre les pannes et enregistrer les évènements qui se passent sur le réseau d’un manière manuelle et répétitive ce qui se qui induisait à un mobilisation accrue du temps en terme de taux d’occupation des ressources humaine (Technicien) et d’argent quant il s’agit de site géographiquement distant. De ce fait Gérer et superviser à distance un grand réseau est complexe et cette complexité va croître avec la taille du réseau. Des logiciels et des dispositifs installés sur les différents matériels vont aider l’administrateur dans cette tâche. a) Notion d’éthique et aspect légal

La révolution informationnelle, de l'ampleur de celle que l'on vit dans les systèmes informatique, impose la nécessité de prendre en considération l'ensemble des moyens techniques, organisationnels, juridiques et humains nécessaires et mis en place pour conserver, rétablir, et garantir la sécurité et l’optimisation des systèmes informatiques. Les aspects légaux et éthiques n'y échappent pas, car ils servent de cadre à l’environnement de travail dans une entreprise! Mais cela ne va pas sans un politique claire et efficace définit par le responsable des systèmes d’information ou imposer par la culture d’entreprise à travers son directeur général. L'éthique de l'informatique est une branche de l 'éthique appliquée qui traite de la façon dont les usagers et les professionnels de l 'informatique font un usage de l'information et prennent des décisions au regard de critères éthiques. L'éthique de l'informatique s'intéresse tant à la gouvernance (décision du management) qu'au comportement individuel des utilisateurs et des professionnels de l'informatique. De nos jours, l'utilisation massive de courriers électroniques nécessite par exemple la définition de règles éthiques pour l'usage de l'information. Exemples : Eviter les mails concernant les activités para- professionnelles Eviter l’accès aux sites web de divertissement Eviter Utilisation des mots de passes connue par l’ensemble des utilisateurs OFPPT/DRIF

51


2.


Les outils de surveillance propriétaire et générique (Cas Windows) a) L’analyseur de performance de Windows

L'Analyseur de performances est un outil de visualisation simple et puissant permettant d'afficher des données de performances en temps réel ou à partir des fichiers journaux. L’administrateur a ainsi la possibilité d’examiner les données de performances dans un graphique, un histogramme ou un rapport. L'Analyseur de performances permet d'ajouter simultanément des objets au moniteur afin de surveiller les différents compostant du serveur Windows b) Objets et compteurs de performance

Les systèmes d'exploitation de la famille Windows Server 2003 obtiennent des données de performance à partir de composants de l'ordinateur à mesure que ces derniers sont utilisés. Ces données sont décrites comme un objet de performance et sont généralement nommées en fonction du composant qui les génère. Par exemple, l'objet Processeur est une collection de données de performances sur les processeurs présents sur votre système. Des objets de performance sont intégrés au système d'exploitation ; ils correspondent généralement aux principaux composants matériels de l'ordinateur (mémoire, processeurs, etc.). D’autres programmes peuvent installer leurs propres objets de performance. Par exemple, des services tel que WINS (Windows Internet Name Service) ou des programmes serveur tel que Microsoft Exchange fournissent des objets de performance, qui peuvent être analysés par les courbes et les journaux de performance. Chaque objet de performance fournit des compteurs de performance qui représentent des données sur des aspects spécifiques d'un système ou d'un service. Par exemple, le compteur Pages/s fourni par l'objet Mémoire effectue le suivi du taux de pagination de la mémoire. Voici les objets de performance les plus courants, bien que le système puisse généralement en comporter beaucoup d'autres : • Cache • Mémoire • Objets • Fichier d'échange • Disque physique • Processus • Processeur • Serveur • Système • Thread Le tableau ci-dessous décrit les services et fonctionnalités du système d'exploitation qui peuvent être employés dans votre configuration et les objets de performance correspondants : Fonctionnalité ou service à analyser OFPPT/DRIF

Objet de performance disponible 52


TCP/IP


Objets ICMP, IP, NBT, TCP et UDP

Services Explorateur, Station de travail et Objets Explorateur, Redirecteur et Serveur Serveur Service WINS (Windows Internet Name Objet WINS Service) Services Connection Point

Objet PBServer Monitor

Service d'indexation

Objets Service d'indexation, Filtre du service d'indexation et Service d'indexation http

Service d'annuaire

Objet NTDS

Activité du serveur d'impression

Objet File d'impression

Pour obtenir une description des données fournies par un compteur particulier associé à un objet de performance, cliquez sur Expliquer dans la boîte de dialogue Ajouter des compteurs. Bien que certains objets (tels que Mémoire et Serveur) ne possèdent qu'une seule instance d'objet de performance, certains objets de performance peuvent en avoir plusieurs. Si un objet possède plusieurs instances, vous pouvez ajouter des compteurs en vue d'effectuer le suivi des statistiques pour chacune des instances ou pour toutes les instances à la fois. Selon la manière dont le compteur a été défini, sa valeur peut être : • La toute dernière mesure d'un aspect de l'utilisation des ressources. Ces compteurs sont appelés compteurs instantanés. Par exemple, le compteur Processus/Thread qui affiche le nombre de threads d'un processus particulier au moment de la dernière mesure effectuée. •

La moyenne des deux dernières mesures pendant la période qui sépare les échantillons. Par exemple, Mémoire\Pages/s qui affiche un taux par seconde calculé sur le nombre moyen de pages de mémoire au cours des deux dernier échantillons.

D'autres types de compteurs peuvent être définis, comme cela est indiqué dans le Kit de développement logiciel de plate-forme. La combinaison nom de l'ordinateur, objet, compteur, instance et index d'instance est connue sous le nom de chemin du compteur . Le chemin de compteur est généralement affiché dans les outils de la façon suivante : \\nom_ordinateur \nom_objet (nom_instance #numéro_index )\nom_compteur Le nom_ordinateur est facultatif. Si vous n'indiquez pas de nom, le système d'exploitation utilise par défaut celui de l'ordinateur local.

OFPPT/DRIF

53



Module : Diagnostic d'un réseau GUIDE DES TRAVAUX PRATIQUES

OFPPT/DRIF

54



Les TP se trouvent dans le dossier TPs avec leurs fiches de préparation

OFPPT/DRIF

55



Evaluation de fin de module

1) Donner les avantages de la consignation du problème et de sa résolution 2)

Donner les avantages de la modélisation en couches

3) Donner deux éléments figurant dans le résultat des commandes suivantes : Ping, traceroute et arp 4)

Citer un exemple de panne de la couche 1

5)

Expliquer la procédure à suivre pour diagnostiquer la panne ci-dessus

6)


7)


8)


9)


10) Définir un analyseur de protocoles 11) Quels sont les avantages des analyseurs de protocoles

12) A votre avis quels sont les inconvénients des analyseurs de protocoles

OFPPT/DRIF

56

Diagnostic d'un réseau1

Recommend Documents