ネットワーク障害調査とパケットキャプチャ解析の実務手順

1. 概要と本質：なぜパケットキャプチャが最強の切り分け手段なのか

ネットワークで「通信が遅い」「時々切断される」「特定のWebページだけ開かない」といった障害が発生した際、機器の死活監視（Ping）やリンクランプの確認だけでは根本原因にたどり着けないケースが多々あります。 特に、パケットフィルタリング（ファイアウォール）、アドレス変換（NAT/NAPT）、暗号化トンネル（IPsec/TLS）、経路制御（OSPF/BGP）が複雑に組み合わさったエンタープライズネットワークでは、「通信の当事者（クライアント・サーバ）および中継機器が実際に送受信した生データ（パケット）」を直接観測することが、最短かつ唯一の客観的解決ルートとなります。

本稿では、ネットワークスペシャリスト（NW）午後・科目B試験で頻出するパケットトレース問題に対応できるよう、Wiresharkを用いたキャプチャ採取ポイントの選定、TCPフラグの遷移、シーケンス番号と確認応答番号の進み、パケットロス・遅延の判定基準、そして午後記述試験特有の設問に対する合格答案作成プロトコルを網羅的に解説します。

2. キャプチャ採取アーキテクチャと採取ポイントの選定

パケットキャプチャを行う際、最も重要なのは「どこでパケットを採取するか」です。採取場所を誤ると、「サーバは応答を返しているのにクライアントに届いていない」のか、「サーバ自体が応答を返していない」のかの切り分けができません。

図のデータを表示できません。

2.1 2地点同時キャプチャの鉄則

ネットワーク遅延やパケット消失を特定する唯一確実な手法は、「送信元に近い地点（クライアント側）」と「宛先に近い地点（サーバ側）」の2箇所で同時にパケットを採取し、同一セッションのパケットを突き合わせることです。

3. TCPヘッダフラグとパケットシーケンスの厳密な読み解き方

午後試験では、パケットキャプチャの抜粋表が提示され、各行のシーケンス番号（Seq）や確認応答番号（Ack）、TCPフラグの値を計算・特定させる設問が反復して出題されます。

3.1 3ウェイハンドシェイクと初期シーケンス番号（ISN）

TCP接続は、クライアントとサーバが互いに異なる初期シーケンス番号（Initial Sequence Number: ISN）を提示し合うことで確立されます。

図のデータを表示できません。

[!IMPORTANT] シーケンス番号・確認応答番号の計算規則（試験頻出） 1. SYNフラグおよびFINフラグは、ペイロード長が0であっても仮想的に1バイトを消費する。 - したがって、SYNに対するACKの確認応答番号は ISN + 1 となる。 2. 通常のデータパケット（ACK, PSH）では、確認応答番号（Ack）は「受信したSeq番号 ＋ ペイロード長（Len）」となる。 3. 純粋なACKパケット（Len = 0）は、シーケンス番号を進めない。

3.2 パケットキャプチャログの読み解き実戦例

以下は、あるWebアクセスにおいてパケットロスと再送が発生した際のWireshark抜粋ログです。

このログから読み取るべき重要ポイント

1. パケット消失の特定（No.7とNo.8の間）:

- クライアントはSeq=1〜1420を受領した後、次に届いたパケットがSeq=2841であったため、「Seq=1421〜2840のパケットが途中で抜けた」と検知しています。

1. 重複ACK（Duplicate ACK）のメカニズム:

- 受信側は、期待する次のバイト番号である Ack=1421 を固定したまま、後続パケット（No.8, No.10, No.12）が届くたびに同一のACKを返送します。

1. 高速再送（Fast Retransmit）の発動条件:

- 同一の重複ACKを3回受信（計4回の同一Ack）した瞬間、送信側は再送タイムアウト（RTO）を待たずに即座に欠落パケット（Seq=1421）を再送します。

1. 累積確認応答（Cumulative ACK）の効果:

- 欠落していたSeq=1421を受信した瞬間、クライアントは既に受領済みのSeq=5681+1420=7100までの全データをまとめて確認したことになるため、Ack=7101（No.15）を1発で返送します。

4. ネットワーク障害の典型パターンとパケットによる切り分け

午後試験で問われる障害シナリオは、パケットの特徴によって明確に分類できます。

4.1 パターンA：Path MTU Discovery（PMTUD）ブラックホール障害

• 現象: 小さなWebページ（テキスト等）は開くが、画像や大きなファイルダウンロードを始めた瞬間にブラウザの読み込みが停止し、最終的にタイムアウトする。

• 原因メカニズム:

1. クライアントとサーバのLAN内MTUは通常 1,500バイト（MSS = 1,460バイト）。 2. 経路上にVPNトンネル（IPsecやPPPoE）が存在し、カプセル化ヘッダの付加によって中継ルータのMTUが 1,454バイト や 1,400バイト に縮小している。 3. 送信側はDFビット（Don't Fragment = 分割禁止）を「1」にセットして1,500バイトのパケットを送信。 4. 中継ルータはパケットを通過させられず破棄し、送信元へ ICMP Type 3 Code 4（Fragmentation Needed and DF set） を返送しようとする。 5. 途中のファイアウォールが「セキュリティ対策」としてICMPを全遮断している場合、送信元ルータにこの通知が届かず、パケットがブラックホールのように闇に消え続ける。

• Wiresharkでの特徴:

- ハンドシェイクやHTTP GET要求は通るが、サーバからの最初の大きなデータパケット（1,460バイト等）が連続して再送タイムアウトし、クライアントには届かない。

• 恒久対策:

- ルータで TCP MSSクランプ（MSS調整機能） を設定し、SYNパケット内のMSSオプションを強制的にカプセル化後の許容値（例: 1,360バイト等）に書き換える。またはICMP Type 3 Code 4を通過許可する。

4.2 パターンB：ファイアウォール・ロードバランサによる無通信セッション切断

• 現象: 長時間放置した端末で「送信」ボタンを押すと、エラーまたは再ログイン画面になる。

• 原因メカニズム:

- ステートフルインスペクションFWやロードバランサ（LB）は、メモリ節約のため「一定時間無通信（例: 300秒）が続いたTCPセッション」をセッションテーブルから自動破棄する。 - 端末側OSはセッションが維持されていると認識しているためパケットを送信するが、FWは「セッションテーブルに存在しない不正パケット」とみなして破棄するか、RSTフラグを返送して強制切断する。

• 対策:

- アプリケーション層で定期的なKeep-Alive通信を送信する、またはTCPのKeep-Alive間隔をFWのタイムアウト時間より短く設定する。

5. 科目B形式 実戦演習問題

ネットワークスペシャリスト午後・科目Bの出題傾向に完全に準拠したオリジナル演習問題です。

【設問シナリオ】

中堅食品メーカーのT社では、本社と工場拠点をIPsec-VPNで接続している。 今般、工場のPCから本社の新基幹データベース（ポート8080/TCP）へアクセスしたところ、「一覧検索は高速に表示されるが、5MBを超える帳票PDFのダウンロードを実行した瞬間に画面がフリーズし、約1分後にエラーとなって失敗する」という障害が多発した。

ネットワーク担当のY君は、工場PC（10.20.1.100）と本社DBサーバ（192.168.10.50）の間でパケットキャプチャを実施した。 調査の結果、以下の事実が判明した。

1. 工場PCと本社DBサーバのネットワークアダプタのMTUは、ともに1,500バイトに設定されている。

2. 本社と工場の拠点間ルータはIPsecトンネル（ESPトンネルモード、AES-256、SHA-256）で暗号化を行っている。

3. IPsec暗号化後のパケットサイズが、WAN回線のMTU（1,500バイト）を超過しないよう、ルータには暗号化後のフラグメンテーション機能が備わっているが、工場側ルータのファイアウォール設定で「ICMP通信は外部からの攻撃防止のため送受信ともに全破棄（Deny）」と設定されていた。

