「つながらない!」の原因究明
プロキシファイアウォール接続のトラブルシューティング
ファイアウォールの設置で複雑になった接続問題。TCPのハンドシェイクプロセスの知識がヒントになる。
クライアントとサーバの間に置かれるプロキシファイアウォールの利用拡大とともに、接続問題のトラブルシューティングは以前より複雑になっている。しかし、TCP(Transmission Control Protocol)の「ハンドシェイク」プロセスの知識が多少あれば、プロキシファイアウォールに関連する接続問題の診断に役立つ。
ネットワーキングの入門講義を受けてからかなり年数がたっている人のために、まずTCPハンドシェイクの仕組みを復習しておこう。TCPはコネクション指向のプロトコルであり、2つのシステムがTCP通信を行うには、まず双方向の通信路が開設されなければならない。これは、フラグを含む特殊なパケットを使って行われる。そうしたフラグの1つであるSYNフラグが接続要求を伝えるために使われ、ACKフラグが接続が開いていることを知らせる。
この3ウェイハンドシェイクのパケットのやりとりは、次のようになる。
まず、クライアントがSYNパケットをサーバに送信する。これを受信したサーバは、応答パケットを作成する。その際、クライアントの接続要求を受け取ったことをクライアントに伝えるために、ACKフラグをオンにする。さらに、サーバからクライアントへという逆方向の通信路の開設を要求するために、SYNフラグをオンにする。サーバはこのSYN/ACKパケットをクライアントに送信する。これを受信したクライアントは、ACKパケットを返信することで、サーバからクライアントへの接続要求を受け取ったことをサーバに伝えなければならない。このACKパケットをサーバが受信した時点で、クライアントとサーバ間の双方向通信が可能になる。
しかし、プロキシファイアウォールは以下の図のように、クライアントとサーバの間に入り、通常のTCPハンドシェイクのパケットのやりとりを仲介する。
クライアントはプロキシファイアウォールに接続し、サーバとの接続を確立したと考える。続いてプロキシファイウォールがクライアントに代わって、サーバとの接続を開く。このユニークなアプローチにより、クライアントとサーバを分離するレイヤが追加され、ファイアウォールが両者のやりとりを中継し、アプリケーションレイヤでトラフィックを調べ、有害な恐れがあるコンテンツをチェックするといったことが可能になる。
だが、ファイアウォールを使うと、クライアント/サーバの接続問題のトラブルシューティングが少し面倒になる。問題を診断するには、ファイアウォールの両側でトラフィックを監視しなければならない。ファイアウォールの外側のトラフィックを監視する外部監視装置と、ファイアウォールの各内部インタフェースに接続された内部監視装置が必要になる。以下では、幾つかの一般的な接続問題に目を向け、それらがtcpdumpの出力にどのように現れるかを見ていこう。以下の例では、いずれも前述した接続シナリオを使用する。Webサーバは、2つのIPアドレスを持つものとする。ファイアウォールで保護されたLAN上でのプライベートアドレスである192.168.3.150と、外部に公開されているパブリックアドレスである10.0.0.120だ。
ケース1:サーバの問題
サーバは、DoS(サービス妨害)、設定ミス、ハッキングなどの原因から、接続に問題が生じることがある。こうした場合、ファイアウォールは正常に動作しているため、ファイアウォールの外側では、3ウェイハンドシェイクが完了しているはずだ。出力は次のようなものになる。
19:24:36.959777 IP 10.1.1.16.1450 > 10.0.0.120:80: S 735906036:735906036(0) win 16384
19:24:36.987938 IP 10.0.0.120:80 > 10.1.1.16.1450: S 3607622985:3607622985(0) ack 735906037 win 8190
19:24:36.987961 IP 10.1.1.16.1450 > 10.0.0.120:80: . ack 1 win 17640
SYNフラグとACKフラグは、目立つように太字にしてある。これは正常な3ウェイハンドシェイクだ。問題は、ファイアウォールとWebサーバの間に現れる。サーバがダウンしていたり、あるいは応答していない場合、以下のような、ファイアウォールからサーバへの一連のSYNパケットでそれが確認できる。
19:22:40.214672 IP 192.168.3.124.1439 > 10.0.0.120.80: S 4182454:4182454(0) win 16384
19:22:43.154580 IP 192.168.3.124.1439 > 10.0.0.120.80: S 4182454:4182454(0) win 16384
19:22:43.154580 IP 192.168.3.124.1439 > 10.0.0.120.80: S 4182454:4182454(0) win 16384
19:22:43.154580 IP 192.168.3.124.1439 > 10.0.0.120.80: S 4182454:4182454(0) win 16384
19:22:43.154580 IP 192.168.3.124.1439 > 10.0.0.120.80: S 4182454:4182454(0) win 16384
ケース2:ファイアウォールの問題
ファイアウォールの問題は、内容に応じてさまざまな形で現れる。ファイアウォールが完全にダウンしている場合には、ファイアウォールのパブリックIPアドレスに送信されても応答が返っていない、一連のSYNパケットが存在する。これは外部監視装置の出力に表示され、内部監視装置の出力には関連するトラフィックは何も表示されない。
一方、ファイアウォールのルールが誤って設定されている場合は、外部監視装置の出力には、正常な3ウェイハンドシェイクが行われたことが示されるかもしれないが、内部監視装置の出力には、トラフィックが何も表示されないかもしれない。
ケース3:アプリケーションの問題
内部監視装置と外部監視装置の両方の出力に正常な3ウェイハンドシェイクが行われたことが示されている場合、一般にファイアウォールに問題がある可能性は除外できる。この場合、アプリケーション自体に問題が生じている疑いが濃厚だ。例えば、攻撃者がアプリケーションを乗っ取って動作を改変している、サービスが誤って設定されている、クライアントが不正な要求を行っている、といった恐れがある。
これらのケースは網羅的なものではない。あり得るトラブルシューティングシナリオをすべてカバーするのは、絶対不可能だ。とはいえ、これらの例はプロキシファイアウォールに関連する接続問題を診断するための良い出発点になる。
本稿筆者のマイク・チャップル氏は、ノートルダム大学のITセキュリティプロフェッショナル職を務めており、CISA(公認情報システム監査人)、CISSP(公認情報システムセキュリティプロフェッショナル)の資格を持つ。米国国家安全保障局と米国空軍に情報セキュリティ研究員として勤務した経験がある。「Information Security」誌のテクニカルエディターを務めるほか、「CISSP: Cissp Certified Information Systems Security Professional」や「Information Security Illuminated」(いずれも共著)など、情報セキュリティに関する数冊の著書がある。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[o9ソリューションズ・ジャパン株式会社] 「改正物流効率化法対策」徹底解説 総物流費を抑制するサプライチェーン戦略 -
製品資料
[o9ソリューションズ・ジャパン株式会社] 「サプライチェーン最適化」実践ガイド:効果的な意思決定を実現する秘訣とは? -
製品資料
[株式会社リンプレス] 非デジタル/IT人材を「自走するDX推進者」に変えるための育成ロードマップ -
市場調査・トレンド
[ワンアイルコンサルティング株式会社] AI時代の組織設計:「判断と責任」を人に残すための2つの原則とは? -
技術文書・技術解説
[ワンアイルコンサルティング株式会社] システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
1200万円のSaaS導入を回避 スギ薬局「運用費10万円」のAIエージェント構築術
-
2
ソフトウェア開発生産性向上に取り組む企業は4割 調査で学ぶ「停滞」の正体
-
3
「完璧な設計」なのに3000万円溶けた AWSの失敗事例から学ぶ3つの教訓
-
4
クラウド資格コレクターは評価されない? 年収1000万を分ける“OSの理解度”
-
5
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
-
6
Microsoft製品でここまで自動化できる 情シスがやめられる手作業10選
-
7
1200万円のSaaS導入を回避 スギ薬局「運用費10万円」のAIエージェント構築術
-
8
「配信に1カ月」の代償 カルビーがLINE運用で外部依存を断ち切った理由
-
9
なぜクラウド全盛の今「メインフレーム」が再び脚光を浴びるのか
-
10
フィッシング詐欺の説明として最も正しい記述は?
ホワイトペーパーランキング PR
-
1
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
2
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは?
-
3
Windows PCとMacの選択制で生産性向上 LINEヤフーが実践する運用管理方法とは
-
4
DX/AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
5
「Google Workspace」活用事例34選、先進の生成AIによる組織変革の全貌
-
6
生成AIで文書活用を進めるには? 効率化と安全性をどう両立する
-
7
「人員を増やす」という選択肢はない 情シスが負の連鎖から抜け出すには?
-
8
「問題が深刻化しやすいプロジェクト管理」から脱却する方法とは?
-
9
Linuxのスキルを証明する“激推し”の認定資格はこれだ
-
10
NTTドコモが実践したクラウド統合監視 業務量2倍でも残業削減を実現できた理由
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー