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

Article
12/14/2024

Essayez notre agent virtuel : il peut vous aider à identifier et à résoudre rapidement les problèmes courants liés à la réplication Active Directory.

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

Outils de résolution des problèmes

La commande ping est utile pour tester la connectivité de base. Toutefois, vous ne devez pas vous appuyer sur ce service pour prouver la connectivité générale. Telnet et PsPing sont plus utiles, pour les raisons suivantes :

Ces outils peuvent tester la connectivité sur 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 accéder aux ports ouverts sur un pare-feu.
Vous pouvez vous connecter à n’importe quel port d’« écoute » sur le nœud de destination pour vérifier l’accès au port d’une application spécifique.

Liste de contrôle pour la résolution des problèmes

Étape 1 : Capturer un diagramme réseau

Capturez un diagramme de réseau détaillant les appareils qui se trouvent dans le chemin de la zone affectée. En particulier, notez les appareils suivants :

Pare-feux
IPS (protection contre les intrusions/systèmes de prévention)
DPI (inspection approfondie des paquets)
Accélérateurs WAN

Le diagramme peut vous aider à visualiser la zone responsable du problème.

Étape 2 : Traces réseau

Les traces réseau sont utiles pour voir ce qui se passe au niveau du réseau quand 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 les messages d’erreur qui s’affichent.

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.

Recherchez 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 montre que l’indicateur d’état de la connexion réseau (NSCI) a échoué pendant une vérification par sondage.

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

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. Utilisez la procédure de résolution des problèmes suivante :

Vérifiez les derniers bits sur le nœud (TCP/IP, NDIS, AFD, Winsock, etc.).
Réinitialisez l’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
```
Redémarrez le nœud.
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
```
Désinstallez ou réinstallez le pilote de carte réseau, le cas échéant.
Recherchez les pilotes de filtre tiers (par exemple, antivirus) et supprimez-les.
Essayez de démarrer l’ordinateur en Mode sans échec avec prise en charge réseau. Si le mode sans échec avec la 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 réactivez-les un par un jusqu’à ce que le problème retourne. 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 lié à une entrée de Registre endommagée.
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. La prise de la cause racine de la corruption peut être difficile et extrêmement fastidieuse. Même si la corruption est trouvée, sachant ce qui a causé cela est encore plus difficile. La modification manuelle de la clé de Registre endommagée met le nœud dans un état non pris en charge. Par conséquent, nous recommandons au client de restaurer ou recharger le nœud afin de corriger la défaillance.

