Guide de dépannage du réseau

Ce guide décrit les étapes collaboratives nécessaires pour diagnostiquer et résoudre les problèmes de performances réseau. Il est organisé sous la forme d’un organigramme hiérarchisé, commençant par les problèmes les plus simples et les plus courants avant de passer à des analyses plus complexes.

Prérequis : passer en revue les bonnes pratiques relatives aux applications

Avant de procéder à une analyse approfondie du réseau, il est essentiel de vous assurer que votre application est conçue pour offrir des performances optimales. De nombreux problèmes de performances peuvent être résolus en améliorant la conception de l’application, par exemple en réduisant les appels API à haute fréquence ou en supprimant les déclencheurs inefficaces.

Consultez ici le guide sur la conception des applications.

Si votre application respecte déjà ces recommandations, passez aux phases d’analyse réseau suivantes et aux étapes qui s’ensuivent :

Phase 1 : Vérifications de base

Éliminez rapidement et sans effort les problèmes locaux, côté client et au niveau de la couche physique.

1. Exécutez les diagnostics actuels depuis la station concernée

• Action: exécutez les commandes suivantes à la fois vers le service cible ET vers un point de terminaison public stable et à large bande passante (par exemple, google.com ou cloudflare.com) à des fins de comparaison.
• Ping étendu (50 à 100 pings ou plus) pour afficher la latence minimale, moyenne et maximale ainsi que la perte de paquets.
• ping 1.1.1.1 (Cloudflare)
• ping 8.8.8.8 (Google)
• pathping (sous Windows)
• Recherches DNS : nslookup, dig, drill
• Raison de la priorité: ce sont les données les plus rapides à collecter. Le test comparatif est essentiel et vous indique immédiatement si le problème est spécifique au chemin d'accès au service ou s'il s'agit d'un problème Internet général au niveau de ce poste.
• Action - Utilisez l'outil « Network Check » de Tulip
  • Option 1 – Dans une fenêtre de navigateur, accédez à https://{Votre Tulip Instance}.tulip.co/networkCheck
  • Option 2 – Dans Tulip Player, cliquez sur le menu « Outils », puis sur « Vérification du réseau ».
  • Vérifiez les résultats
    • Vérifiez si tous les tests sont réussis. S’ils échouent, faites une capture d’écran de cette page et cliquez sur « Télécharger les diagnostics ». Envoyez la capture d’écran et le fichier de diagnostics à support.tulip.co, et un représentant Tulip pourra vous aider.
    • Vous pouvez également partager ces fichiers avec votre service informatique interne afin qu’il puisse vous aider à résoudre le problème.

2. Effectuer une inspection physique du matériel

• Action: effectuez une inspection physique exhaustive du matériel des postes concernés. Vérifiez s’il y a des câbles Ethernet défectueux, des cartes réseau mal enfichées ou des problèmes au niveau du port physique du commutateur.Raison de la priorité: les problèmes liés à la couche physique sont fondamentaux et peuvent imiter des problèmes réseau plus complexes. Les éliminer en premier lieu évite de perdre du temps sur un diagnostic au niveau logiciel.

3. Vérifier la configuration locale du poste

• Action: vérifiez les paramètres DNS du poste, les configurations de proxy local (pour d’éventuelles redirections), les logiciels de sécurité/pare-feu locaux, et examinez les journaux du serveur DHCP pour vous assurer que le poste ne subit pas de renégociations DHCP fréquentes.
• Raison de la priorité: il s’agit de paramètres spécifiques au client qui peuvent causer des problèmes à un seul utilisateur sans affecter l’ensemble du réseau. C’est la prochaine étape logique après avoir écarté les problèmes physiques et les problèmes généraux liés à Internet.

4. Examiner les journaux système locaux à la recherche d’événements récents

• Action: depuis le poste concerné, consultez les journaux d’événements système (par exemple, l’Observateur d’événements Windows, la Console macOS ou les commandes journalctl/dmesg sous Linux) afin de repérer toute erreur, tout avertissement ou tout changement significatif récent lié au réseau et coïncidant avec l’apparition du problème de performances. Recherchez les événements liés à des changements d’état de la carte réseau, à des échecs de bail DHCP, à des problèmes de résolution DNS ou à des alertes du pare-feu ou des logiciels de sécurité.
• Raison de la priorité: cela permet de déterminer si le problème est nouveau ou s’il est lié à une modification récente de la configuration ou à un problème réseau localisé antérieur qui aurait pu laisser des traces sur la machine cliente.

