Mise en réseau

Dépistage des problèmes réseau insaisissables

Christophe Stoneff

Vue d'ensemble:

• Causes habituelles de problèmes réseau
• Voir au-delà des apparences
• Quand les outils de dépannage sont inutiles
• Pourquoi configurer les limites de connexion

Ce scénario vous est sans doute familier, votre ordinateur ne peut plus communiquer avec le reste du réseau et vous ne voyez pas pourquoi. Votre système de gestion repose sur un segment de réseau routé connecté à d'autres segments réseau par l'intermédiaire d'un routeur, tel que Microsoft Internet

Security and Acceleration (ISA) Server ou un autre périphérique matériel. La gestion de 10, 20, voire 100 systèmes, se fait sans problèmes. Par contre, lorsque vous passez à 500 systèmes, votre ordinateur est incapable de communiquer sur le réseau, à l'exception des ordinateurs avec lesquels il dispose déjà de connexions ouvertes. Vous ne pouvez communiquer avec aucun autre système, vous ne pouvez pas accéder à Internet, alors que personne d'autre sur le réseau, ce qui inclut votre segment, ne subit ce phénomène. Par où commencer ?

Diagnostic du problème

Dans ce cas, le logiciel de gestion est le principal suspect. De nombreux outils de gestion dynamiques se connectent et gèrent vos systèmes. Cependant, il arrive parfois que ces outils soient à l'origine du problème que vous tentez de dépister. Ceci est dû au fait qu'un outil de gestion dynamique peut créer des milliers de connexions avec vos périphériques au nom d'une meilleure gestion. Windows® laisse ces connexions ouvertes pendant deux minutes par défaut même si les connexions sont inutilisées, sauf si l'outil, l'application ou le service les maintiennent actives plus longtemps. Ceci signifie que même si votre système de gestion n'a pas communiqué avec d'autres ordinateurs pendant deux minutes, vous pouvez avoir plus de 1 000 connexions ouvertes. (Vous pouvez afficher les connexions ouvertes en exécutant NETSTAT à partir de la ligne de commande. La commande NETSTAT affiche toutes les connexions ouvertes, en attente et en cours de fermeture, depuis ou vers votre système, et indique leur état. Les descriptions des messages d'état figurent dans RFC 793 sur tools.ietf.org/html/rfc793.)

Pour écarter tous les logiciels de gestion défaillants, vous pouvez créer un fichier de commandes qui établit des connexions avec les systèmes distants. Si le même problème survient pendant l'exécution du fichier de commandes, ceci signifie que le logiciel de gestion et ses threads ne sont pas à l'origine du problème. Voici un exemple de contenu du fichier de commandes requis :

Net use \\system01\ipc$
Net use \\system02\ipc$
Net use ...

Si le programme de gestion en question mettait en œuvre sa propre mise en réseau et pile d'authentification, il pourrait être à l'origine du problème. Dans les solutions sans agent, comme pour la plupart des packages de gestion, l'outil exploite les fonctionnalités réseau et les piles d'authentification du système d'exploitation pour exécuter les opérations réseau. Si le fichier de commandes crée autant de connexions réseau sans pour autant entraîner de défaillance, ceci indique que le problème ne résulte pas de l'exploitation des fonctionnalités réseau et de la pile d'authentification du système d'exploitation, dans la mesure où le fichier de commandes les utilise aussi.

Journaux et messages d'erreur qui prêtent à confusion

Vous avez probablement constaté que lorsque les connexions ont commencé à échouer, vous avez reçu des messages d'erreur erronés : erreur 53 : chemin réseau n'a pas été trouvé, erreur 64 : le nom réseau a été supprimé et erreur 1203 : aucun logiciel réseau n'a accepté le chemin réseau fourni. Tous ces messages indiquent généralement des problèmes de résolution de nom. Toutefois, tous les autres ordinateurs parviennent à résoudre les noms sans problème et à se connecter aux mêmes systèmes. Pour vous assurer que les paramètres de votre ordinateur ne sont pas en cause, exécutez simplement ipconfig pour confirmer que vos paramètres sont corrects.

Ensuite, si le phénomène semble localisé sur votre système de gestion, consultez les journaux des événements. La recherche dans les journaux d'application est infructueuse, alors que le journal système présente un événement d'avertissement 4226 provenant de la source d'événement TCP/IP, indiquant que le nombre maximum de connexions a été atteint (voir la figure 1).

