Conseils de résolution des problèmes de communication TCP/IP

Cet article est conçu pour vous aider à résoudre les problèmes de communication TCP/IP.

Outils de résolution de problèmes

La commande ping est utile pour tester la connectivité de base. Toutefois, vous ne devez pas vous en fier pour prouver la connectivité globale. Telnet et PsPing sont plus utiles, pour les raisons suivantes :

• Ces outils peuvent tester la connectivité à la couche application en utilisant TCP ou UDP (PsPing uniquement) comme protocole de transport.
• Vous pouvez spécifier le port à utiliser. Par conséquent, vous pouvez naviguer dans les ports ouverts sur un pare-feu.
• Vous pouvez vous connecter à n’importe quel port « à l’écoute » sur le nœud de destination pour vérifier l’accès au port d’une application spécifique.

Liste de pour la résolution des problèmes

Étape 1 : Capturer un diagramme réseau

Capturez un diagramme réseau qui détaille les appareils qui se trouvent dans le chemin d’accès à la zone affectée. Plus précisément, notez les appareils suivants :

• Pare-feu
• IPS (Systèmes de protection/prévention contre les intrusions)
• DPI (Deep Packet Inspection)
• Accélérateurs de WAN

Le diagramme peut vous aider à visualiser et à identifier où rechercher la cause du problème.

Étape 2 : Suivis réseau

Les traces réseau sont utiles pour voir ce qui se produit au niveau du réseau lorsque le problème se produit.

Étape 3 : Effectuer un test ping sur l’adresse IP locale de l’ordinateur

Essayez d’effectuer un test ping sur l’adresse IP locale de l’ordinateur.

Si le nœud ne peut pas effectuer un test ping sur son adresse IP locale, la pile locale ne fonctionne pas. Notez tous les messages d’erreur affichés.

Si vous recevez une erreur d’échec général , cette erreur signifie qu’il n’existe aucune interface valide pour traiter la demande. Ce problème peut être dû à un problème matériel ou à un problème de pile.

Vérifiez si vous voyez un caractère « X » rouge ou un point d’exclamation jaune sur l’icône Connexion réseau dans la barre d’état système. Un X rouge indique que Windows ne détecte pas de connexion réseau. Un point d’exclamation jaune indique que l’indicateur d’état de connexion réseau (NSCI) n’a pas réussi à case activée de sonde.

Pour résoudre ce problème, vérifiez que la carte réseau signale la connectivité. Assurez-vous que la carte réseau est branchée et que le port de commutateur sur lequel le nœud est connecté n’est pas dans un état d’erreur. Vous pouvez modifier les câbles, les ports de basculement et les cartes réseau pour limiter l’endroit où ce problème se produit. Toutefois, en fin de compte, le problème est en dehors du système d’exploitation. Pour plus d’informations, contactez les fournisseurs de matériel.

Un problème peut également se produire entre le pilote réseau et Windows. Ce problème est généralement dû à une altération de la pile. Suivez les étapes de résolution des problèmes suivantes :

1. Assurez-vous que les derniers bits sur le nœud (TCP/IP, NDIS, AFD, Winsock, etc.).

2. Réinitialisez l’adresse IP et Winsock en exécutant les commandes suivantes. Sauvegardez toute la configuration réseau.

   netsh -c interface dump > C:\netConfig.txt
   netsh int ip reset
   netsh winsock reset
   

3. Redémarrez le nœud.

4. Restaurez les paramètres réseau après le redémarrage. Cette opération fonctionne uniquement si les noms d’interface n’ont pas changé ou si le script est mis à jour pour utiliser les nouveaux noms.

   netsh -f C:\netConfig.txt
   

5. Désinstallez ou réinstallez le pilote de carte réseau, le cas échéant.

6. Recherchez et supprimez les pilotes de filtre tiers (par exemple, antivirus).

