OCI Network Path Analyzer

解決する課題

ネットワーク構成は VCN・サブネット・ルートテーブル・セキュリティリスト/NSG・各種ゲートウェイが絡み合い、「なぜつながらないのか」を人手で追うのは困難です。Network Path Analyzer は経路を静的に解析して、どこで通信が止まるかを示します。

• インスタンス間や VCN・オンプレミス間で通信できない原因がどこにあるかを素早く突き止めたい
• ルートテーブルやセキュリティルールの設定ミスを、実際にトラフィックを流す前に検出したい
• 構成変更やデプロイの前に、意図した経路で到達できるかを事前検証したい
• セキュリティリスト・NSG・ルートのどのレイヤーで遮断されているのかをレイヤーごとに切り分けたい

主要概念と用語

Network Path Analyzer は、送信元から宛先までの「パス」を定義して解析します。

• Network Path Analyzer（ネットワークパスアナライザ）: 送信元・宛先・プロトコル/ポートを指定すると、経路上の構成要素を順にたどって到達可否を判定する診断機能
• パス分析（Path Analysis）: 1回の解析実行。送信元から宛先への片方向の経路を評価する
• 送信元 / 宛先（Source / Destination）: 解析の起点と終点。VNIC やインスタンスの IP、VCN 内の IP、オンプレミス側 IP などを指定する
• プロトコルとポート: TCP / UDP / ICMP などと、必要に応じてポート番号を指定し、その通信が許可されるかを評価する
• アナリシス（保存された分析）: 送信元・宛先・プロトコルの組み合わせを名前付きで保存し、構成変更後に再実行して回帰確認できる
• 静的解析（Static Analysis）: 実トラフィックを流さず、構成（ルート・セキュリティルール・ゲートウェイ）だけから到達性を導く方式
• 遮断ポイント: 経路上で通信が止まる箇所。ルートが無い、セキュリティリスト/NSG で拒否、ゲートウェイ不在などとして示される

仕様・制限・クォータ

• 解析は**静的（構成ベース）**で、実際のパケットは流さない。構成上は通っても、OS のファイアウォールやアプリ層の問題までは検出しない
• 評価対象は VCN 内の経路に加え、ゲートウェイ（IGW / NAT / SGW / DRG など）を介した経路も含む。VPN や FastConnect 経由のオンプレミス方向も対象になりうる
• 評価は片方向。双方向の疎通を確認したい場合は、向きを入れ替えてもう一度解析する
• ルートテーブル・セキュリティリスト・NSG・ゲートウェイ構成を読み取るため、解析を行う主体に該当リソースの読み取り権限が必要
• 保存したアナリシスはテナンシ/リージョンごとの**サービス制限（リミット）**の枠内で管理する
• 解析結果は解析した時点の構成のスナップショットに基づく。構成を変えたら再実行して最新の判定を得る

内部の仕組み

Network Path Analyzer は、送信元から宛先へ向かう経路上の構成要素を順番にシミュレーションします。実トラフィックは流さず、各要素のルールを構成情報から評価して到達可否を判定します。

評価は概ね次の順序で進みます。

1. 送信元側の**セキュリティルール（egress / 送信許可）**でその宛先・ポートが許可されているか
2. 送信元サブネットのルートテーブルに宛先へのルートがあり、適切なゲートウェイ/ネクストホップへ向くか
3. 経路上の**ゲートウェイ（IGW / NAT / SGW / DRG など）**が存在し、その通信を通す構成か
4. 宛先側サブネットのルートテーブルと戻り経路（必要な場合）
5. 宛先側の**セキュリティルール（ingress / 受信許可）**でその送信元・ポートが許可されているか

いずれかで条件を満たさないと、その箇所が遮断ポイントとして示されます。結果は経路を要素ごとに分解した形で表示され、どのレイヤーが原因かが一目で分かります。

設計パターン / ベストプラクティス

