Résoudre les problèmes de connectivité TCP/IP

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

S’applique à : versions prises en charge du client Windows et de Windows Server

Cet article fournit un guide complet pour résoudre les erreurs de connectivité TCP/IP.

Symptômes et analyse

Vous pouvez rencontrer des problèmes de connectivité au niveau de l’application ou rencontrer des erreurs de délai d’expiration. Voici quelques scénarios courants :

• Connectivité d’application à un serveur de base de données
• Erreurs de délai d’expiration SQL
• Erreurs de délai d’expiration de l’application BizTalk
• Échecs rdp (Remote Desktop Protocol)
• Échecs d’accès au partage de fichiers
• Connectivité générale

Lorsqu’un problème lié au réseau est soupçonné, nous vous recommandons de collecter une capture de paquets réseau. Cette capture peut être filtrée pour identifier la connexion TCP problématique et déterminer la cause de l’échec.

Pendant le processus de résolution des problèmes, vous pouvez rencontrer une réinitialisation TCP dans la capture réseau, ce qui peut indiquer un problème réseau.

Introduction de TCP

TCP est caractérisé comme un protocole fiable et orienté connexion. Il garantit la fiabilité via le processus de négociation. Une session TCP démarre avec une négociation tridirectionnel, suivie du transfert de données, et se termine par une fermeture à quatre voies.

• Une fermeture à quatre voies, où l’expéditeur et le destinataire acceptent de fermer la session, est appelée fermeture normale. Cela est identifié par l’indicateur FIN dans l’en-tête TCP défini sur 1.

• Après la fermeture à quatre voies, la machine attend 4 minutes (par défaut) avant de libérer le port. Il s’agit d’un état TIME_WAIT. Pendant cet état TIME_WAIT, tous les paquets en attente pour la connexion TCP peuvent être traités. Une fois l’état TIME_WAIT terminé, toutes les ressources allouées pour la connexion sont libérées.

• Une réinitialisation TCP est une fermeture brusque de session, ce qui entraîne la libération immédiate des ressources allouées et l’effacement de toutes les informations de connexion. Cela est identifié par l’indicateur RESET dans l’en-tête TCP défini sur 1. Une trace réseau collectée simultanément sur la source et la destination vous aide à déterminer le flux du trafic et à identifier le point de défaillance.

Les sections suivantes décrivent les scénarios dans lesquels une RÉINITIALISATION peut se produire.

Perte de paquets sur le réseau

Lorsqu’un homologue TCP envoie des paquets sans recevoir de réponse, l’homologue retransmet les données. S’il n’y a toujours aucune réponse, la session se termine par une réinitialisation ACK, indiquant que l’application reconnaît les données échangées, mais ferme la connexion en raison d’une perte de paquets.

Les traces réseau simultanées à la fois à la source et à la destination peuvent vérifier ce comportement. Côté source, vous pouvez voir les paquets retransmis. Côté destination, ces paquets ne sont pas présents. Ce scénario indique qu’un appareil réseau entre la source et la destination supprime les paquets.

Scénario 1 : Perte de paquets pendant l’établissement d’une liaison TCP initiale

Si la négociation TCP initiale échoue en raison d’une chute de paquets, le paquet TCP SYN est retransmis trois fois par défaut.

Note

Le nombre de fois où le paquet TCP SYN est retransmis peut être différent en fonction du système d’exploitation. Cela est déterminé par la valeur Max SYN Retransmissions sous paramètres TCP Global , qui peuvent être consultés à l’aide de la commande netsh int tcp show global.

Supposons qu’une machine source avec l’adresse IP 10.10.10.1 se connecte à la destination avec l’adresse IP 10.10.10.2 sur le port TCP 445. Voici une capture d’écran de la trace réseau collectée sur l’ordinateur source, qui montre la négociation TCP initiale où le paquet TCP SYN est envoyé, puis retransmis par la source, car aucune réponse n’a été reçue de la destination.

La même conversation TCP vue dans la trace réseau collectée sur la destination indique qu’aucun des paquets ci-dessus n’a été reçu par la destination. Cela implique que le paquet TCP SYN a été supprimé sur le réseau intermédiaire.

Si les paquets TCP SYN atteignent la destination, mais que la destination ne répond pas, vérifiez si le port TCP connecté est dans l’état d’écoute sur l’ordinateur de destination. Cela peut être archivé dans la sortie de la commande netstat -anob.

Si le port écoute et qu’il n’y a toujours aucune réponse, il peut y avoir une baisse à la plateforme de filtrage Windows (PAM).

Scénario 2 : Perte de paquets pendant le transfert de données après l’établissement de la connexion TCP

Dans un scénario où un paquet de données envoyé après l’établissement de la connexion TCP est supprimé sur le réseau, TCP retransmet le paquet cinq fois par défaut.