7. Essayez de démarrer l’ordinateur en mode sans échec avec mise en réseau. Si le mode sans échec avec mise en réseau fonctionne, exécutez un processus de démarrage propre en désactivant toutes les applications et services tiers dans MSConfig, puis en les réactivant un par un jusqu’à ce que le problème revient. Vous pouvez ensuite contacter le fournisseur pour obtenir du support.

   1. Si aucun de ces éléments ne réussit, le problème est probablement une altération du registre.
   2. Si vous disposez d’une copie de sauvegarde du Registre (par exemple, une sauvegarde physique ou un point de restauration système), vous pouvez essayer de restaurer le nœud dans une configuration précédemment opérationnelle. L’interception de la cause racine de la corruption peut être difficile et extrêmement fastidieuse. Même si la corruption est détectée, savoir ce qui l’a causé est encore plus difficile. La modification manuelle de la clé de Registre endommagée place le nœud dans un état non pris en charge. Par conséquent, nous recommandons au client de restaurer ou de recharger le nœud afin de corriger l’altération.

Si la sonde NSCI échoue case activée (point d’exclamation jaune), cela n’indique pas nécessairement un problème de connectivité. Assurez-vous que la communication classique se produit comme il se doit.

• Si c’est le cas, l’enquête doit se concentrer spécifiquement sur la raison pour laquelle le NCSI échoue à ses vérifications de sonde. Les détails de cette opération sont abordés dans une rubrique distincte.
• Si ce n’est pas le cas, examinez d’abord les problèmes de connectivité, car cela sera probablement corrigé après la restauration de la connectivité.

Étape 4 : Résoudre les problèmes liés aux messages d’erreur qui se produisent pendant le test ping ou telnet

Si le nœud peut effectuer un test ping ou telnet vers des nœuds sur le même sous-réseau ou segment réseau, cela confirmerait que la connectivité externe fonctionne. Des tests supplémentaires sont toujours nécessaires pour comprendre s’il existe un problème de connectivité de base.

Si le nœud ne peut pas effectuer un test ping/telnet vers des nœuds sur le même sous-réseau/segment réseau. Notez tous les messages d’erreur affichés.

1. L’erreur inaccessible de l’hôte de destination signifie que les requêtes ARP envoyées par le nœud n’obtiennent pas de réponse.

2. Rassemblez une trace recto verso à partir des nœuds entre lesquels vous effectuez des tests. Assurez-vous que la requête ARP envoyée par le nœud source atteint le nœud de destination et que le nœud de destination répond en conséquence. Cette réponse doit être consultée dans la trace source. Si ce processus échoue, le problème est probablement une mauvaise configuration ou d’autres problèmes qui affectent l’infrastructure.

   Les causes possibles peuvent être les suivantes :

   1. Réseaux locaux virtuels incorrects ou incompatibles.
   2. Une configuration de port de commutateur incorrecte (jonction ou port d’accès).
   3. Autres problèmes matériels.

3. L’erreur Request timed out signifie que la requête ARP a reçu une réponse, mais que la demande d’écho ICMP envoyée par le nœud n’obtient pas de réponse d’écho ICMP. Cela, à lui seul, n’indique pas de problème. Le trafic ICMP peut être bloqué par le logiciel réseau ou pare-feu sur les nœuds. Il peut être utile de désactiver les profils de pare-feu (Windows) ou de les désactiver via la méthode prise en charge par le fournisseur de pare-feu pour tester ICMP.

   1. Telnet et PsPing sont mieux adaptés aux tests. Exécutez Telnet ou PsPing à partir du nœud source vers le nœud de destination sur un port d’écoute (par exemple, 445).
   2. Si l’étape 1 réussit, la connectivité externe fonctionne. Continuez à tester la connectivité de base.
   3. Si l’étape 1 échoue (et si les profils de pare-feu netsh netconnection sont désactivés), rassemblez une trace de scénario double pour résoudre les problèmes.

Étape 5 : Effectuer une commande Ping ou Telnet sur la passerelle par défaut

Lorsque le nœud peut effectuer un test ping sur sa passerelle par défaut, une connectivité externe (par exemple, une connectivité off-box) est possible à partir du nœud source. D’autres tests sont toujours nécessaires pour comprendre s’il existe un problème de connectivité de base. Si le nœud ne peut pas effectuer un test ping ou Telnet sur sa passerelle par défaut, cela signifie que les réponses ICMP sont désactivées sur le routeur.

Étape 6 : Vérifier les problèmes qui affectent le nœud de destination spécifique

