Dépannage réseau, les outils tactiques

Dans de tels cas, l’examen du trafic qui s’écoule dans le réseau permet de voir littéralement un problème en action. Ces outils – appelés outils tactiques parce qu’ils vous aident à étudier un problème au cœur de la bataille, si l’on peut dire – montrent exactement comment les unités interagissent entre elles. Le plus connu d’entre eux est un analyseur de protocole de réseau, ou renifleur (sniffer).

Les renifleurs de réseaux peuvent être des appareils ou des logiciels dédiés qui fonctionnent sur des ordinateurs fixes ou portables. Dans le cas des réseaux Ethernet, on trouve surtout des dispositifs logiciels, dont l’un très connu, FOSS package – Wireshark (wireshark.org) – est à la fois puissant et simple d’emploi. Les renifleurs pour interfaces série, comme T1, T3 et les circuits optiques, demandent un matériel d’écoute (ou d’espionnage) du circuit pour interposer le renifleur sur un circuit opérationnel sans perturber le trafic. En revanche, pour le reniflage Ethernet, il suffit généralement d’un commutateur Ethernet géré doté de la fonction « mise en miroir des ports » – c’est-à-dire la possibilité de copier le trafic provenant d’un ou plusieurs ports sur le commutateur vers un port que le renifleur est en train de superviser. Il existe aussi des écoutes Ethernet matérielles – parfois appelées garages à trois voitures à cause de leurs trois ports Ethernet côte à côte.
Un renifleur intercepte le trafic sur une liaison de communication et le décode, puis stocke le trafic décodé pour examen ultérieur. Selon la capacité de stockage du renifleur et le volume du trafic passant par la liaison surveillée, vous pouvez capturer de quelques minutes à quelques jours de trafic. Outre le décodage, certains renifleurs comportent des outils d’analyse élaborés capables de reconstruire des ensembles de données originaux, comme des transmissions d’e-mails ou des échanges de protocoles graphiques. Certains routeurs et pare-feu ont même des renifleurs intégrés rudimentaires, utiles pour de petites tâches de diagnostic.

Mais les réseaux actuels, de l’ordre du gigabit, peuvent facilement surcharger les analyseurs de protocoles commerciaux, sauf les plus coûteux. Pour contourner ce problème, on s’est tourné vers un nouveau genre d’analyse de protocole, appelée analyse de flux. Au lieu de capturer chaque paquet sur une liaison, l’analyse de flux récapitule les paquets d’après les flux de données, circulant entre deux points d’extrémité uniques. Un flux est défini comme toute combinaison unique d’adresses IP source et destination, et de protocoles source et destination. Un générateur de flux examine chaque paquet passant sur une liaison et crée des enregistrements de flux pour présenter le nombre de paquets dans chaque flux. Périodiquement – en principe à quelques secondes d’intervalle – le générateur de flux transmet les éventuels enregistrements de flux changés à un collecteur de flux, lequel archive les enregistrements dans une base de données et fournit une interface pour visualiser les flux sous forme de tables et de graphiques.

Les deux protocoles d’analyse de flux les plus connus aujourd’hui sont Netflow, développé par Cisco, et sFlow (sflow.org), un standard ouvert. A l’heure actuelle, Netflow est le plus répandu car il vise à capturer et à tabuler tous les paquets présents dans un flux. sFlow effectue un échantillonnage statistique, donc ses tabulations de flux ne sont pas aussi précises et donc pas aussi utiles pour le dépannage du réseau. Certains produits pare-feu ont des composants d’analyse de flux propriétaires, mais ils ne servent généralement qu’à suivre l’usage global du réseau. Le dépannage à l’aide des flux exige de pouvoir examiner les enregistrements de flux individuels.

La plupart des routeurs Cisco, et beaucoup d’unités tierces parties, ont des générateurs de flux intégrés. Il vous suffit de fournir un collecteur et analyseur de flux. Il existe des produits analyseurs commerciaux, mais un package FOSS, ntop (ntop.org), vous permet de pratiquer l’analyse de flux à moindres frais. Sous sa forme la plus simple, ntop peut combiner le générateur et le collecteur de flux dans un même ordinateur. Il peut aussi accepter les flux générés par des unités NetFlow et sFlow. Son interface de type web récapitule le trafic par flux, par protocole, et par « plus gros parleurs » – c’est-à-dire ceux qui génèrent le trafic le plus volumineux (et donc le plus intéressant pour le dépannage) sur le réseau. Si aucun de vos appareils n’a la fonction de génération de flux, vous pouvez acquérir des générateurs de flux autonomes, comme le nMon nBox (nmon.net). Les générateurs autonomes peuvent traiter de gros volumes de trafic en utilisant un matériel spécialisé dédié. nBox présente une caractéristique intéressante : une version open-source, appelée nProbe, que vous pouvez exécuter sur votre propre plate-forme, y compris Windows XP.

Les renifleurs et les analyseurs de flux ont pour mérite de vous montrer exactement le trafic qui emprunte le réseau. Si deux unités ne peuvent pas communiquer, vous pouvez généralement en déterminer la cause en examinant les flux de trafic. Peut-être que les requêtes envoyées par une unité ne produisent jamais de réponse de l’unité de destination. Ou bien, les réponses disparaissent quelque part sur le réseau. Une sonde de réseau judicieusement insérée permet d’isoler et d’identifier rapidement les problèmes de communication.

L’indispensable trio

Si vous n’êtes pas encore un dépanneur de réseau parfaitement équipé, vous savez maintenant comment le devenir. Vos moyens doivent couvrir les trois domaines essentiels de la résolution des problèmes réseau : l’instrumentation du réseau, les méthodes de diagnostic et les outils tactiques. Une fois ces bases couvertes, vous pourrez étendre la couverture à un plus large éventail d’outils et de procédures. Mais quelle que soit votre position aujourd’hui, agissez sans tarder. La prochaine énigme du réseau est juste au coin de la rue !