Comment résoudre les problèmes de connectivité TCP / IP et de configuration
Lorsque vous devez vous assurer que les applications du serveur peuvent se connecter correctement, le dépannage général n’aide en rien. Elle appelle des moyens avancés pour dépanner la connectivité TCP / IP surtout quand vous avez beaucoup d'erreur de timeout. Le problème de connectivité pourrait être lié au serveur de base de données, aux échecs RDP, au partage de fichiers, etc..
Au niveau de base, lorsque les données sont envoyées d'un point à un autre via TCP, à la fin, l'expéditeur et le destinataire conviennent que les informations sont ce qu'elles devraient être et que tout va bien. Chaque fois qu'il y a un problème avec TCP, l'un des côtés continue d'attendre (état TIME_WAIT), il peut y avoir une fermeture abrupte des sessions, ce qui entraîne l'indicateur RESET dans l'en-tête TCP..
Dépanner la connectivité TCP / IP
Cet indicateur RESET peut être vu à l'aide de l'outil Message Analyzer ou de l'un des outils de surveillance du réseau qui peut vous aider à comprendre l'en-tête TCP. L'en-tête contient des informations qui permettent d'identifier s'il y avait un problème, en particulier l'indicateur RESET. Imaginez que chaque donnée envoyée ait un en-tête ou un émetteur qui donne des informations sur la localisation des données.
Lors de l'utilisation de Message Analyzer, vous devez définir l'adresse IP du serveur, le numéro de port, s'il est disponible, et explorer chaque résultat de trace pour obtenir des informations détaillées. S'il y a une erreur, l'outil la marquera. Cliquez dessus et vous devriez pouvoir voir le niveau du message d'erreur pour ce paquet. Il est facile à utiliser, mais il faut aussi bien comprendre comment l'utiliser..
Trouver des gouttes de paquets
Lorsque des données sont envoyées et qu'aucune réponse n'est reçue de l'autre extrémité, cela signifie qu'il y a une perte de paquet. La source attend la confirmation et, si elle n'est pas acceptée, envoie un ping avec l'indicateur ACK RESET. Cet indicateur signifie que, puisqu'il n'y a pas eu de confirmation, cela signifie qu'il peut y avoir des pertes de paquets ou des données, d'où la perte de la connexion..
Cela signifie généralement que le périphérique réseau entre les deux a un problème. Utilisez l'outil Réseau pour surveiller les ports et exécuter le programme de trace. Si vous ne voyez pas les mêmes résultats de trace, vous savez que le problème se situe quelque part entre.Le paramètre incorrect dans l'en-tête TCP
Les périphériques et les logiciels intermédiaires modifient généralement les en-têtes TCP. Il est standard sur les ordinateurs où un logiciel de sécurité Internet modifie les certificats provenant de sites Web compatibles HTTPS. Les périphériques tels que les accélérateurs de réseau étendu peuvent faire de même. L’administrateur informatique devra examiner la configuration de ces périphériques matériels pour résoudre ce problème..
Pour comprendre cela, vous aurez exécuté la trace à la fois sur la source et sur la destination. Si les résultats diffèrent, en particulier les détails du paquet TCP, nous avons un problème..
Réinitialisation côté application
Si les traces ne montrent rien de probabiliste, c'est peut-être l'application qui est à l'origine du problème. Cela se produit lorsque le serveur a accepté les données reçues mais n’accepte pas la connexion. Donc, l'application serait comme si elle n'avait rien obtenu, et vous vous demanderiez si tous les liens sont en place.
Vous pouvez identifier ce scénario en consultant les indicateurs TCP. Si le paquet contient ACK + RST, cela signifie que l’application est à l’origine du problème, c’est-à-dire que la destination / le serveur, pour une raison quelconque, ne souhaite pas accepter le package pour une raison quelconque..
Si votre application utilise UDP, il sera difficile de le trouver de cette façon. Au lieu de cela, vous devrez utiliser ICMP comme protocole de rapport d'erreur. Si vous remarquez un message Hôte de destination ICMP inaccessible: port inaccessible message immédiatement après le paquet UDP, alors l'application est la cause.
Conseils:
- Lors du dépannage, si tout se passe bien, mais que le serveur ne répond pas, il peut s'agir d'un problème de pare-feu. Assurez-vous de reconfigurer le pare-feu pour garder ces ports ou applications propres. Vous devrez regarder le pare-feu local et le pare-feu du serveur.
- Consultez également les journaux des événements de sécurité. Vous pouvez surveiller s'il y a une chute de paquet sur un port-IP particulier.
