Retransmissions TCP face aux rejets de rejeu IPsec : lire chaque couche

Trois outils différents signalent trois doublons différents, et un seul d’entre eux est un événement réseau sur lequel vous pouvez agir. Une retransmission TCP est un émetteur qui renvoie une plage, un ACK dupliqué est un récepteur qui répète un accusé de réception, et un rejet de rejeu ESP est une association de sécurité qui refuse un numéro de séquence qu’elle a déjà accepté. Aucun des trois n’implique l’un des autres. Lisez chaque compteur à la couche qui le produit avant de les relier en une histoire.

Trois compteurs qui ne mesurent jamais le même événement

L’annotation de retransmission TCP signifie que l’émetteur a de nouveau placé une plage de séquence sur le fil. La perte est l’une des raisons, et la capture que vous détenez peut simplement manquer du paquet d’origine ou de l’accusé de réception qui expliquerait le moment. Un ACK dupliqué est le récepteur qui répète un accusé de réception cumulatif selon les règles de récupération TCP, ce qui n’est ni une écriture applicative dupliquée ni une seconde copie des données.

ESP travaille dans son propre espace de séquence. Chaque association de sécurité numérote les paquets qu’elle envoie, et le récepteur conserve une fenêtre de numéros qu’il a déjà acceptés, si bien qu’un paquet ESP qui arrive deux fois est écarté sur cette seule base. Un segment TCP retransmis voyage donc dans un paquet ESP neuf avec un numéro de séquence neuf, ce qui est le comportement correct aux deux couches. Les mêmes octets peuvent paraître neufs dans un compteur et anciens dans un autre, et aucune des deux couches ne ment.

Ce que l’analyseur peut voir et ce qu’il ne peut pas

Commencez par le vocabulaire de l’analyseur, car les noms de filtres décrivent des observations et non l’intérieur des points de terminaison. Compter avec les mêmes noms que ceux utilisés par l’outil vous garde honnête sur ce qui a été réellement mesuré. Un décompte issu d’une capture incomplète est un décompte de ce qui a survécu, non de ce qui s’est produit sur le fil.

tshark -r trace.pcap -Y "tcp.analysis.retransmission" | wc -l
tshark -r trace.pcap -Y "tcp.analysis.duplicate_ack" | wc -l

Lisez les informations expertes à côté de ces chiffres, car les avertissements de somme de contrôle et d’ordre changent le poids qu’ils méritent. Une trace fusionnée de deux capteurs peut montrer une trame deux fois, et compter les deux copies invente un événement de récupération qui n’a jamais eu lieu.

Les compteurs ESP vivent dans l’état du noyau

Les numéros de séquence ESP appartiennent à l’association de sécurité, pas au flux TCP, donc la passerelle est l’endroit où demander. La liste d’état rapporte des compteurs de paquets et d’erreurs par association qu’aucune capture ne peut reconstruire.

ip -s xfrm state
tshark -r trace.pcap -Y "esp" -T fields -e esp.seq | head

RFC 4303 définit le numéro de séquence et la fenêtre anti-rejeu qui le consomme, ce qui explique que le compteur augmente même lorsque rien ne va mal. Des numéros de séquence externes monotones sans anomalie TCP correspondante désignent un autre émetteur ou un chemin dupliqué plutôt qu’une tempête de retransmissions. Une capture externe d’un tunnel chiffré masque normalement les numéros de séquence TCP internes, elle ne peut donc pas prouver ce que la pile interne a fait. Capturez à l’intérieur du tunnel seulement là où la politique l’autorise, et ne désactivez jamais l’anti-rejeu pour faire taire un avertissement sans rapport.

Où le point d’observation change la réponse

Avant d’escalader, notez comment la capture a été prise : l’interface, si le processus de capture a signalé des pertes et si les horodatages sont comparables entre capteurs. Un seul point d’observation ne peut pas voir les deux extrémités d’un chemin, donc toute affirmation sur le comportement du récepteur est une inférence et non une mesure. Une trace prise sur la passerelle et une trace prise sur l’hôte seront en désaccord sur l’ordre sous charge, et ce désaccord appartient généralement à la capture plutôt qu’au tunnel. Corréler deux vues est ce qui transforme un décompte en preuve.

Utilisez un flux applicatif autorisé et relevez les compteurs des points de terminaison à côté des décomptes de la capture au même moment. Si les chiffres divergent, faites confiance à la couche qui possède l’événement et traitez l’autre comme un artefact d’observation jusqu’à preuve du contraire. Cette règle règle la plupart de ces cas sans toucher à la configuration du tunnel.

Lire les chiffres dans le bon ordre

Commencez par la couche où la question a été posée : un avertissement TCP se répond à partir d’une capture TCP, et un rejet ESP se répond à partir des compteurs de l’association de sécurité sur la passerelle. C’est seulement ensuite que vous demandez si les deux vues décrivent le même paquet. Une conclusion qui exige les deux couches devrait nommer les deux, car une affirmation sur le tunnel reposant sur une seule annotation TCP est une supposition.

Notez la couche, le compteur et le point d’observation pour chaque constat, et le prochain lecteur ne fusionnera pas trois événements en une panne imaginaire. Escaladez avec ces trois champs et le correctif découle généralement du premier.