Figure 1** La limite de connexions TCP a été atteinte **

Effectuez une recherche dans la base de connaissances de Microsoft® concernant les limites de connexion. Vous verrez alors que des limites de connexion s'appliquent en cas de connexions incomplètes, tandis que les connexions complètes ne sont sujettes à aucune limite. Vous avez la capacité de régler les entrées de Registre suivantes sous HKLM\System\CurrentControlSet\Services\TCPIP\Parameters pour contrôler les facteurs mentionnés ci-dessus : TcpNumConnections est utilisé pour définir le nombre maximum de connexions que TCP peut ouvrir en même temps (la valeur par défaut est de 10). TCPTimedWaitDelay définit la durée de l'état TIME_WAIT pour la connexion en cours de fermeture. La demi-durée de vie par défaut est de 120 secondes, ce qui signifie qu'une connexion est utilisée pendant 4 minutes. Enfin, MaxFreeTcbs joue également un rôle concernant le nombre maximal de connexions. Si tous les blocs de contrôle TCP sont utilisés, TCP doit libérer les connexions dont l'état est TIME_WAIT pour créer davantage de connexions, même si TCPTimedWaitDelay n'a pas encore expiré. TCPTimedWaitDelay a une plage de valeurs qui va de 30 à 300 secondes (0x1 E – 0x12C).

Dans le cadre de notre scénario, vous pourrez constater une légère amélioration des performances globales en appliquant ces modifications dans le registre. Vous pouvez également essayer de réparer le fichier TCPIP.sys en supprimant ces limites, mais ceci permet uniquement d'améliorer les applications P2P.

Captures réseau

Si vous ne parvenez toujours pas à résoudre les problèmes de connexion, l'exécution d'une capture réseau sur les ordinateurs en cause semble être une bonne solution. Lorsque j'ai exécuté Microsoft Network Monitor (Netmon), il a produit des captures qui reproduisaient exactement ce que je voyais dans les outils de gestion et les scripts de test : tout fonctionne, puis s'arrête, sans indication d'erreur.

La figure 2 affiche le résultat de Netmon, qui indique une communication réussie entre les n premiers systèmes. Vous pouvez constater que j'obtiens des accusés de réception des requêtes RPC. Il s'agit bien du résultat attendu, une communication bidirectionnelle réussie.

Figure 2** Communication réussie dans Netmon **(Cliquer sur l'image pour l'agrandir)

Vous allez maintenant examiner les captures du système de gestion et les ordinateurs distants qui semblent présenter l'erreur 53/1203. Comme vous pouviez vous y attendre, il n'y a rien à voir, car les ordinateurs ne communiquent pas. Dans la capture réseau de la figure 3, le système de gestion a résolu l'adresse IP et tente de se connecter au système sur le port 445 (le port SMB de Microsoft) sans jamais recevoir de réponse.

Figure 3** La tentative de connexion au système sur le port 445 n'obtient aucune réponse **(Cliquer sur l'image pour l'agrandir)

L'erreur que vous recevez lorsque vous disposez d'un nombre de threads supérieur au nombre de connexions possibles sur votre ordinateur n'est pas toujours cohérente. Dans certains cas, le système source renvoie une erreur 53, ce qui indique que vous avez reçu la résolution de nom, tandis que l'adresse IP reste introuvable. Ceci indique que DNS fournit une adresse à laquelle vous ne pouvez pas vous connecter. Vous pouvez recevoir une erreur 1203, ce qui indique qu'aucun ordinateur n'a répondu au nom ou à l'adresse IP que vous avez demandés. L'erreur 1203, dans ce cas, indique que DNS ne vous est pas disponible. Vous verrez que c'est le cas si vous exécutez nslookup.

À ce stade, vous sentirez sans doute une certaine frustration, mais il y a d'autres options à prendre en compte. La plupart des personnes ne pensent même pas à vérifier l'infrastructure de connexion, compte tenu de la manifestation du problème : votre ordinateur est le seul à ne pas pouvoir se connecter au réseau et les journaux d'événements indiquent que votre ordinateur a atteint le nombre maximum de connexions autorisées, ce qui semble écarter les problèmes d'architecture.

Alors que les milliers de connexions créées par votre solution de gestion ne s'activeront pas en même temps, les conservations de transmissions actives et les délais de connexions peuvent signifier que vous avez plus de connexions ouvertes en même temps que vous ne le pensez. Par conséquent, vous devez également examiner les systèmes qui se connectent au reste du réseau.