Si le nœud source peut effectuer un test ping, Telnet ou PsPing vers d’autres nœuds sur le sous-réseau de destination, la connectivité de base et le routage au sein de l’infrastructure fonctionnent. Ce résultat pointe vers un problème qui affecte le nœud de destination spécifique.

1. Essayez d’accéder à Telnet ou PsPing sur le port spécifique sur lequel l’application écoute (par exemple, le port TCP 445 pour SMB). Si la connexion réussit, la connectivité de base au niveau de l’application peut être confirmée. Dans ce cas, vous devez contacter le fournisseur de l’application pour vous aider à déterminer pourquoi l’application ne se connecte pas.

   Remarque

   Le fournisseur de l’application peut être Microsoft si le problème est un échec de connexion à un partage, par exemple. Dans ces situations, il serait utile d’utiliser la trace de scénario netsh netconnection recto verso pour collecter des informations supplémentaires et vous aider à vérifier qu’il n’y a aucun problème dans la pile de mise en réseau.

2. Si la connexion au port spécifique échoue :

   1. Vérifiez que le port est dans un état « à l’écoute » :
      CMD: netstat -nato | findstr :<port>
      Powershell: Get-NetTcpConnection -LocalPort <port>
   2. Désactivez temporairement tous les profils de pare-feu. (Remarque : Désactivez uniquement les profils. Ne désactivez pas le service.)
      Si cela réussit, le pare-feu doit être reconfiguré pour autoriser le trafic de l’application sur son port spécifique.
   3. Supprimez toutes les applications tierces une par une, puis testez entre chaque suppression.
      Si cela réussit, contactez le fournisseur du logiciel problématique.
   4. Essayez le mode sans échec avec mise en réseau.
      Si cela réussit, isolez la cause en exécutant un « démarrage propre » du nœud à l’aide de MSConfig, puis en activant les applications et services tiers un par un jusqu’à ce que le problème se reproduise.
   5. Lorsque vous reproduisez la tentative de connexion, vous devez exécuter une trace de scénario netsh netconnection à partir de la source vers le nœud de destination affecté. Un SDP de mise en réseau serait également avantageux.

3. Si le nœud ne peut pas effectuer un test ping, Telnet ou PsPing à d’autres nœuds sur le sous-réseau de destination, le problème peut probablement être lié à l’infrastructure. Là encore, ICMP peut être bloqué dans l’environnement. Par conséquent, vérifiez la connectivité à l’aide de Telnet ou PsPing pour vous connecter aux ports d’écoute connus. À ce stade, une trace réseau recto verso est nécessaire pour indiquer où la perte de paquets se produit sur le réseau. Assurez-vous que les deux traces sont en cours d’exécution avant d’essayer le test de connectivité afin que le problème soit capturé.

Problèmes courants et solutions

La connexion TCP/IP à un hôte semble s’être arrêtée

Ce problème se produit parce que les données sont bloquées dans les files d’attente TCP et UDP ou qu’il existe des problèmes de retard logiciel au niveau du réseau ou de l’utilisateur.

Pour résoudre ce problème, utilisez la netstat -a commande pour afficher les status de toutes les activités sur les ports TCP et UDP de l’ordinateur local.
L’état d’une bonne connexion TCP est établi tout en ayant zéro (0) octet dans les files d’attente d’envoi et de réception. Si les données sont bloquées dans l’une ou l’autre file d’attente, ou si l’état est irrégulier, la connexion est probablement défaillante. Si ce n’est pas le cas, vous rencontrez probablement un retard logiciel au niveau du réseau ou de l’utilisateur.

Temps de connexion longs lors de l’utilisation de Lmhosts pour la résolution de noms

Ce problème se produit parce que le fichier Lmhosts est analysé séquentiellement pour rechercher les entrées sans l’option #PRE.

Pour résoudre ce problème, placez les entrées fréquemment utilisées en haut du fichier et les entrées #PRE en bas. Si une entrée est ajoutée à la fin d’un fichier Lmhosts volumineux, marquez l’entrée dans Lmhosts comme entrée préchargée à l’aide de l’option #PRE. Ensuite, exécutez la nbtstat -R commande pour mettre à jour immédiatement le cache de noms locaux.

L’erreur système 53 s’est produite

L’erreur système 53 est retournée si la résolution de noms échoue pour un nom d’ordinateur particulier lorsque la net use commande est utilisée.

