この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第40回です。
第4章では、仮想ネットワーク、ルーティング、セキュリティ、 NAT、ロードバランサー、VPN、専用線、複数クラウド、DNSまで、 クラウドネットワークを設計するための基本を学んできました。 今回は、それらを使って実際の通信障害を切り分けます。
NETWORK ADVANCED｜CHAPTER 4 CLOUD NETWORK
クラウドネットワーク障害の切り分け｜ルート・セキュリティ・DNS・VPNを順番に確認
クラウド上で「サーバーへ接続できない」という障害が発生したとき、 原因は仮想マシンだけとは限りません。 DNS、ルートテーブル、セキュリティ制御、NAT、ロードバランサー、 VPN、専用線、OS、アプリケーションなど、 複数の要素を通信経路に沿って確認する必要があります。 この記事では、勘ではなく根拠を使って原因候補を絞り込む方法を解説します。
オンプレミスでは、ルーターやスイッチへログインして インターフェースやルーティングテーブルを確認することが多くあります。
一方、クラウドでは物理ネットワークを直接確認できないため、 「送信元から宛先まで、どの論理コンポーネントを通るのか」 を整理し、設定・ログ・メトリクス・診断機能から確認することが重要です。
この記事を読み終えるとできること
- クラウド障害で最初に整理すべき情報を説明できる
- DNS・経路・セキュリティを順番に切り分けられる
- NATやロードバランサーを含む通信経路を確認できる
- VPN・専用線を含むハイブリッド通信を切り分けられる
- ログやフローログを使って仮説を検証できる
- 調査結果を顧客や上司へ根拠付きで報告できる
クラウドネットワーク障害の切り分けとは
クラウドネットワーク障害の切り分けとは、 送信元から宛先までの通信経路を分解し、 各地点の設定と観測結果を確認して、 通信を止めている場所を段階的に絞り込むことです。
障害対応で重要なのは、 最初から「ファイアウォールが原因だろう」 「クラウド側がおかしいだろう」と決めつけないことです。
たとえば、利用者から次の連絡があったとします。
「クラウド上の業務システムへ接続できません。」
この一文だけでは調査できません。 最低でも、次の情報へ分解する必要があります。
- 誰が接続できないのか
- どこから接続しているのか
- どの宛先へ接続しているのか
- どのプロトコル・ポートを使用しているのか
- いつから発生したのか
- 全員なのか一部利用者だけなのか
- 常時発生するのか断続的なのか
- 直前に設定変更やリリースがなかったか
障害切り分けの最初の仕事は「原因を探すこと」ではなく、 「正常な通信が本来どのように流れるかを定義すること」です。
これは、 ネットワーク要件定義 と同じ考え方です。 曖昧な「つながらない」を、そのまま扱うのではなく、 調査できる具体的な条件へ変換します。
まず通信経路を1枚にする
クラウド障害では、管理画面を片っ端から開くより先に、 対象通信の経路を整理します。
例として、社内PCからVPN経由でクラウド上のWebシステムへ HTTPS接続する構成を考えます。
社内からクラウド上のWebシステムへ接続する例
実際の調査では、往路だけでなく戻り通信の経路も確認します。
ここで「通信できない」ときの原因候補を考えると、 すでに複数あります。
名前解決
DNSが誤ったIPアドレスを返している、 または名前解決そのものが失敗している可能性があります。
経路
ルートテーブルに宛先への経路がない、 または意図しない次ホップへ送られている可能性があります。
通信制御
セキュリティルールやファイアウォールで TCP/443が許可されていない可能性があります。
VPN・専用線
トンネル、BGP、経路広報などに問題がある可能性があります。
ロードバランサー
リスナーは正常でも、 バックエンドが異常判定されている可能性があります。
サーバー・アプリ
OSファイアウォール、待ち受けポート、 アプリケーション停止などの可能性があります。
最初に確認する5つの情報
本格的な調査を始める前に、 次の5項目を明確にします。
1．送信元
「社内から接続できない」ではなく、 可能な限り送信元を特定します。
- 送信元IPアドレス
- 送信元サブネット
- 拠点名
- VPN利用の有無
- 踏み台サーバー経由か
2．宛先
- FQDN
- 名前解決後のIPアドレス
- ロードバランサーなのかVMなのか
- Private IPなのかPublic IPなのか
3．プロトコルとポート
「pingが失敗する」だけでは、 Web通信が利用できないことを証明できません。
実際に利用する通信がHTTPSなら、 TCP/443で確認する必要があります。
# Windows
Test-NetConnection app.example.internal -Port 443
# Linux
curl -v https://app.example.internal/
ICMPを許可していない環境では、 pingに応答しなくてもTCP/443は正常に通信できる場合があります。 業務通信と同じ条件で確認することが重要です。
4．症状
| 症状 | 考えやすい原因 | 確認の方向性 |
|---|---|---|
| 名前解決できない | DNS | DNSサーバー、ゾーン、レコード、転送設定 |
| Timeout | 経路・FW・NAT・障害 | ルート、通信制御、戻り経路、ログ |
| Connection refused | サーバー側 | 待ち受けポート、サービス状態 |
| HTTP 5xx | LB・アプリケーション | バックエンド状態、アプリログ |
| 一部ユーザーだけ失敗 | 送信元条件・DNS・経路差 | 正常端末との差分比較 |
5．発生時刻
発生時刻はログとの突合に必要です。 また、障害発生直前に変更がなかったか確認します。
- ルートテーブル変更
- セキュリティルール変更
- DNSレコード変更
- VPN設定変更
- ロードバランサー設定変更
- サーバー再起動
- アプリケーションリリース
クラウドネットワーク障害の基本切り分けフロー
基本的には、次の順序で確認すると整理しやすくなります。
- 障害範囲を確認する 1台だけなのか、同一サブネット全体なのか、 複数拠点なのかを確認します。
- 名前解決を確認する FQDNが正しいIPアドレスへ解決されるかを確認します。
- 送信元と宛先の状態を確認する 仮想マシンやロードバランサーが稼働しているか確認します。
- ルーティングを確認する 宛先への経路だけでなく、戻り通信の経路も確認します。
- セキュリティ制御を確認する 送信元、宛先、プロトコル、ポートの条件が許可されているか確認します。
- NAT・ゲートウェイを確認する インターネット向け通信ならNATやインターネット接続部分を確認します。
- LB・VPN・専用線など中継サービスを確認する 対象通信が通過するクラウドサービスの状態と設定を確認します。
- OS・アプリケーションを確認する ネットワークが正常でもサービスが待ち受けていなければ接続できません。
- ログとメトリクスで仮説を検証する パケットがどこまで到達しているか、拒否されていないかを確認します。
「設定を見る → 怪しそうなら変更する」ではなく、 「仮説を立てる → 証拠を確認する → 原因候補を減らす」 の順番で進めます。
1．DNSを確認する
FQDNを使って接続している場合、 最初に名前解決結果を確認します。
# Windows
nslookup app.example.internal
# Linux
dig app.example.internal
確認するポイント
- 期待するIPアドレスが返っているか
- Public IPとPrivate IPを取り違えていないか
- 利用者が正しいDNSサーバーを参照しているか
- オンプレミスとクラウド間のDNS転送が正常か
- レコード変更後のキャッシュが残っていないか
名前解決と通信を分けて考える
DNS障害なのかネットワーク障害なのかを確認するため、 名前解決したIPアドレスへ直接接続できるか比較する方法があります。
FQDNでは失敗するがIPアドレスでは通信できる のであれば、DNS側の調査を優先できます。
クラウドDNSについては、 第39回「クラウドDNSの設計」 で詳しく解説しています。
2．ルーティングを確認する
DNSが正常でも、送信元から宛先までの経路がなければ通信できません。
クラウドでは、サブネットや仮想ネットワークに関連付けられた ルートテーブルを確認します。
確認する4つのポイント
宛先プレフィックス
宛先ネットワークに一致するルートが存在するか確認します。
次ホップ
VPN、NAT、インターネットゲートウェイなど、 意図した次ホップになっているか確認します。
より具体的な経路
より長いプレフィックスのルートによって、 想定外の経路が選ばれていないか確認します。
戻り経路
宛先から送信元へ戻るルートも存在するか確認します。
往路だけ確認して終わらないことが重要です。
行きのパケットがサーバーへ到達していても、 戻り通信が別経路へ流れたり、 送信元ネットワークへのルートがなかったりすると通信は成立しません。
クラウドのルート設計については、 第33回「ルートテーブルとセキュリティ制御」 も確認してください。
3．セキュリティ制御を確認する
経路が正しくても、 セキュリティルールで通信が拒否されれば接続できません。
確認するときは、 「HTTPSを許可している」という見方ではなく、 次の4要素に分解します。
通信許可ルールを4要素に分ける
よくある設定ミス
- 送信元CIDRが古い
- TCP/443ではなく別ポートを許可している
- 受信方向だけ確認し送信方向を見落としている
- 複数段のファイアウォールの一部だけ確認している
- サブネット側のフィルタリングを見落としている
- OSファイアウォールを見落としている
「許可ルールがあるか」だけでなく、 実際の通信がそのルールへ一致するか を確認します。
4．NAT・インターネット接続を確認する
Private Subnet上のサーバーからインターネットへ接続する場合、 NATを経由する構成がよく使われます。
Private Subnetからインターネットへ接続する例
NAT障害で確認する項目
- Private Subnetのデフォルトルート
- NATサービスの状態
- NATが配置されるネットワーク側の外部接続
- 送信元側のセキュリティ制御
- ポート枯渇や接続数などのメトリクス
- 宛先サービス側のアクセス制限
NATについては、 第35回「NAT Gatewayの役割」 も参照してください。
5．ロードバランサーを確認する
利用者からロードバランサーまでは正常でも、 ロードバランサーからバックエンドへの通信に問題がある場合があります。
ロードバランサーを含む切り分け
確認ポイント
- ロードバランサー自体が利用可能な状態か
- リスナーのポート・プロトコルが正しいか
- 転送先のバックエンドが正しいか
- バックエンドのヘルスチェックが正常か
- LBからバックエンドへの通信が許可されているか
- バックエンドアプリケーションが待ち受けているか
ヘルスチェックが失敗している場合、 ロードバランサーそのものではなく、 バックエンドサーバー、ポート、URL、 セキュリティ制御などを確認します。
詳細は、 第34回「ロードバランサーの基本」 で確認できます。
6．VPN・専用線を確認する
オンプレミスとクラウド間の障害では、 クラウド内部だけでなく接続部分も確認します。
VPNの場合
- VPNトンネルが確立しているか
- 片系だけ停止していないか
- 暗号化対象ネットワークが一致しているか
- BGPを利用している場合はセッションが確立しているか
- 必要な経路を相互に学習しているか
- オンプレミス側FWで通信が許可されているか
専用線の場合
- 物理・論理接続の状態
- BGPセッション
- 受信経路
- 広告経路
- 優先経路
- 冗長回線への切り替わり状態
BGPセッションが確立しているだけでは、 業務通信が正常とは限りません。
必要なプレフィックスを正しく送受信し、 実際のルーティングテーブルへ反映されているか まで確認します。
7．OS・アプリケーションを確認する
クラウドネットワーク側の設定が正常でも、 サーバー側でサービスが動いていなければ通信できません。
Linuxの確認例
# IPアドレス
ip addr
# ルーティング
ip route
# 待ち受けポート
ss -lntp
# DNS
cat /etc/resolv.conf
# HTTPS接続
curl -v https://example.com/
Windowsの確認例
ipconfig /all
route print
nslookup example.com
netstat -ano
Test-NetConnection example.com -Port 443
確認するポイント
- IPアドレスが想定どおりか
- デフォルトルートが存在するか
- DNS設定が正しいか
- 必要なポートを待ち受けているか
- OSファイアウォールで拒否されていないか
- アプリケーションプロセスが稼働しているか
「クラウドネットワーク担当だからOSは見ない」 と責任範囲だけで調査を止めないことが重要です。
自分が変更できない領域であっても、 どこまで正常で、どこから先が別チームの確認範囲なのかを整理して 引き継げる状態にします。
ログ・診断機能を使って「どこまで届いたか」を確認する
クラウドでは、 物理スイッチへログインしてパケットカウンターを見る代わりに、 フローログ、サービスログ、メトリクス、 到達性診断などを利用して通信を可視化します。
確認に使える情報
フローログ
送信元IP、宛先IP、ポートなどを確認し、 対象通信が観測されているかを調べます。
ロードバランサーログ
リクエストがLBへ到達しているか、 バックエンド応答がどうなっているかを確認します。
VPN・接続メトリクス
トンネルやセッションの状態、 通信量の変化などを確認します。
到達性診断
クラウド上の設定を解析し、 経路や通信制御のどこで到達性が失われているか確認します。
主要クラウドの代表的な診断機能
| クラウド | 代表的な機能 | 主な用途 |
|---|---|---|
| AWS | Reachability Analyzer / VPC Flow Logs | 設定上の到達性確認、IPトラフィック情報の確認 |
| Microsoft Azure | Network Watcher | 接続・ルーティング・通信制御などの診断 |
| Google Cloud | Connectivity Tests | 送信元から宛先までの到達性と設定の解析 |
診断ツールは非常に便利ですが、 「なぜその送信元・宛先・ポートでテストするのか」 を理解せず実行しても、結果を正しく判断できません。
正常系と比較する
障害調査で非常に有効なのが、 正常に通信できている端末やサーバーとの比較です。
| 項目 | 正常系 | 異常系 | 差分 |
|---|---|---|---|
| DNS結果 | 10.20.1.10 | 10.30.1.10 | あり |
| 送信元Subnet | 10.1.10.0/24 | 10.1.20.0/24 | あり |
| TCP/443 | 成功 | Timeout | あり |
| ルート | VPN経由 | VPN経路なし | あり |
このように差分を見つけると、 調査対象を短時間で絞り込めます。
実務ケース：社内PCからクラウドWebシステムへ接続できない
構成
障害発生構成
申告
利用者： 「https://portal.example.internal/ が開けません。」
STEP 1：DNS
portal.example.internal
→ 10.20.10.10
想定どおりロードバランサーのIPへ解決されています。 DNSの優先度を下げます。
STEP 2：VPN
VPNトンネルは確立しています。 ただし、トンネル確立だけでは業務通信の正常性は証明できません。
STEP 3：経路
オンプレミスから10.20.0.0/16へのルートは存在します。 クラウド側にも192.168.10.0/24への戻りルートがあります。
経路は正常と判断します。
STEP 4：セキュリティ制御
ロードバランサーでは、 192.168.10.0/24からTCP/443が許可されています。
ここまでで、 PC → LB の経路と通信制御には大きな問題が見つかっていません。
STEP 5：ロードバランサー
バックエンドのヘルスチェックを見ると、 Webサーバーが異常になっています。
さらに調査すると、 ロードバランサーからWebサーバーへ接続する TCP/8443がサーバー側の通信制御で許可されていませんでした。
原因： Webサーバー側の通信制御で、 ロードバランサーからTCP/8443への通信が許可されていなかった。
このケースから分かること
利用者から見ると単に「Webページが開かない」という障害ですが、 実際には、
PC
↓
DNS
↓
社内ネットワーク
↓
VPN
↓
クラウドルート
↓
セキュリティ制御
↓
ロードバランサー
↓
バックエンド通信
↓
Webサーバー
という複数段階を確認する必要があります。
クラウド障害切り分けでよくある失敗
失敗1．pingだけで判断する
ICMPが許可されているとは限りません。 実際の業務通信と同じポートで確認します。
失敗2．VPN UP＝通信正常と判断する
VPNが確立していても、 必要な経路や通信制御に問題があれば通信できません。
失敗3．往路だけ確認する
戻りルートがなければ通信は成立しません。 双方向の経路を確認します。
失敗4．クラウド設定だけを見る
OSファイアウォールやアプリケーション停止も 接続障害の原因になります。
失敗5．設定変更から入る
原因が分からないまま設定を変更すると、 状況を複雑にする可能性があります。
失敗6．正常系と比較しない
同じサービスへ接続できる端末があるなら、 その設定との差分が重要な手掛かりになります。
本番障害中に設定を変更する場合は、 変更理由、影響範囲、復旧確認方法、切り戻し方法を整理してから実施します。
顧客・上司への説明方法
障害対応では、 原因を調べる技術だけでなく、 まだ原因が分からない状態を正確に報告する力 も重要です。
悪い報告例
「クラウドのネットワークがおかしいようです。 現在調査中です。」
これでは、 どこまで調査したのか、 何が分かっているのかが伝わりません。
良い報告例
障害途中報告の例
事象：
東京拠点からクラウド上の業務システムへHTTPS接続できない状態です。
影響範囲：
現時点では東京拠点の利用者で事象を確認しています。
他拠点への影響は確認中です。
確認済み：
DNS名前解決は正常です。
オンプレミス・クラウド間VPNも確立しています。
双方向のルーティングも確認済みです。
現在の調査箇所：
ロードバランサーからバックエンドサーバー間の
TCP/8443通信とヘルスチェックを確認しています。
次の対応：
バックエンド側の通信制御とアプリケーション待ち受け状態を確認します。
原因確定前でも、 「確認済み」「未確認」「次に確認する場所」 を分けて伝えれば、調査状況を明確に説明できます。
英語ドキュメントで使われる表現
クラウドサービスの公式ドキュメントやサポート問い合わせでは、 次の表現がよく登場します。
| 英語 | 意味 | 調査時のイメージ |
|---|---|---|
| Reachability | 到達性 | 送信元から宛先まで通信できるか |
| Next hop | 次ホップ | パケットを次にどこへ送るか |
| Effective routes | 実際に有効な経路 | 複数設定を反映した最終的なルート |
| Denied / Dropped | 拒否／破棄 | 通信制御などでパケットが通らない |
| Health check | 正常性確認 | LBからバックエンドの状態を確認 |
| Asymmetric routing | 非対称ルーティング | 往路と復路が異なる経路を通る |
| Connection timeout | 接続タイムアウト | 一定時間応答を得られない |
| Connection refused | 接続拒否 | 宛先到達後に接続を受け付けていない可能性 |
ベンダー問い合わせで使える表現
We are unable to establish a TCP connection from the on-premises network to the cloud workload.
Source IP: 192.168.10.50
Destination IP: 10.20.10.10
Protocol/Port: TCP/443
DNS resolution and routing have already been verified.
The issue started after 10:15 JST.
英語で問い合わせる場合も、 「つながらない」とだけ書くのではなく、 送信元・宛先・ポート・発生時刻・確認済み事項を整理すると、 技術情報が伝わりやすくなります。
理解度チェック
解答を見る前に、 自分ならどの順番で調査するか考えてみてください。
問題1．FQDNでは接続できませんが、名前解決後のIPアドレスへ直接接続すると通信できます。 最初に優先して確認すべきものはどれですか。
- NAT
- DNS
- BGP
- ロードバランサーのCPU
解答を見る
IPアドレスで正常に接続できる場合、 ネットワーク経路自体は成立している可能性が高いため、 FQDNの名前解決結果やDNS設定を優先して確認します。
問題2．VPNトンネルがUPしていれば、 オンプレミスとクラウド間の業務通信も必ず正常でしょうか。
解答を見る
VPNトンネルが確立していても、 必要なルートがない、経路を学習していない、 セキュリティ制御で拒否されているなどの理由で 業務通信が失敗することがあります。
問題3．送信元から宛先へのルートは正常でした。 次にルーティングで必ず確認したいものは何ですか。
解答を見る
往路が正常でも、 宛先から送信元への経路がなければ通信は成立しません。
問題4．ロードバランサーへTCP/443で接続できますが、 Webページはエラーになります。 バックエンドがすべてUnhealthyでした。 次に確認する内容を2つ挙げてください。
解答を見る
例：
- ロードバランサーからバックエンドへの通信制御
- バックエンドの待ち受けポート
- ヘルスチェックのポート・URL
- アプリケーションの稼働状態
問題5．障害調査中に原因がまだ分からない場合、 顧客へ「調査中です」とだけ伝えれば十分でしょうか。
解答を見る
影響範囲、確認済み事項、現在調査している場所、 次に確認する内容を分けて報告すると、 原因確定前でも状況を正確に共有できます。
実践演習：Private SubnetのVMからインターネットへ接続できない
次の構成で、 Private Subnet上のVMから外部のWebサイトへ HTTPS接続できない障害が発生しました。
演習構成
確認結果
| 確認項目 | 結果 |
|---|---|
| VM-A | 正常稼働 |
| DNS名前解決 | 正常 |
| VM-Aの送信通信制御 | TCP/443許可 |
| Private Subnet Route | 0.0.0.0/0 → NAT |
| NAT | 正常稼働 |
| NAT側Subnet Route | 10.10.0.0/16 → Local のみ |
課題1．最も疑わしい箇所を答えてください
解答を見る
NAT側ネットワークからインターネットへ向かう経路を確認します。
Private SubnetからNATまでは経路がありますが、 NATからインターネット側へ通信を転送するための 外部接続経路が不足している構成が疑われます。
課題2．この障害で確認した順番を書いてください
解答例を見る
DNS → VMの状態 → セキュリティ制御 → Private Subnetのルート → NATの状態 → NAT側ネットワークのルート
課題3．顧客向けの途中報告を作成してください
影響範囲：
確認済み：
現在の調査箇所：
次の対応：
報告例を見る
事象：
Private Subnet上のVMから外部WebサイトへHTTPS接続できません。
確認済み：
VM稼働状態、DNS、送信通信制御、
VM側サブネットからNATまでの経路は正常です。
現在の調査箇所：
NATからインターネット側へ転送する経路を確認しています。
次の対応：
NAT側ネットワークのデフォルトルートと
インターネット接続設定を確認します。
自分の言葉で説明する課題
後輩から、 「クラウド上のサーバーへ接続できないとき、 何から確認すればいいですか？」 と質問されました。
1分程度で説明してください。
説明例を見る
まず、送信元・宛先・プロトコル・ポート・発生時刻を整理します。 そのうえで、DNS、送信元と宛先の状態、ルーティング、 セキュリティ制御、NATやロードバランサー、VPNなど、 実際の通信経路に沿って確認します。
往路だけでなく復路も確認し、 最後にフローログやサービスログを使って パケットがどこまで到達しているかを確認します。 ネットワークが正常なら、 OSファイアウォールやアプリケーションまで範囲を広げます。
まとめ
- クラウド障害は、送信元から宛先までの通信経路を分解して調査する
- 最初に送信元・宛先・プロトコル・ポート・発生時刻を明確にする
- DNS、ルート、セキュリティ制御、NAT、LB、VPNなどを順番に確認する
- pingだけで判断せず、実際の業務通信と同じプロトコル・ポートで確認する
- ルーティングでは往路だけでなく戻り経路も確認する
- VPNやBGPがUPしているだけで業務通信が正常とは判断しない
- クラウドネットワークが正常ならOSやアプリケーションまで調査範囲を広げる
- ログ・メトリクス・到達性診断を使い、仮説を証拠で検証する
- 障害報告では「確認済み・未確認・次の調査」を分けて説明する
上級者の障害対応とは、 多くの設定を知っていることではありません。 正常な通信経路を描き、 一つずつ事実を確認し、 根拠を持って原因候補を減らせることです。
コメント