Je vais essayer de m'expliquer plus clairement. Comme je l'ai mentionné plus haut, lorsque le trafic transite sur le réseau, il passera par des commutateurs, des routeurs, voire des pare-feux. À tous ces points, généralement au niveau du routeur ou du pare-feu, vous risquez de rencontrer des systèmes de détection des intrusions. Les commutateurs et les routeurs gérés peuvent également filtrer le trafic. Vous, ou quiconque a le contrôle de ces périphériques, devez consulter les journaux afin de rechercher les erreurs ou les avertissements éventuels. Le problème de communication peut très bien provenir de l'un de ces systèmes.

Dans la mesure où vous vous connectez depuis un système interne vers d'autres systèmes internes, vous pourrez constater qu'aucune alerte n'a été déclenchée, car la fonctionnalité d'alerte n'est pas configurée sur le périphérique ou parce que le problème ne constitue pas une attaque par intrusion ou déni de service. Encore une fois, vous devez commencer par les journaux. En prenant ISA Server comme exemple, ces journaux figurent dans la console de gestion d'ISA Server sous Arrays\<ArrayName>Monitoring\Logging.

Si cette stratégie est à l'origine du blocage, vous pouvez (dans le cas d'ISA Server) rechercher les codes de résultat suivants où l'IP source correspond à votre ordinateur de gestion :

• 0xc0040037 FWX_E_TCP_RATE_QUOTA_EXCEEDED_DROPPED
• 0xc004000d FWX_E_POLICY_RULES_DENIED
• 0xc0040017 FWX_E_TXP_SYN_PACKET_DROPPED

Si vous trouvez ces résultats, vous avez identifié l'origine de vos problèmes de connectivité.

Implémentation de la solution

Maintenant que vous avez identifié le problème, la solution peut être simple, avec comme seul obstacle les éventuels règlements du service dont vous dépendez. Avant d'apporter des modifications, assurez-vous que vous disposez d'autorisations adéquates, dans la mesure où la mise en place d'exclusions dans les configurations de sécurité de vos pare-feux, routeurs et/ou systèmes de détection d'intrusion ne sont pas toujours autorisés.

Toujours en prenant ISA Server comme exemple, les étapes suivantes indiquent comment augmenter le nombre maximal de connexions pour un hôte donné ou pour tous les ordinateurs du réseau (comme indiqué dans la figure 4). Ouvrez la console de gestion d'ISA Server et accédez à Arrays\<ArrayName>\Configuration\General\Configure Flood Mitigation Settings.

Figure 4** Augmentez le nombre maximum de connexions pour un hôte ou tous les ordinateurs avec ISA Server. **

Les deux paramètres qui nous intéressent sont le nombre maximum de connexions TCP simultanées par adresse IP et le nombre maximum de requêtes TCP de connexion par minute par adresse IP. Le nombre maximum de connexions TCP simultanées par adresse IP est généralement défini sur une valeur qui serait suffisante en l'absence de toute gestion active, ce qui signifie qu'aucun ordinateur ne se connecte de façon active et rapide à des milliers d'autres ordinateurs. Dans ISA Server, la limite par défaut pour le nombre de connexions TCP simultanées est de 160. Le nombre maximal de demandes de connexions TCP par minute par adresse IP a été conçu pour limiter les dommages et la visibilité des analyses réseau. La limite par défaut est de 600 requêtes de connexion par minute par IP.

Comme indiqué plus haut, Windows préserve une connexion pendant une période par défaut de deux minutes, à condition que rien d'autre ne tente de maintenir la connexion active et même si cette connexion reste inutilisée. Ceci signifie que même si vous avez déjà géré avec succès un ordinateur et n'avez plus besoin de communiquer avec ce dernier, la connexion restera active. Cette connexion ouverte compte dans le total des connexions attribuées. Si vous répétez ce processus plus de 160 fois sans supprimer les connexions ainsi ouvertes, vous constaterez que toutes les tentatives de connexion seront refusées par votre routeur. Même si votre programme de gestion termine une session de façon dynamique, Windows peut très bien conserver la connexion dans un état time_wait en attendant que l'ordinateur cible consente à déconnecter la session.

Procédez à des ajustements sur les principaux suspects : nombre maximum de connexions TCP simultanées par adresse IP. Vous devez définir ceci de façon à ce que votre ordinateur de gestion puisse créer toutes les connexions nécessaires à la gestion de vos systèmes sans avoir à subir de refus d'accès. Cliquez le bouton Modifier près du paramètre et modifiez les valeurs.

L'invite suivante (voir la figure 5) comporte une case Limite qui représente la limite par défaut, qui s'applique à tous les clients. La limite Personnalisée s'applique à tous les ordinateurs, réseaux et ainsi de suite qui sont définis dans l'onglet Exceptions IP de la boîte de dialogue de prévention des attaques par saturation. Pour que chaque ordinateur puisse créer davantage de connexions, modifiez ensuite la valeur de Limite. Pour configurer l'exception uniquement sur votre ordinateur de gestion, réglez la limite Personnalisée et ajoutez votre ordinateur dans l'onglet Exceptions IP. Ceci est généralement préférable pour autoriser l'exception uniquement sur votre propre ordinateur.

Figure 5** Limite de connexion par défaut et limite de connexion personnalisée **

Si vous souhaitez utiliser la limite personnalisée pour modifier cette valeur pour des systèmes spécifiques, modifiez la valeur du champ de limite Personnalisée, puis cliquez sur OK. Ajoutez ensuite votre ordinateur dans l'onglet Exceptions IP dans la boîte de dialogue de prévention des attaques par saturation. Pour ajouter votre ordinateur à la liste d'exceptions, dans la section Exceptions IP, cliquez sur Ajouter pour afficher la boîte de dialogue Jeux d'ordinateurs. Cliquez sur Nouveau pour créer un nouveau jeu réseau contenant votre ou vos systèmes si aucun jeu réseau contenant ces ordinateurs n'existe. Sélectionnez ce jeu réseau et cliquez sur Ajouter pour ajouter le jeu réseau Réseaux internes, puis cliquez sur Fermer. Sélectionnez à nouveau le réseau Réseaux internes, puis cliquez sur Modifier. Ceci ouvrira les propriétés de Réseaux internes voir la figure 6). Cliquez sur Ajouter dans cette boîte de dialogue pour afficher un sous-menu permettant d'ajouter un ordinateur, une plage d'adresses ou un sous-réseau. Choisissez la section ordinateur. Tapez un nom pour identifier l'entrée, l'adresse IP de l'ordinateur et une description, de telle façon que toute personne consultant cette entrée par la suite ne se sentira pas obligée par la suite de supprimer votre système (voir la figure 7). Cliquez sur OK pour ajouter votre système, puis cliquez à nouveau pour ajouter l'exception. Une fois ces modifications appliquées, vous devez appliquer les paramètres.

Figure 6** Propriétés des réseaux internes **

Figure 7** Entrez le nom d'ordinateur, l'adresse IP et la description pour vous assurer que le système n'est pas supprimé **

Exécutez à nouveau votre outil de gestion dynamique, qui devrait vous indiquer que les performances sont bien meilleures et que la connexion n'échoue pas, du moins pas à cause du trafic réseau. En résumé, le problème ne résidait pas dans le nombre de connexions établies par le logiciel, mais dans l'absence de planification adéquate de ces connexions.

Enseignements tirés

L'un des principaux casse-tête en informatique est la détection et la résolution de problèmes insaisissables. Il s'agit de problèmes que l'utilisateur final n'a pas créés, que l'équipe de serveur n'a pas causé, de problèmes que le centre d'assistance ne connaît pas, et, malheureusement, dont la résolution risque de vous incomber. Vous disposez de myriades d'outils pour vous aider à dépanner, isoler et résoudre des problèmes, mais parfois les outils ne suffisent plus. Parfois ils ont tort. Et parfois vous devez voir plus loin que ces outils.

Ainsi, si à l'avenir la connexion devient impossible entre plusieurs ordinateurs de votre réseau sans raison évidente, essayez les étapes que j'ai décrites ici. Il est alors fort probable qu'en suivant ces étapes, en examinant de plus près votre logiciel de gestion et en définissant les connexions admissibles correctement, vous résolviez le problème avec succès.

Christophe Stoneff est responsable de produit chez Lieberman Software (liebsoft.com), une société de développement de logiciels de gestion de la sécurité et de systèmes. Chris détient un nombre incroyable de certifications techniques. Ce qui le motive n'est pas tant de savoir comment les choses fonctionnent, mais pourquoi.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.