Une mauvaise somme de contrôle dans une capture VPN n’est pas une corruption de fichier

L’analyseur signale un paquet comme ayant une mauvaise somme de contrôle, et un fichier téléchargé semble incorrect, si bien que les deux observations se rejoignent en une seule histoire de corruption sur le VPN. Ce sont des mesures différentes prises à des points différents. L’une décrit ce que le mécanisme de capture a vu avant que l’adaptateur réseau n’ait fini son travail ; l’autre décrit les octets que l’application a stockés. Déterminer laquelle des deux a réellement changé, c’est tout le diagnostic.

Où se situe la capture par rapport à l’adaptateur

Une capture de paquets est un instantané à un point d’un chemin qui comporte plusieurs transformations. Entre la pile de l’hôte et le câble se trouvent la segmentation, le calcul de la somme de contrôle et, à la réception, la coalescence. Un point de capture montre l’état à cet instant, qui est rarement identique à la trame finale sur le câble. La lire comme si c’était le câble, c’est précisément ainsi qu’un champ de remplissage devient une accusation.

La question utile à propos d’un champ suspect n’est donc pas de savoir s’il paraît faux, mais où il a été observé. Notez l’interface de capture, la version de l’analyseur et la couche de paquet à côté du constat ; sans ces trois éléments, une étiquette de somme de contrôle ne peut pas du tout être interprétée.

Ce que l’offload d’émission fait à une trace

Lorsque l’offload de somme de contrôle à l’émission est activé, l’adaptateur calcule la somme et remplit le champ après que l’hôte a mis le paquet en file. Une capture côté hôte enregistre donc un remplissage, et l’analyseur signale une somme de contrôle que le câble n’a jamais transportée. L’offload de segmentation crée un artefact similaire, car l’hôte peut remettre à l’adaptateur un seul grand tampon qui devient ensuite plusieurs trames.

La référence sur l’offload de Wireshark décrit les deux effets et note que la reconnaissance des sommes de contrôle partielles dépend de la version de l’analyseur et du type de paquet. C’est pourquoi un outil de capture ancien et un plus récent peuvent diverger sur la même trace alors que tous deux la lisent correctement.

L’encapsulation ajoute un second objet

Un VPN insère un second paquet dans le tableau. L’interface du tunnel montre le paquet interne que l’application a réellement envoyé, tandis que l’interface physique montre la connexion externe encapsulée qui le transporte. Une somme de contrôle ou une longueur prise dans le paquet interne n’appartient pas à la trame externe, et comparer les deux comme si elles décrivaient le même objet produit un non-sens.

Quand il faut comparer, comparez ce qui est comparable : interne avec interne, externe avec externe, au même point du chemin. Une paire de champs qui ne correspond pas prouve seulement que deux objets différents ont été mesurés. Notez de quelle interface provient chaque trace, car une capture de tunnel qui paraît propre ne dit rien de ce que l’adaptateur a émis.

Prouvez l’intégrité du fichier avec des hashes

Pour le fichier lui-même, calculez un hash de contenu d’une source reproductible et du résultat stocké, puis comparez les empreintes. Cela répond à une autre question que n’importe quelle étiquette par paquet, et cela y répond à propos de l’objet qui importe vraiment à l’utilisateur.

sha256sum payload.bin
sha256sum /srv/transfer/payload.bin
cmp -l payload.bin /srv/transfer/payload.bin | head

Des empreintes égales closent la question de la corruption pour ce transfert. Des empreintes différentes en ouvrent une plus étroite : trouvez l’étape la plus précoce où les octets divergent et vérifiez si quelque chose a transformé le fichier à dessein. Un enregistrement partiel, une pièce jointe réencodée et une page d’erreur stockée sous le nom de fichier attendu modifient des octets sans aucun défaut réseau.

Localisez un chemin d’adaptateur sans le rendre permanent

Pour un problème reproductible qui suit un seul dock ou adaptateur, gardez fixes le profil VPN, l’application, l’objet de test et la destination, puis répétez le transfert via une interface alternative prise en charge. Un résultat qui change avec l’adaptateur localise la panne sur ce chemin ; il n’identifie pas encore un réglage de pilote et ne prouve pas un défaut propre à tout un modèle.

Désactiver l’offload globalement est un test tentant et une mauvaise valeur par défaut. Un réglage propre à tout l’hôte affecte un trafic bien au-delà de l’expérience et peut avoir un coût réel en performance, alors traitez tout changement de ce type comme temporaire, consignez-le et annulez-le. Utilisez les diagnostics pris en charge par le fabricant avant de conserver un contournement emprunté à une autre machine.

Le rapport devrait indiquer lequel des trois résultats a changé : l’interprétation d’un paquet par l’analyseur, les octets applicatifs complets ou la reproductibilité d’un chemin d’adaptateur. Ils mènent à trois actions suivantes différentes, et une seule concerne le chiffrement.