ICTSC2025 二次予選 問題解説: All I Want for Christmas are …
概要
あなたはインフラ基盤を管理するインフラエンジニアです。社内から https://server.example.local に対し「なんか上手く行かない」
という問い合わせが来ています。担当者が早めのクリスマス休暇に入っており連絡が付かないという状況ですが、当事者意識が高すぎるあなたなので、問題を分析し、解決に導くことでしょう。
構成情報
- FW上ではSquidが動いており、許可する宛先を限定しています。
- サーバ上では接続先のWebサーバとしてApacheが動いています。
- クライアントには、明示型プロキシが指定されており、必ずFWを経由して通信を行う必要があります。
- クライアントは、2種類あります。
- 1台は問い合わせしてきた担当者の管理下にあるため、ログインができません。しかし、そのクライアントから、3~4秒おきにサーバにアクセスが行われているそうです。
- もう1台は、インフラチームの管理下にあるので、ログイン可能です。名前解決、プロキシ、証明書に関する設定について、問い合わせが来ているサーバの設定と比べても、トラブルに関連する差はないことは分かっているので、問題の切り分けに使うことが出来ます。
回答内容と達成すべき状態について
-
回答内容には以下の情報を含めてください
- 何が問題だったか
- どのような方法で問題に気が付いたか
- 問題を解消するためにどのような設定変更を行ったか
- 問い合わせ先のクライアントからの3～4秒おきの通信が、30回以上連続で200番で成功していることが、Apacheのログに記録されている様子
- ※ログイン可能なインフラチームのクライアントから手動実行して同様のログを出力させることも可能ですが、下記「達成すべき状態」を満たせていない場合は、不正な回答とさせていただきます
-
達成すべき状態は以下の通りです
- 休暇から戻った担当者がクライアントにログインし、Webサーバへの通信が問題なく通信出来ることを確認できる状態
注意・制約事項
- HTTPSでの通信を成功させること。
- Squidを介さない、もしくは、宛先を全て許可する設定は禁止。
- いずれのVMにおいても、IPアドレスやルーティングに関する設定の変更は禁止。
- ログインユーザの権限に関する設定変更は禁止。
接続情報
| ホスト名 | IPアドレス | ユーザ | パスワード |
|---|---|---|---|
| client-vm | 192.168.255.32 | user | ictsc2025 |
| firewall-vm | 192.168.255.33 | user | ictsc2025 |
| server-vm | 192.168.255.34 | user | ictsc2025 |
解説
今回の問題は、以下の2つの事象によって構成されていました。
- ① FW === サーバ間が2本のリンクで接続されており、ECMPでルーティング経路が設定されているが、片方のリンクは tc コマンドによって 100% トラフィックが破棄されているため、通信が通ったり通らなかったりする状態になっている。
- ② 問い合わせ元のクライアントが 誤った SNI（.wrong） を埋め込んで通信しており、その結果、FW のポリシーにマッチせず通信が遮断されている。
①は、物理ネットワークが半死状態で、リンクアップしているように見えるが実際には通信できない、といった事象をイメージしています。
②は、大規模なインフラ環境において、「どんなクライアントが、どんな通信を投げてくるか分からない」という状況下でのトラブルシューティングを想定しています。実例としては、SNIを出せないほど古いクライアントなどの存在がありました。
この事象に気付くためには、さまざまなアプローチが考えられますが、タイトルの通り(?)「All I Want for Christmas are "Packets"」ということで、FW 上でパケットキャプチャを行うことで、
- 不自然な SNI（.wrong）を含む通信が来ていること
- 特定のインタフェース経由の通信が一切返ってこないこと
を確認できるようになっていました。
また、FW のログを追ったり、tcコマンドの実行履歴やipコマンドの結果からnetemの存在に気付くなど、必ずしもパケットキャプチャに限定されない方法でも原因にたどり着いたチームも多く見受けられました。
本問における 正しい解決状態は、「通信が成功すること」ではなく、通信結果が常に安定し、再現性のある状態になることを指しています。
そのため、問題の解決方法は以下の2点です。
- ①パケットが破棄されているリンクをダウンさせ、ECMPによる不安定な経路選択を解消する
- ②FWに .wrong 宛先の通信を許可するポリシーを追加する
多くのチームでは②のみを解消し、FWのログ上で問い合わせ元クライアントからの通信がおおよそ50%程度の確率で成功している状態を確認したうえで、そのログを30行抜粋し「終了状態を満たしている」と回答していました。
しかし実際のタイムスタンプを見ると、通信間隔が3〜4秒ではなく、20秒近く空いている箇所が存在するなど、
通信が安定していない状態であることが確認できました。
インフラチーム側のクライアントから curl を複数回実行すると、①の事象が残っていることに気付けるため、「成功しているか」だけでなく「常に同じ結果になるか」を意識して状態を確認してもらえるとより良かったと考えています。
本問を通じて、パケットキャプチャがより身近な存在となり、トラブルシューティングの強力な武器として活用してもらえるきっかけになれば幸いです！