アップロードが壊れて見える：両端でハッシュを比べる

アップロードしたファイルを開けない受け取り手は、VPN が壊したとよく耳にする。それは観測ではなく仮説であり、検証できる。トンネルに触れる前に、宛先に今保存されているオブジェクトが、送るはずだったオブジェクトと異なるかを確かめる。ほかのすべてはその答えから導かれる。

苦情ではなく、送るはずだったバイトから始める

問題を再現する無害なファイルを選ぶか、ポリシーが許すなら元の環境から出してよい実ファイルを選ぶ。転送の前に、バイト単位の正確なサイズと現代的な内容ハッシュという二つを記録する。ファイル名、時刻、プレビューはメタデータであり、どれも内容を特定しない。

両端で実行できるアルゴリズムでハッシュを計算し、どれを使ったかを書き留める。SHA-256 と MD5 の比較は比較ではないし、たまたま同じ名前を持つ二つの別ファイルの比較も比較ではない。

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

Microsoft の Get-FileHash リファレンス コマンドとそのアルゴリズム引数を説明しており、比較が無意味な不一致を生むときに人が飛ばしてしまうのはまさにその部分だ。

段階ごとに一つのハッシュ、同じアルゴリズム

次に、保存されたオブジェクトが最終的に置かれている場所で、別のツールを通ったコピーではなく許可された方法を使って、同じアルゴリズムを計算する。受け取ったファイルを手元に保存してそのコピーをハッシュすると、試していない手順が一つ増える。

サービスが独自の整合性の値を公開しているなら、それは別の観測として扱う。提供元が報告するチェックサムは、提供元が何を保存したと考えているかを教えてくれるが、あなたのクライアントが送ったものと同じ主張ではない。

結果は三通りあり、それぞれ違う方向を指す。ハッシュが等しければ、バイトは変わらずに届いた。既知の変換を伴う不一致なら、サービスが意図的に新しいオブジェクトを作った。変換のない不一致なら、二点の間の何かが内容を変えたのであり、次の手順はそれが起きた最も早い境界を見つけることだ。

転送の失敗と変換を切り分ける

部分的なアップロードと壊れたアップロードはファイルブラウザでは同じに見えるが、別の障害だ。転送が完了したかは、中断された要求を示すアプリケーションログ、サイズが元ファイルの先頭部分になっている保存ファイル、想定された拡張子で保存された実体がエラーページのオブジェクトのいずれかで確かめられ、どれもバイトの変化ではなく転送の未完了を示す。

変換もよくある説明だ。画像を再圧縮し、CSV の行末を書き換え、文書を変換するサービスは、元とは異なるハッシュを正当に生むが、それは破損ではない。忠実なコピーだと称する段階を比べるのであって、最終的な表示形式を比べるのではない。

遅延と損失は第三の分類に入る。これらはクライアントをタイムアウトさせ、再試行させ、諦めさせるが、どれもサーバーが受け取ったバイトが黙って変えられたことを意味しない。何かをトンネルのせいにする前に、転送の結果を見る。

すべてを変えずに別の経路を試す

ハッシュが本当に違い、変換もないなら、同じファイル、クライアント、プロトコル、宛先を、VPN ではなくローカルネットワークなど別の対応経路で繰り返す。変えるのは一つの変数だけだ。クライアントと端点とツールを同時に変えると、原因を特定できない結果になる。

比較は両方向に誠実に保つ。ハッシュは二点が内容について一致するか食い違うかを教えるがどちら側が信頼できるかは教えないので、期待値と検証は実際に依存している信頼モデルの内側に置く。

チケットには、転送が途中で止まった、アプリケーションがオブジェクトを変換した、保存側が変えた、あるいはバイトは一致していて読み取りが失敗だ、という具体的な一文で締める。どれも担当が異なり、どれも既定で VPN のせいではない。