Supposons qu’une machine source avec l’adresse IP 192.168.1.62 a établi une connexion avec l’ordinateur de destination ayant l’adresse IP 192.168.1.2 sur le port TCP 445. La machine source envoie des données (paquet SMB Negotiate) qui sont retransmises cinq fois, comme indiqué ci-dessous. Après l’absence de réponse de destination, la machine source envoie un ACK-RST pour fermer cette connexion TCP.

Source 192.168.1.62 trace latérale :

Vous ne verrez aucun des paquets ci-dessus qui atteignent la destination.

Vous devez impliquer votre équipe réseau interne pour examiner les différents tronçons entre la source et la destination, et vérifier si l’un des tronçons peut entraîner des chutes de paquets.

Paramètre incorrect dans l’en-tête TCP

Ce comportement se produit lorsque les appareils intermédiaires du réseau modifient les paquets, ce qui provoque le rejet du protocole TCP à la fin de réception. Par exemple, le numéro de séquence TCP peut être modifié, ou les paquets peuvent être relectés par un appareil intermédiaire avec un numéro de séquence TCP modifié.

Une trace réseau simultanée sur la source et la destination peut aider à identifier les modifications apportées aux en-têtes TCP.

Commencez par comparer les traces source et de destination pour détecter les modifications apportées aux paquets ou la présence de nouveaux paquets atteignant la destination pour le compte de la source.

Dans ce cas, nous vous recommandons de demander de l’aide de l’équipe réseau interne pour identifier les appareils qui modifient ou relecture des paquets vers la destination. Les coupables courants incluent des appareils Riverbed ou des accélérateurs WAN.

Réinitialisation au niveau de l’application

Lorsque vous avez déterminé que les réinitialisations ne sont pas dues à des suppressions de paquets, à des paramètres incorrects ou à des modifications de paquets (comme identifiés par le biais de traces réseau), vous pouvez conclure que le problème est une réinitialisation au niveau de l’application.

Les réinitialisations au niveau de l’application sont caractérisées par l’indicateur d’accusé de réception (ACK) défini sur 1, ainsi que l’indicateur de réinitialisation (R). Cela indique que le serveur accuse réception du paquet, mais n’accepte pas la connexion pour une raison quelconque. Ce problème se produit généralement lorsque l’application qui reçoit le paquet trouve quelque chose d’inacceptable dans les données.

Dans les captures d’écran ci-dessous, vous pouvez observer que les paquets à la fois à la source et à la destination sont identiques, sans aucune modification ni suppression. Toutefois, une réinitialisation explicite est envoyée par la destination à la source.

Trace côté source :

Trace côté destination :

Un paquet TCP avec indicateur ACK+RST peut également se produire lorsqu’un paquet TCP SYN est envoyé. Le paquet TCP SYN est initié par l’ordinateur source pour établir une connexion sur un port spécifique. Toutefois, si le serveur de destination ne souhaite pas accepter le paquet pour une raison quelconque, le serveur répond avec un paquet ACK+RST.

Dans ce cas, il est essentiel d’examiner l’application à l’origine de la réinitialisation (identifiée par les numéros de port) pour comprendre pourquoi la connexion est réinitialisée.

Note

Les informations ci-dessus concernent les réinitialisations du point de vue TCP et non UDP. UDP est un protocole sans connexion, et les paquets sont envoyés de manière non valide. Par conséquent, les retransmissions ou les réinitialisations ne sont pas observées lors de l’utilisation d’UDP comme protocole de transport. Toutefois, UDP utilise ICMP comme protocole de création de rapports d’erreurs. Lorsqu’un paquet UDP est envoyé à un port qui n’est pas répertorié à la destination, la destination répond immédiatement avec un message ICMP « Hôte de destination inaccessible : port inaccessible ».

10.10.10.1  10.10.10.2  UDP UDP:SrcPort=49875,DstPort=3343
 
10.10.10.2  10.10.10.1  ICMP    ICMP:Destination Unreachable Message, Port Unreachable,10.10.10.2:3343

Lors de la résolution des problèmes de connectivité TCP/IP, vous pouvez observer dans la trace réseau qu’une machine reçoit des paquets, mais ne répond pas à ces problèmes. Cela peut indiquer une suppression sur la pile réseau du serveur de destination.

Pour déterminer si le Pare-feu Windows local supprime le paquet, activez l’audit pour la plateforme de filtrage Windows (PAM) sur l’ordinateur à l’aide de la commande suivante.

auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable

Vous pouvez ensuite consulter les journaux des événements de sécurité pour identifier une suppression de paquets sur un port TCP et une adresse IP spécifiques, ainsi qu’un ID de filtre PAM associé.

Ensuite, exécutez la commande netsh wfp show state qui génère un fichier wfpstate.xml .

Vous pouvez ouvrir ce fichier à l’aide du Bloc-notes et filtrer l’ID trouvé dans les journaux d’événements (par exemple, 2944008 dans l’exemple d’événement). Le résultat révèle le nom de règle de pare-feu associé à l’ID de filtre qui bloque la connexion.