L’envoi semble corrompu : comparez les empreintes aux deux extrémités

Les destinataires qui ne peuvent pas ouvrir un fichier envoyé entendent souvent que le VPN l’a corrompu. C’est une hypothèse, pas une observation, et elle est vérifiable. Avant de toucher au tunnel, établissez si l’objet désormais stocké à destination diffère de l’objet qui devait être envoyé. Tout le reste découle de cette réponse.

Partez des octets prévus, pas de la plainte

Choisissez un fichier inoffensif qui reproduit le problème, ou le fichier réel si la politique autorise sa sortie de l’environnement source. Notez deux choses avant le transfert : la taille exacte en octets et une empreinte de contenu moderne. Les noms de fichiers, les horodatages et les aperçus sont des métadonnées, et aucun d’eux n’identifie le contenu.

Calculez l’empreinte avec un algorithme que les deux extrémités peuvent exécuter, et notez lequel vous avez utilisé. Une comparaison entre SHA-256 et MD5 n’est pas une comparaison, et une comparaison entre deux fichiers différents qui partagent un nom par hasard ne l’est pas non plus.

PS> Get-FileHash -LiteralPath "C:\uploads\report.csv" -Algorithm SHA256
Hash                                                        Path
----                                                        ----
9F2C...                                                      C:\uploads\report.csv

La référence Get-FileHash de Microsoft documente la commande et son paramètre d’algorithme, précisément la partie que les gens sautent quand une comparaison produit un écart dénué de sens.

Une empreinte par étape, le même algorithme

Calculez maintenant le même algorithme sur l’objet stocké là où il vit finalement, avec une méthode autorisée plutôt qu’avec une copie passée par un autre outil. Enregistrer localement le fichier reçu et calculer l’empreinte de cette copie ajoute une étape que vous n’avez pas testée.

Si le service expose sa propre valeur d’intégrité, traitez-la comme une observation distincte. Une somme de contrôle rapportée par le fournisseur peut vous dire ce que le fournisseur croit avoir stocké, et ce n’est pas la même affirmation que ce que votre client a envoyé.

Trois issues sont possibles, et elles pointent dans des directions différentes. Des empreintes égales signifient que les octets sont arrivés inchangés. Des empreintes différentes avec une conversion connue signifient que le service a intentionnellement produit un nouvel objet. Des empreintes différentes sans conversion signifient que quelque chose entre les deux points a altéré le contenu, et l’étape suivante est de trouver la frontière la plus précoce où cela s’est produit.

Séparez l’échec de transfert de la transformation

Un envoi partiel et un envoi corrompu se ressemblent dans un navigateur de fichiers et sont des défauts différents. Vérifiez si le transfert s’est terminé : un journal applicatif montrant une requête interrompue, un fichier stocké dont la taille est un préfixe de la source, ou un objet qui est en réalité une page d’erreur enregistrée sous l’extension attendue, tous indiquent un transfert incomplet plutôt que des octets altérés.

La transformation est l’autre explication courante. Un service qui recompresse des images, réécrit les fins de ligne d’un CSV ou convertit un document produira légitimement une empreinte différente de la source, et ce n’est pas de la corruption. Comparez l’étape qui prétend être la copie fidèle, pas le format de présentation final.

Le retard et la perte relèvent d’une troisième catégorie. Ils peuvent faire expirer un client, le faire réessayer ou abandonner, et rien de tout cela n’implique que des octets acceptés par le serveur aient été modifiés en silence. Regardez le résultat du transfert avant d’attribuer quoi que ce soit au tunnel.

Essayez un second chemin sans tout changer

Si les empreintes diffèrent réellement et qu’aucune conversion n’intervient, répétez le même fichier, client, protocole et destination par un autre chemin pris en charge, comme un réseau local plutôt que le VPN. Changez une variable. Changer le client, le point de terminaison et l’outil en même temps vous donne un résultat que vous ne pouvez pas attribuer.

Gardez la comparaison honnête dans les deux sens. Une empreinte vous dit que deux points sont en désaccord ou en accord sur le contenu ; elle ne vous dit pas quel côté est digne de confiance, alors gardez la valeur attendue et la vérification à l’intérieur du modèle de confiance sur lequel vous vous appuyez réellement.

Terminez par une phrase précise dans le ticket : le transfert s’est arrêté tôt, l’application a transformé l’objet, le stockage l’a modifié, ou les octets concordent et leur lecture est la panne. Chacune de ces possibilités a un propriétaire différent, et aucune n’est le VPN par défaut.