PCAP チェックサム エラーは必ずしも不良パケットであるわけではない: オフロードの証拠を理解する

パケット キャプチャの TCP、UDP、および IP チェックサム エラーがチェックサム オフロードによって発生する理由と、有効な証拠の書き換えを回避する方法

PCAP, チェックサム, Wireshark, ネットワーク診断

パケット キャプチャでは、TCP、UDP、または IP チェックサム エラーが表示されることがよくあります。場合によっては、これらのエラーは実際の破損を意味します。場合によっては、ネットワーク アダプターがチェックサムを入力する前にキャプチャが取得されたことを意味します。エンジニアがすべてのチェックサム警告を不良パケットとして扱うと、間違った問題を追跡したり、有効な証拠を書き換えたりすることができます。

チェックサム オフロードは、誤解を招く PCAP 解釈の最も一般的な原因の 1 つです。

オフロードによって紛らわしいキャプチャが作成される理由

最新のネットワーク アダプターは、ハードウェアでチェックサムを計算できます。オペレーティング システムは、プレースホルダー チェックサム フィールドを含むパケットをアダプターに渡す場合があります。ハードウェアが完了する前にキャプチャが発生した場合、回線上に送信されたパケットが正しい場合でも、PCAP は無効なチェックサムを表示する可能性があります。

これは、ローカルのアウトバウンドキャプチャで特に一般的です。キャプチャ ファイルには、ホストが準備した内容が記録されますが、オフロード後の正確な最終的なワイヤ イメージが必ずしも記録されるわけではありません。

パケットがどこでキャプチャされたかを尋ねる

チェックサムの解釈はキャプチャ位置によって異なります。

  • NIC オフロード前に送信ホスト上でキャプチャされる
  • 送信後にミラーポートまたはタップでキャプチャされる
  • 受信側ホストでキャプチャされる
  • VM またはコンテナの境界内でキャプチャされる
  • 仮想アダプタ上でキャプチャされる

送信側でのアウトバウンド チェックサム警告は、独立したタップで観察されるチェックサム エラーと同じではありません。キャプチャーポイントは証拠の一部です。

チェックサムを早すぎて書き換えないでください

すぐにチェックサムを再計算したくなるかもしれません。これにより、下流のツールの動作が静かになる可能性がありますが、証拠も変わります。編集する前に、キャプチャがどのような質問に答える必要があるかを決定します。

目的がアプリケーション層のデバッグである場合、明確に文書化されていれば、可読性を高めるためにチェックサムを再計算することが許容される可能性があります。目的が配線の破損を証明することである場合、チェックサムを書き換えると、調査中の証拠そのものが消去される可能性があります。

制御されたワークフローは以下を記録します。

  • どのチェックサムフィールドにフラグが立てられたか
  • パケットの方向
  • キャプチャポイント
  • オフロードの可能性が高いかどうか
  • 出力ファイルがチェックサムバイトを書き換えたかどうか
  • どのパケットが変更されたか

編集は自動的に行うのではなく、意図的に行う必要があります。

オフロードと実際の汚職を区別する

チェックサム オフロードが関係している可能性がある兆候:

  • ほとんどの場合、キャプチャ ホスト上の送信パケット
  • 一貫したパターンでフラグが付けられた多くのチェックサム
  • 警告にもかかわらず交通は機能する
  • 独立したキャプチャ ポイントでは同じエラーが表示されない
  • 仮想化環境またはオフロード負荷の高い環境

実際の汚職が関与している可能性がある兆候:

  • 受信側ドロップ
  • 独立したタップにより無効なチェックサムが確認される
  • パケット損失または再送信はチェックサムの失敗と一致します
  • オフロードの説明なしで両方向にエラーが表示される
  • リンク層またはキャプチャ ハードウェアがエラーを報告する

重要なのは、チェックサムの警告を無視しないことです。重要なのは、文脈に沿って解釈することです。

PCAP 手術が適している場所

PCAP Surgery は、証拠に基づくパケット キャプチャ作業用に設計されています。これは、エンジニアがパケットのメタデータを検査し、キャプチャが間違っているように見える理由を理解し、正当な場合にのみ制御された書き換え操作を適用するのに役立ちます。

チェックサムの場合、積の境界が重要です。黙ってキャプチャを「修正」し、何も変わっていないふりをするべきではありません。便利な手術ツールについては次のように説明されています。

  • チェックサム警告ソース
  • コンテキストをオフロードする可能性が高い
  • 影響を受けるパケットセット
  • 書き換えられたときの前後の値
  • 変化が正規化なのか修復なのか

これにより、プロトコル エンジニアは単にファイルを静かに開くだけでなく、防御できるキャプチャが得られます。