Phase 2 : Analyse corrélative de l’infrastructure

Utilisez des données d’événements spécifiques pour examiner l’infrastructure réseau partagée. Cette phase nécessite un accès aux systèmes informatiques et une collaboration avec le service informatique.

5. Identifiez les horodatages et examinez les journaux internes

• Action: mettez en corrélation les moments de ralentissement signalés par les utilisateurs avec les journaux des périphériques réseau internes. Recherchez :
• Une forte instabilité du réseau
• Perte de paquets ou taux de retransmission élevés
• Examinez le schéma du réseau et fournissez les journaux
• Les journaux réseau correspondant à la période où le problème s’est produit (y compris ceux du proxy, le cas échéant)
• Événements de congestion du réseau local ou de saturation de la bande passante
• Raison de priorité: cela permet de concentrer l'investigation sur des moments précis, ce qui est bien plus efficace que de passer au crible des jours entiers de journaux. Cette étape doit être effectuée avant de faire appel à des intervenants externes.

6. Vérifier les performances du pare-feu et des appareils de sécurité

• Action: pendant les périodes concernées par le problème, examinez les journaux du pare-feu/proxy à la recherche de connexions TCP/UDP bloquées et vérifiez les ressources des appareils (CPU, RAM, connexions). Veuillez également vous assurer que toutes les adresses IP et tous les domaines Tulip requis figurent bien sur la liste blanche et ne font pas l’objet d’une inspection trop agressive susceptible d’augmenter la latence. Prêtez attention aux indicateurs spécifiques aux proxys, tels que les limites de connexion, les sessions simultanées et la latence induite par l’inspection approfondie des paquets.
• Raison de la priorité: les dispositifs de sécurité constituent souvent un goulot d’étranglement. Cette vérification permet de détecter à la fois les règles de blocage explicites et la dégradation des performances due à une surcharge matérielle ou à des politiques d’inspection intrusives.

7. Examinez la configuration de la qualité de service (QoS)

• Action: si vous avez mis en place des politiques de QoS, vérifiez comment le trafic à destination et en provenance des services de l’application est classé. Assurez-vous qu’il n’est pas accidentellement dépriorisé.
• Raison de la priorité: une mauvaise configuration de la QoS est une cause spécifique et souvent négligée de problèmes de performances des applications, en particulier pendant les périodes de forte activité réseau.

8. Analysez la bande passante globale et les données SNMP

• Action: examinez l’utilisation maximale de la bande passante à l’échelle du site et vérifiez les données SNMP des routeurs/commutateurs pour détecter une utilisation élevée ou des erreurs pendant les périodes où le problème s’est produit.
• Raison de la priorité: cela permet de déterminer si le problème est lié à la capacité globale du réseau ou à une contention.

9. Analysez le chemin réseau de votre FAI

• Action: contactez votre FAI en lui fournissant les horodatages précis des pics de latence.
• Détails concernant le FAI: demandez-lui de rechercher un routage sous-optimal, une congestion au niveau des points de peering, une perte de paquets ou une latence accrue sur ses segments ou ses chemins de transit, ou encore toute politique réseau pertinente en vigueur pendant ces périodes spécifiques.
• Raison de la priorité: cette étape implique un tiers et s’avère particulièrement efficace lorsque vous pouvez lui fournir des données précises et des horodatages issus de votre enquête interne.

Phase 3 : Analyse approfondie avancée

Utilisez des méthodes hautement techniques et gourmandes en ressources pour détecter les problèmes les plus insaisissables.

10. Analyse approfondie avancée au niveau des paquets

• Action: Effectuez une capture complète des paquets (pcap) sur une machine affectée pendant un épisode de ralentissement. La clé réside dans une attention particulière portée à la corrélation des horodatages à travers toutes les couches d’analyse. Analysez la capture à la recherche de manipulations de paquets (par exemple, modifications du TTL), d’erreurs de protocole (retransmissions TCP) ou de messages d’erreur ICMP spécifiques.
• Raison de la priorité: il s’agit de l’étape la plus complexe. Elle fournit la vérité absolue, mais n’est envisagée que lorsque toutes les autres investigations ont échoué à identifier la cause.