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

本記事はNWの午後試験・科目B群の学習を支える技術解説です。演習と解答例は当サイトのオリジナルで、IPAの公式問題・公式採点基準ではありません。製品ごとの設定差や、問題文で仮定した条件を区別して読み進めてください。

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）を提示し合うことで確立されます。

2. 確認応答番号は、連続して受信できた範囲の直後にある「次に期待するバイト番号」。順序どおり届き、欠落がない場合に限りSeq＋Lenとなる。順序逆転や欠落がある間は、後続データを受信しても累積ACKは進まない。

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

以下は送信側・受信側の観測をまとめた学習用トレースである。時刻は同一基準に正規化した概略値で、消失したNo.7は送信側でのみ観測された。No.6の後に最初のAck=1421が受信側から返された行は省略している。

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

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. WANのMTUは1,500バイト。両VPNルータは内側IPv4パケットのDFビットを外側IPv4ヘッダにもコピーし、カプセル化前後とも分割しない設定である。本社VPNルータから送信元DBサーバへのICMP Type 3 Code 4も、FW設定により遮断されていた。

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を超え、分割できず廃棄されたため。」

模範解答

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

解答で確認したい論点

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

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

【設問2】

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

解答への思考プロセス

• 解決策の選定:

本演習のTCP通信では、MSSをトンネルの有効MTUに合わせて調整する方法を解答例とする。PMTUDに必要なICMPの通過許可も検討できるが、IPAの公式採点基準を示すものではない。

• 字数制限への圧縮:

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

模範解答

VPNルータでMSSをトンネルの有効MTUに合わせて調整する。

解答で確認したい論点

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

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

6. まとめと次ステップ

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

観測を誤らないための確認事項

2地点の時計を同期し、キャプチャの取りこぼし、SPANの過負荷、NICオフロードを確認する。NAT前後では5-tupleが変わり、L7プロキシでは別のTCP接続になるため、対応付けの根拠が必要である。表の事象は原因候補であり、未観測だけをもって破棄場所やRST生成機器を断定しない。

TCP ACKは受信TCPスタックによる確認であり、業務処理完了の通知ではない。TLS内のHTTP内容を読めない場合は、アプリログや適切に管理された復号情報を併用する。MSS=1,460はIPv4ヘッダ20バイト・TCP基本ヘッダ20バイトの場合の例である。

PMTUDでは必要なIPv4 ICMP Type 3 Code 4とIPv6 Packet Too Bigの到達性を確認する。MSSクランプはTCP向けの緩和策であり、UDPを含むすべての通信のMTU問題を解決する機能ではない。

参考資料・関連する学習記事

RFC 9293

RFC 1191

RFC 8201

次に読む：TCP通信制御のメカニズムと輻輳・パケットロス解析