Le TCP a été conçu pour prendre en charge les connexions de bout en bout, c'est-à-dire un hôte communiquant directement avec un autre hôte. Bien sûr, il y avait des ponts et des routeurs entre les deux, mais ces dispositifs ne touchaient ni l'en-tête TCP ni la charge utile. Mais ce n'est plus le cas aujourd'hui. Nous avons maintenant des choses comme les traducteurs d'adresses réseau, les pare-feu, les systèmes de prévention des intrusions et les accélérateurs de réseau. Toutes ces choses peuvent soit modifier l'en-tête TCP, envoyer des accusés de réception ou des réinitialisations, soit simplement déposer le paquet dans le seau de bits. Pour aggraver les choses, ces dispositifs se trouvent à chaque extrémité du réseau et parfois aussi au milieu.
Imaginez le cas d'un hôte A sur le réseau B avec une connexion à l'hôte Y sur le réseau Z. Devant le réseau B se trouve un accélérateur WAN qui augmente le débit en spoofant les acquittements de l'hôte Y. Cela permet à l'hôte A d'envoyer des données aussi vite qu'il le peut. L'accélérateur s'occupe de la mise en mémoire tampon et des retransmissions. Malheureusement, le système de prévention des intrusions devant le réseau Z laisse tomber un paquet d'apparence innocente mais suspecte de l'hôte A. L'hôte Y ne le voit jamais et ne l'accuse donc pas réception. L'accélérateur WAN devant le réseau B retransmet, mais bien sûr, le paquet est à nouveau rejeté. L'accélérateur finit par s'arrêter et renvoie une réinitialisation à l'hôte A et à l'hôte Y.
Que voit l'administrateur du système de l'hôte A lorsqu'il essaie de comprendre ce qui se passe après qu'un utilisateur se soit plaint ? Il voit que les paquets quittent l'hôte A et sont reconnus par l'hôte Y, mais qu'aucune réponse de la couche application n'est reçue de l'hôte Y, puis que l'hôte Y réinitialise la connexion, rien n'indiquant un problème ou pourquoi l'hôte Y a réinitialisé la connexion. Que voit l'administrateur système de l'hôte Y ? Il constate que l'hôte A vient d'arrêter d'envoyer des paquets et qu'il a ensuite envoyé une réinitialisation, mais rien n'indique qu'il y ait eu un problème ou que l'hôte A ait réinitialisé la connexion.
L'hypothèse selon laquelle l'hôte A communique directement avec l'hôte Y est fausse et le fait de faire cette hypothèse amène chaque administrateur à blâmer l'autre système pour l'échec de la connexion.
Afin de comprendre ce qui se passe, vous devez faire attention aux valeurs des champs "inintéressants" des données de trace de l'en-tête IP, des champs comme le "Type de service", l'ID, les drapeaux et le "Time to Live" (TTL). Les modifications de ces champs, par exemple les paquets avec données ont un TTL de 47 et les paquets sans données ont un TTL de 127, peuvent vous indiquer que les paquets proviennent de deux sources différentes.
La comparaison des traces de l'hôte A et de l'hôte Y peut mettre en lumière le problème. Non seulement vous pouvez voir des paquets dans une trace qui ne sont pas dans l'autre mais les changements dans tous ces champs inintéressants de l'en-tête IP ou dans les numéros de port ou de séquence TCP indiqueront avec une certitude de 100% que ces hôtes ne communiquent pas directement entre eux.
Il n'est peut-être pas possible de désactiver l'accélérateur de réseau ou le système de prévention des intrusions (et ce n'est peut-être pas une bonne idée non plus), mais le fait de savoir qu'ils sont là et de savoir ce qu'ils font vous donne une meilleure chance de comprendre et de corriger les problèmes lorsqu'ils surviennent.
Entreprise