• 障害切り分けの一次ツールにする: 「つながらない」報告を受けたら、まず Network Path Analyzer で経路を解析し、ネットワーク構成側かインスタンス内部側かを切り分ける
• 変更前後の回帰確認: 重要な経路を名前付きアナリシスとして保存し、ルートやセキュリティルールの変更後に再実行して、意図せぬ遮断が起きていないか確認する
• レイヤー別の確認順を固定する: ルート → ゲートウェイ → セキュリティリスト/NSG の順で原因を絞る運用手順を定めておく
• 重複しない CIDR 設計とセットで使う: 経路解析で問題が出やすいのはアドレス設計の不備や非対称ルーティング。設計段階のレビュー材料としても活用する
• 代表的な経路をカタログ化: App → DB、オンプレミス → VCN、VCN → Object Storage など、よく使う経路を保存しておき定期的に検証する

運用・監視

• 接続トラブル時の標準切り分け手順に組み込み、まず経路解析で構成側の問題有無を確定させる
• Network Path Analyzer は構成側を診断する。OS ファイアウォールやアプリ層が疑わしい場合は、VCN Flow Logs（OCI Logging）で実際の許可/拒否を突き合わせる
• 静的解析で「到達可」でも実際に通らない場合は、ホスト内ファイアウォール・ルーティング・サービス稼働状況を別途確認する
• 構成変更（ルートテーブル更新、NSG 変更など）の運用フローに、事前/事後の経路解析をチェック項目として組み込む
• 結果は解析時点の構成に基づくため、原因調査ではいつ解析したかと当時の構成を併せて記録する

コスト

Network Path Analyzer は OCI のネットワーク診断機能として提供され、一般に経路解析の実行そのものに対する追加課金は発生しないか、ごく軽微です。実トラフィックを流さないため、解析によるデータ転送コストも生じません。一方で、併用する VCN Flow Logs（OCI Logging）は取り込み・保管したログ量に応じた課金が発生しうるため、ログ側のコストは別途考慮します。具体的な料金は変動するため、最新の公式料金ページで確認してください。

セキュリティ

• 経路解析はセキュリティリスト/NSG の許可・拒否を評価対象に含むため、意図せず開いている経路や、逆に塞がりすぎている経路を発見できる
• 解析を行う主体には、対象の VCN・サブネット・ルートテーブル・セキュリティルール・ゲートウェイを読み取る IAM 権限が必要。診断権限は最小権限で付与する
• 解析結果はネットワーク構成の機微情報（到達可能な経路）を含むため、閲覧範囲を適切に制限する
• 「到達可」と判定されても、それはネットワーク経路が通ることを意味するだけで、宛先サービス側の認証・認可（IAM など）とは別レイヤーである点に注意する

関連サービス・比較

VCN Flow Logs が「実際に流れた通信の許可/拒否」を記録するのに対し、Network Path Analyzer は「構成上つながるはずか」を実トラフィックなしで判定します。両者は補完関係にあります。

ハンズオン / CLI例

# 送信元・宛先・プロトコルを定義したパス分析（アナリシス）を作成
# protocol は IANA 番号で指定（例: 6=TCP）。endpoint は IP やリソースの OCID を指定する
oci vn-monitoring path-analyzer-test create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --display-name app-to-db-check \
  --protocol 6 \
  --source-endpoint '{"type":"IP_ADDRESS","address":"10.0.1.10"}' \
  --destination-endpoint '{"type":"IP_ADDRESS","address":"10.0.2.20"}'

# 保存したアナリシスの一覧を確認
oci vn-monitoring path-analyzer-test list \
  --compartment-id ocid1.compartment.oc1..xxxx

# 経路解析を実行（実トラフィックは流さず構成から到達性を判定）
# 結果には経路上の各要素と、遮断があればその箇所が含まれる
oci vn-monitoring path-analysis create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --path-analyzer-test-id ocid1.pathanalyzertest.oc1..xxxx