Si l’ordinateur se trouve sur le sous-réseau local, vérifiez que le nom est correctement orthographié et que l’ordinateur cible exécute également TCP/IP. Si l’ordinateur n’est pas sur le sous-réseau local, assurez-vous que son nom et son mappage d’adresse IP sont disponibles dans le fichier Lmhosts ou la base de données WINS. Si tous les éléments TCP/IP semblent être installés correctement, utilisez la ping commande avec l’ordinateur distant pour vérifier que son logiciel TCP/IP fonctionne.

Impossible de se connecter à un serveur spécifique

Ce problème se produit parce que la résolution de noms NetBIOS ne résout pas le nom ou que l’adresse IP incorrecte est en cours de résolution.

Pour résoudre ce problème, utilisez la nbtstat -n commande sur le serveur pour déterminer les noms que le serveur a inscrits sur le réseau. Le nom de l’ordinateur auquel vous essayez de vous connecter doit figurer dans la liste affichée. Si le nom n’est pas répertorié, essayez l’un des autres noms d’ordinateurs uniques affichés par nbtstat. Si le nom utilisé par un ordinateur distant est identique au nom affiché par la nbtstat -n commande, vérifiez que l’ordinateur distant dispose d’une entrée pour le nom du serveur qui se trouve sur le serveur WINS ou dans son fichier Lmhosts.

Impossible d’ajouter une passerelle par défaut

Ce problème se produit car l’adresse IP de la passerelle par défaut ne se trouve pas sur le même ID réseau IP que votre adresse IP.

Pour résoudre ce problème, déterminez si la passerelle par défaut se trouve sur le même réseau logique que la carte réseau de l’ordinateur en comparant l’adresse IP de la passerelle par défaut avec les ID réseau de l’une des cartes réseau de l’ordinateur.

Par exemple, un ordinateur dispose d’une seule carte réseau configurée avec une adresse IP 192.168.0.33 et un masque de sous-réseau de 255.255.0.0. Pour cela, la passerelle par défaut doit être au format « 192.168.<y>.<z> », car la partie ID réseau de l’interface IP est 192.168.0.0.

Collecte de données

Avant de contacter le support Microsoft, vous pouvez collecter des informations sur votre problème.

Configuration requise

1. Le service TSS doit être exécuté par des comptes disposant de privilèges d’administrateur sur le système local, et le CLUF doit être accepté (une fois que le CLUF est accepté, TSS n’y invite plus).
2. Nous vous recommandons d’utiliser la stratégie d’exécution PowerShell de l’ordinateur RemoteSigned local.

Collecter les informations clés avant de contacter le support Microsoft

1. Téléchargez TSS sur tous les nœuds et décompressez-le dans le dossier C :\tss .

2. Ouvrez le dossier C :\tss à partir d’une invite de commandes PowerShell avec élévation de privilèges.

3. Démarrez les traces sur le serveur source et le serveur de destination à l’aide de l’applet de commande suivante :

   TSS.ps1 -Scenario NET_General
   

4. Acceptez le CLUF si les traces sont exécutées pour la première fois sur le serveur source ou de destination.

5. Autoriser l’enregistrement (PSR ou vidéo).

6. Reproduisez le problème avant d’entrer Y.

   Remarque

   Si vous collectez des journaux sur le client et sur le serveur, attendez ce message sur les deux nœuds avant de reproduire le problème.

7. Entrez Y pour terminer la collecte des journaux une fois le problème reproduit.

Les traces sont stockées dans un fichier zip dans le dossier C :\MS_DATA , qui peut être chargé dans l’espace de travail à des fins d’analyse.

Référence

• Résoudre les problèmes de connectivité TCP/IP
• Résoudre les problèmes d’épuisement des ports
• Résoudre les erreurs d’appel de procédure distante (RPC)
• Collecter des données à l’aide du Moniteur réseau
• Échec de l’ouverture des propriétés TCP/IP de la carte réseau
• SMB hôte direct sur TCP/IP
• Configurer la mise en réseau TCP/IP lorsque NetBIOS est désactivé
• Arrêt du trafic TCP
• La plage de ports dynamiques par défaut pour TCP/IP a changé
• Les propriétés TCP/IP reviennent aux paramètres par défaut