Si la NSCI échoue à sa vérification de sonde (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 le doit.

Dans ce cas, l’investigation doit se concentrer spécifiquement sur la raison pour laquelle la vérification par sondage de NCSI échoue. Les détails de cet article sont traités dans une rubrique distincte.
Si ce n’est pas le cas, investiguez d’abord les problèmes de connectivité, car ils sont susceptibles d’être corrigés une fois la connectivité restaurée.

Étape 4 : Résoudre les messages d’erreur qui se produisent pendant le test ping ou telnet

Si le nœud peut effectuer un test ping ou Telnet sur des nœuds du même sous-réseau ou segment de réseau, cela confirme que la connectivité externe fonctionne. Des tests supplémentaires sont toujours nécessaires pour déterminer s’il y a un problème avec la connectivité de base.

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

L’erreur irrécupérable de l’hôte de destination signifie que les requêtes ARP envoyées par le nœud ne reçoivent pas de réponse.
Rassemblez une trace à deux côtés à 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 s’afficher dans la trace source. En cas d’échec de ce processus, le problème est probablement lié à une erreur de configuration ou à d’autres problèmes affectant l’infrastructure.

Les causes possibles sont :
1. VLAN incorrects ou incompatibles.
2. Configuration de port de commutateur incorrecte (mode trunk et port d’accès).
3. Autres problèmes matériels.
L’erreur de délai d’attente de la requête a expiré 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, seul, n’indique pas de problème. Le trafic ICMP peut être bloqué par le réseau ou le logiciel de pare-feu sur les nœuds. Essayez de désactiver les profils de pare-feu (Windows) ou de les désactiver avec la méthode prise en charge par le fournisseur de pare-feu pour tester ICMP.
1. Telnet et PsPing conviennent mieux pour le test. Effectuez un test 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. Vous pouvez tester la connectivité de base.
3. Si l’étape 1 n’est pas réussie (et si les profils de pare-feu sont désactivés), rassemblez une trace de scénario à deux côtés netsh netconnection pour résoudre les problèmes supplémentaires.

Étape 5 : Ping ou Telnet vers la passerelle par défaut

Quand le nœud peut effectuer un test ping sur sa passerelle par défaut, une connectivité externe (comme la connectivité off-box) est possible à partir du nœud source. Des tests supplémentaires sont toujours nécessaires pour déterminer s’il y a un problème avec la connectivité de base. Si le nœud ne peut pas effectuer un test ping ou Telnet vers 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é et le routage de base au sein de l’infrastructure fonctionnent. Ce résultat indique un problème qui affecte le nœud de destination spécifique.

Essayez d’effectuer un test 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 qu’il vous aide à investiguer pourquoi l’application ne se connecte pas.

Note

Le fournisseur d’applications peut être Microsoft si le problème est un échec de connexion à un partage, par exemple. Dans ce cas, collectez une trace des deux côtés du scénario netsh netconnection pour recueillir des informations supplémentaires et vous aider à vérifier qu’il n’y a aucun problème dans la pile réseau.
Si la connexion au port spécifique n’a pas réussi :
1. Assurez-vous que le port est dans un état « d’é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 fonctionne, 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 effectuez un test entre chaque suppression.
  Si cela fonctionne, contactez le fournisseur du logiciel à l’origine du problème.
4. Essayez le Mode sans échec avec prise en charge 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. Quand vous reproduisez la tentative de connexion, vous devez exécuter une trace de scénario netsh netconnect à partir de la source vers le nœud de destination affecté. Un SDP réseau peut également être bénéfique.
Si le nœud ne peut pas effectuer de test ping, Telnet ou PsPing vers d’autres nœuds sur le sous-réseau de destination, le problème peut probablement être lié à l’infrastructure. De nouveau, ICMP peut être bloqué au sein de l’environnement. Par conséquent, vérifiez la connectivité en utilisant Telnet ou PsPing pour vous connecter aux ports d’écoute connus. À ce stade, une trace réseau des deux côtés est nécessaire pour indiquer l’endroit où se produit la perte de paquets sur le réseau. Vérifiez que les deux traces sont en cours d’exécution avant d’essayer le test de connectivité, pour que le problème soit capturé.

Problèmes courants et solutions

La connexion TCP/IP à un hôte semble avoir cessé

Ce problème se produit, car les données sont bloquées dans les files d’attente TCP et UDP, ou 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 l’état de toutes les activités sur les ports TCP et UDP sur l’ordinateur local.
L’état d’une bonne connexion TCP est établi tout en ayant zéro (0) octets dans les files d’attente d’envoi et de réception. Si les données sont bloquées dans l’une ou l’autre des files d’attente, ou si l’état est irrégulier, la connexion est probablement en cause. Si ce n’est pas le cas, vous rencontrez probablement un délai 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 localiser 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 commande nbtstat -R pour mettre à jour le cache de noms local immédiatement.

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, vérifiez que son nom et son mappage d’adresses 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 résolue.

Pour résoudre ce problème, utilisez la nbtstat -n commande sur le serveur pour déterminer le nom du serveur inscrit 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’ordinateur 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 a 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 parce que l’adresse IP de la passerelle par défaut n’est 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 a une seule carte réseau configurée avec l’adresse IP 192.168.0.33 et le masque de sous-réseau 255.255.0.0. Cela nécessite que la passerelle par défaut soit de la forme « 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.

Prerequisites

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 l’CLUF est accepté, TSS n’invite pas à nouveau).
Nous recommandons la stratégie d’exécution powerShell de l’ordinateur RemoteSigned local.

Note

Si la stratégie d’exécution PowerShell actuelle n’autorise pas l’exécution de TSS, effectuez les actions suivantes :

Définissez la RemoteSigned stratégie d’exécution pour le niveau de processus en exécutant l’applet de commande PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned.
Pour vérifier si la modification prend effet, exécutez l’applet de commande PS C:\> Get-ExecutionPolicy -List.
Étant donné que les autorisations au niveau du processus s’appliquent uniquement à la session PowerShell actuelle, une fois que la fenêtre PowerShell donnée dans laquelle TSS s’exécute est fermée, l’autorisation affectée pour le niveau de processus revient également à l’état précédemment configuré.

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

Téléchargez TSS sur tous les nœuds et décompressez-le dans le dossier C :\tss .
Ouvrez le dossier C :\tss à partir d’une invite de commandes PowerShell avec élévation de privilèges.
Démarrez les traces sur le serveur source et de destination à l’aide de l’applet de commande suivante :
```
TSS.ps1 -Scenario NET_General
```
Acceptez le CLUF si les traces sont exécutées pour la première fois sur la source ou le serveur de destination.
Autoriser l’enregistrement (PSR ou vidéo).
Reproduire le problème avant d’entrer Y.

Note

Si vous collectez des journaux sur le client et le serveur, attendez ce message sur les deux nœuds avant de reproduire le problème.
Entrez Y pour terminer la collection de 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.

Partager via