4. 本社DBサーバは、OSのPath MTU Discovery機能に従い、送信するすべてのTCPパケットにDF（Don't Fragment）ビットを「1」に設定して送信していた。

【設問1】

帳票PDFのダウンロード時に通信がフリーズした原因について、パケットのサイズ、ルータの動作、およびパケットの廃棄理由に着目し、35字以内で述べよ。

解答への思考プロセス

• 事実関係の整理:

- 本社DBサーバは大きなPDFデータを送信するため、MSS=1,460バイト（IPヘッダ20B + TCPヘッダ20B + データ1,460B = 計1,500バイト）のフルサイズパケットを生成する。 - パケットにはDFビットが「1」（分割禁止）でセットされている。 - 本社側VPNルータがこれをIPsecカプセル化（ESPヘッダ、暗号化IV、パディング、ESPトレイラ、外部IPヘッダ等で約50〜70バイト増加）すると、パケット長は1,560バイト前後となり、WAN回線のMTU 1,500バイトを超過する。 - ルータはDF=1のためフラグメントできず、パケットをドロップし、送信元（DBサーバ）へ「ICMP Type 3 Code 4」を返送しようとする。 - しかし、ファイアウォールでICMPが遮断されているため、DBサーバに届かない。

• 設問要求への正対:

- 「パケットのサイズ」「ルータの動作」「廃棄理由」を含めて35字以内。 - 「DF設定パケットがVPN付加でMTUを超え、分割できず廃棄されたため。」（35字）

模範解答

DF設定パケットがVPN付加でMTUを超え、分割できず破棄されたため。（35字）

減点・失点分析

• ×「通信容量が大きすぎてルータの処理能力を超えたため。」（1点もつかない。抽象的すぎる）

• △「MTUを超過したパケットが分割されなかったから。」（なぜ分割されなかったのか「DFビット」の観点が抜けており部分点どまり）

【設問2】

T社のネットワーク構成において、各端末やDBサーバのMTU設定を個別に変更することなく、本障害をネットワーク側で根本的に解決するための設定変更策を、対象機器と設定内容を明確にして35字以内で述べよ。

解答への思考プロセス

• 解決策の選定:

- 端末やサーバのMTUを1台ずつ変更して回るのは運用上不可能。 - ネットワーク機器側で解決する王道手段は2つ： 1. 拠点間VPNルータで TCP MSSクランプ（MSS書き換え） を有効にし、3ウェイハンドシェイク時のSYNパケットに含まれるMSSオプション値を、IPsecオーバヘッドを引いた安全な値（例: 1,400バイト以下）に強制書き換えする。 2. ルータのFWで ICMP Type 3 Code 4（Fragmentation Needed）の通過を許可 する。 - IPA試験で最も確実かつ汎用的な模範解答は「VPNルータでTCPのMSS値を小さく調整（クランプ）する」こと。

• 字数制限への圧縮:

- 「対象機器」＝VPNルータ - 「設定内容」＝TCPのMSS値をIPsecのヘッダ分小さく調整する - 「VPNルータでTCPのMSS値をIPsecヘッダを考慮した値に調整する。」（35字）

模範解答

VPNルータでTCPのMSS値をIPsecの暗号化分小さく調整する。（33字） （別解：VPNルータでICMPの宛先到達不能通知の通過を許可する。（28字））

減点・失点分析

• ×「ルータを買い換えて回線帯域を増強する。」（帯域の問題ではないため0点）

• △「ルータでMTUを大きくする。」（WAN回線のMTUは通信キャリアの仕様であり勝手に大きくできない）

6. まとめと次ステップ

パケットキャプチャ解析は、ネットワークスペシャリスト試験のあらゆる分野（DNS、Web、ルーティング、セキュリティ）を貫く最強の共通基盤技術です。 次稿 NWP-02（TCP通信制御のメカニズムと輻輳・パケットロス解析） では、スライディングウィンドウの動的変化、スロースタートアルゴリズム、およびBDP（帯域遅延積）の計算問題を集中的に攻略します。