接続テストの一般的な使用例

接続テストは、トラフィックがネットワーク内のエンドポイント間で正常に転送されるかどうかを評価します。ネットワーク到達性を評価するには、ネットワーク構成を分析します。プローブ パケットを送信して評価する場合もあります。

このページでは、接続テストの一般的な使用例を次の 6 つのカテゴリに分類して説明します。

  • 共有 VPC や VPC ネットワーク ピアリングを使用するネットワークを含む、Virtual Private Cloud(VPC)ネットワーク内でのテスト
  • Google マネージド サービスのテスト(プレビュー
  • VPC ネットワークから非 VPC ネットワーク(オンプレミスのデータセンターなど)へのテスト
  • Google Cloud 以外のネットワークから VPC ネットワークへのテスト
  • Google Cloud 以外のネットワークから別の Google Cloud 以外のネットワークへのテスト
  • Google Cloud ロードバランサのテスト

無効な構成または整合性のない構成の検出で、こうしたケースを取り扱う方法について説明します。

仮想マシン(VM)インスタンスから別のインスタンスへのテストを行うユースケースでは、Google Cloud Console に提供されるテスト結果を含む、エンドツーエンドのテストシナリオ全体について説明します。

テストの実施方法については、接続テストの実施をご覧ください。

トレース図の凡例

このページのトレース図では、次の凡例で説明されている記号を使用しています。

記号 名前 意味
パケット トレース図の凡例: 灰色のひし形
灰色のひし形
チェックポイント 接続テストにより構成がチェックされ、トレース パケットを転送、配信、またはドロップする必要があるかどうかを決める決定ポイント。
パケット トレース図の凡例: 青い四角形
青い四角形
ホップ トレース パケットの転送パス内のステップ。VPC ネットワークのネクストホップ(Cloud Load Balancing プロキシや Cloud VPN トンネルなど)にパケットを転送する Google Cloud リソースを表します。
パケット トレース図の凡例: オレンジ色の六角形
オレンジ色の六角形
エンドポイント トレース パケットの送信元または送信先。

VPC ネットワーク内のテスト

接続テストの一般的な使用例は、同一またはピアリングされた VPC ネットワーク内の 2 つの Compute Engine 仮想マシン(VM)インスタンス間のテストです。このタイプの接続テストでは、構成分析とダイナミック検証の両方を使用してネットワーク到達性を評価します。

接続テストでは、構成を分析するためにトレースパスを特定して評価します。

次の図は、2 つの VM インスタンス間の一般的なトレースパスを示しています。Match routes オブジェクトは、1 つの VPC ネットワーク内または 2 つのピアリングした VPC ネットワーク間でトラフィックを転送するルートを表します。

送信元 VM から送信先 VM へのトレース
送信元 VM から送信先 VM へのトレース

次の手順では、トレース図の各ポイントに対応するチェックポイントについて説明します。各チェックポイントでは、チェックに失敗する場合があります。失敗の理由はクエリ結果に示されます。テストの状態とメッセージの全一覧については、構成分析状態のリファレンスをご覧ください。

  1. 接続テストでは、指定した送信元 IP アドレスで送信元 VM が下り(外向き)パケットを送信できることを確認します。送信元 IP アドレスが指定されていない場合は、プライマリ内部 IP アドレスをデフォルトに設定できることを確認します。設定できない場合は、この VM で IP 転送を有効にする必要があります。
  2. 接続テストは、VM インスタンスとの間のシミュレートされたパケットが、そのインスタンスが所有していない IP アドレスを使用している場合に、なりすましチェックを実施します。VM が所有する IP アドレスには、すべての VM 内部 IP アドレスとセカンダリ IP アドレスが含まれます。

    アドレスが、外部トラフィックから発信されているように見せかけたアドレス(外部アドレスとも呼ばれる)である場合、その IP アドレスはなりすましチェックに合格しません。

  3. ソースからトレース パケットを送信できるかどうかを判断するために、接続テストは適切な下り(外向き)ファイアウォール ルールを検証します。このプロセスの一環として、接続テストはまず、既存の階層のファイアウォール ポリシールールを評価します。階層型ファイアウォール ポリシールールと VPC ファイアウォール ルールが接続に与える影響の詳細については、階層型ファイアウォール ポリシーの例をご覧ください。
  4. 接続テストは、ルーティング順序に従って、送信先 IP アドレスのルートを検索(照合)します。送信先 VM インスタンスに使用できる他のルートがない場合、接続テストではネクストホップを含むデフォルトの静的ルートをインターネット ゲートウェイとして使用します。このデフォルト ルートが削除されていない限り、すべての VPC ネットワークで使用されます。
  5. 接続テストでは、ネットワークの上り(内向き)ファイアウォール ルールがパケットの送信先 VM への到達を許可していることを確認します。ここでも、接続テストはまず、既存の階層のファイアウォール ポリシールールを評価します。
  6. 必要に応じて、接続テストは 2 番目の VM に到着したパケットに対してなりすましチェックを行います。
  7. 接続テストでは、送信先 VM が指定した送信先 IP アドレスを持つパケットを受信できることを確認します。このアドレスが外部 IP アドレスの場合、送信先 VM で IP 転送が有効にされている必要があります。外部 IP アドレスとは、VM に属していないアドレスのことです。

Console

次の Google Cloud Console のスクリーンショットは、VM から VM へのテスト結果を示しています。

構成分析の結果には、パケット配信可能状態であることが示されています(API レスポンスでは、このラベルは Deliver の最終状態に対応します)。

この結果は、送信元 VM から宛先 VM へのパス上にあるすべての Google Cloud リソースのネットワーク接続が検証されたことを示しています。 この場合、ルートには 2 つの VPC ファイアウォール ルール(default という暗黙の VPC ファイアウォール ルール)と、この VPC ネットワーク用に作成されたルールがあります。

接続テストでは、アクティブ プローブを使用して、宛先 VM へのネットワーク到達性を動的に検証します。この結果の詳細が [前回のパケット送信の結果] フィールドに表示されます。

VM 間トレースの Cloud Console のスクリーンショット
VM 間トレースの Cloud Console のスクリーンショット

トレースパスの各カードを展開すると、詳細が表示されます。

次の例は、展開した上り(内向き)ファイアウォール ルールのカードを示しています。このカードには、VPC ネットワーク、ファイアウォール ルールに構成されたアクション(許可)、ルールの優先度に関する情報が含まれています。

展開した上り(内向き)ファイアウォール ルールのカード
展開した上り(内向き)ファイアウォール ルールのカード

ネクストホップがピアリングした VPC ネットワークである VPC ネットワーク ルートがトレースに含まれている場合、トレースは VM インスタンスではなく VPC ネットワークから開始されます。このタイプのトレースでは、テスト対象の IP アドレスが VM インスタンスではなくネットワークの範囲にあるため、ネットワーク レベルでファイアウォール ルールとルートが検証されます。

ピアリングしたネットワークは、同じプロジェクトまたは別のプロジェクトに存在できます。次のトレース例では、異なるプロジェクトのピアリングしたネットワークを示しています。

別のプロジェクトにあるアクセス可能なピアリングした VPC ネットワークを介した VM 間のトレース。
別のプロジェクトにあるアクセス可能なピアリングした VPC ネットワークを介した VM 間のトレース

VPC ネットワークのテストの失敗

次の表に、VPC ネットワーク内のテストの一般的な失敗を示します。

失敗の種類 説明 トレース結果
ファイアウォール ルールによってブロックされた ソースまたは宛先のエンドポイントから送信されるトラフィックは、階層型のファイアウォール ポリシールールまたは VPC ファイアウォール ルールによってブロックされます。
  • 階層型ファイアウォール ポリシールールによって接続がブロックされている場合、トレースにはポリシーの名前が含まれます。テストを行っているユーザーに、ポリシーの詳細を表示する権限が付与されていない可能性があります。この状況の詳細については、トラブルシューティングをご覧ください。
  • VPC ファイアウォール ルールによって接続がブロックされている場合、トレースには、関連する上り(内向き)、または下り(外向き)のファイアウォール ルールの名前が一覧表示されます。
一致するルートがない 送信先エンドポイントへのルートが見つかりませんでした。
  • 送信元と宛先の VM インスタンスが別の VPC ネットワークに存在し、それらのネットワークがピアリングされていない場合は、分析によってパケットが破棄される可能性があると判定されます。
  • 両方の VM が同じネットワーク内に存在していても一致するルートが見つからない場合、トラフィックは、デフォルトのインターネット ルート(インターネット ゲートウェイへのネクストホップ)に送信されます。この場合、トラフィックは宛先 VM に到達せず、パケットがドロップされる可能性があると分析されます。
  • インターネット ゲートウェイへのルートがない場合、パケットがドロップされる可能性があると分析されます。
インスタンスが実行されていない 送信先 VM インスタンスは存在しますが、実行状態ではありません。 この場合、パケットがドロップされる可能性があると分析されます。
ネクストホップが無効 VM インスタンスに構成されたネクストホップが存在せず、そのインスタンスへのルートは無効です。 この場合、パケットがドロップされる可能性があると分析されます。

Console

次のスクリーンショットは、上り(内向き)の階層型ファイアウォール ポリシールールによって接続がブロックされたために失敗したトレースを示しています。

階層型ファイアウォール ポリシールールによってブロックされているトレースの Cloud Console のスクリーンショット。
階層型ファイアウォール ポリシールールによってブロックされているトレースの Cloud Console のスクリーンショット

共有 VPC ネットワークのテストの失敗

共有 VPC ネットワークでは、ホスト プロジェクトまたはサービス プロジェクトに対する権限がない場合、次の表に示すテストの失敗につながることがあります。

失敗の種類 動作 トレース結果
権限がホスト プロジェクトに限定される 送信先 IP アドレスが配置されているサービス プロジェクトに対する権限がないため、トレースを行えません。 構成分析の結果には、構成分析が中断状態であることが示されています(API レスポンスでは、このラベルは Abort の最終状態に対応します)。
権限がサービス プロジェクトに限定される

権限がないため、Cloud Console でトレースを行うことや、ホスト プロジェクト ネットワークを選択することができません。

ホスト プロジェクトがネットワーク構成を所有しているため、ホスト プロジェクト内の VPC ファイアウォール ルール、ネットワーク ルート、IP アドレスにアクセスできないと、サービス プロジェクトのリソースに対するトレースを続行できません。

接続テストでは、パケットを送信先に配信できるかどうかを判定できないため、全体的なネットワーク到達性の結果は Undetermined になります。

VPC ネットワーク ピアリング ネットワークのテストの失敗

VPC ネットワーク ピアリングでは、peered ネットワークの Google Cloud プロジェクトに対して primary ネットワークからの権限がない場合、次の表に示すテストの失敗につながることがあります。

失敗の種類 動作 トレース結果
ピアリングした VPC ネットワーク内のプロジェクト構成に対する権限がない 接続テストでトレースできるのは、プライマリ ネットワークのプロジェクトの構成のみに限定されます。 構成分析の結果として [パケットは転送されている可能性があります] が表示されます。この結果は、パケットがネットワークからアクセス権のないネットワークに送信されることを示します。この場合、パケットはピアリングしたネットワーク ゲートウェイに転送されます。API レスポンスでは、この状態は Forward に対応します。

次のトレースパスは、ピアリングした VPC ネットワークに対するこのテストの失敗を示しています。

別のプロジェクトにあるアクセス不能のピアリングした VPC ネットワークを介した VM 間のトレース。
別のプロジェクトにあるアクセス不能のピアリングした VPC ネットワークを介した VM 間のトレース

Google マネージド サービスのテスト

接続テストの構成分析を使用すると、Google Kubernetes Engine(GKE)クラスタ マスターや Cloud SQL インスタンスなど、Google マネージド サービスとの間のルートを分析できます。これらのリソースが存在する Google 所有プロジェクトにアクセスする権限がなくても、接続テストを行い、プロジェクトの VPC ネットワークの構成を分析し、全体的なネットワーク到達性を確認できます。接続テストでは、Google 所有プロジェクト内での構成の分析結果は提供されません。

デフォルトの接続テストでは、Google マネージド サービス エンドポイントのプライベート IP アドレスと、ネットワークと Google マネージド ネットワーク間の VPC ネットワーク ピアリング接続を使用してテストが行われます。エンドポイントにプライベート IP アドレスが割り振られていない場合はパブリック IP アドレスが使用されます。接続テストでは、パケットがエンドポイントに到達できるかどうかを分析します。Google 所有の VPC ネットワーク内でのエンドポイントの構成も分析します。接続テストでプロジェクト内に構成の問題が見つかると、Google 所有のネットワークに到達する前に分析が停止します。

次の図は、Google マネージド サービスへの接続をテストする際のトレースパスを表しています。ここでは、例として GKE ノード間のテストを使用しています。

送信元の GKE ノードから宛先の GKE ノードへのマスター トレース。
送信元の GKE ノードから宛先の GKE ノードへのマスター トレース

Cloud SQL から VM への接続

このセクションでは、Cloud SQL インスタンスから VM への接続テストの例を示します。

サンプルの入力値

次の表に、Cloud SQL インスタンスからのテストで使用する入力値を示します。テスト成功の出力は、次のセクションで確認できます。

入力パラメータ 入力値
プロトコル TCP
送信元 Cloud SQL インスタンス instance-1
ソース プロジェクト my-project
宛先 VM vm-1
宛先ポート 80

テストの成功

このセクションでは、Cloud SQL インスタンスからのテストに成功した場合の結果を示します。

Console

次の Cloud Console のスクリーンショットは Cloud SQL インスタンスからのトレース結果を示しています。これは、Reachable の全体的な結果を表しています。

この結果は、接続テストで送信元の Cloud SQL インスタンスから宛先 VM へのネットワーク接続が検証されたことを示しています。このテストでは、Cloud SQL インスタンスが実行されている Google 所有プロジェクト内の構成も分析されています。Google 所有プロジェクトのリソースに対する表示権限がないため、これらのリソースの詳細情報は表示されません。

Cloud SQL から VM へのトレース結果が表示されている Cloud Console のスクリーンショット。
Cloud SQL インスタンスから VM へのトレース結果が表示されている Cloud Console のスクリーンショット

GKE ノードから GKE クラスタ マスターへの接続

このセクションでは、Google Kubernetes Engine(GKE)ノードから GKE クラスタ マスターへの接続テストの例を示します。

テスト入力の例

次の表に、GKE マスターへの接続テストで使用する入力値を示します。テスト成功の出力は、次のセクションで確認できます。

入力パラメータ 入力値
プロトコル TCP
送信元の GKE ノード gke-cluster-1-node-1
ソース プロジェクト my-project
宛先 GKE クラスタ マスター projects/myproject/locations/us-central1/clusters/cluster-1
宛先ポート 443

テストの成功

このセクションでは、GKE マスターへの接続テストに成功した場合の結果を示します。

Console

次の Cloud Console のスクリーンショットは、宛先の GKE マスターへのトレース結果を示しています。これは、Reachable の全体的な結果を表しています。

この結果は、接続テストで送信元 GKE ノードから宛先 GKE マスターへのネットワーク接続が検証されたことを示しています。このテストでは、マスターが実行されている Google 所有プロジェクト内のリソースの構成も分析されています。Google 所有プロジェクトのリソースに対する表示権限がないため、これらのリソースの詳細情報は表示されません。

GKE ノードからマスターへのトレース結果が表示されている Cloud Console のスクリーンショット。
GKE ノードからマスターへのトレース結果が表示されている Cloud Console のスクリーンショット

パブリック IP アドレスを使用した GKE ノードから GKE マスターへの接続

次の表に、パブリック IP アドレスを使用した GKE マスターへの接続テストの入力値を示します。テスト成功の出力は、次のセクションで確認できます。

テスト入力の例

入力パラメータ 入力値
プロトコル TCP
送信元の GKE ノード gke-cluster-1-node-1
ソース プロジェクト my-project
宛先 IP アドレス 104.1.1.1
宛先ポート 443

テストの成功

このセクションでは、パブリック IP アドレスを使用した GKE マスターへの接続テストに成功した場合の結果を示します。

Console

次の Cloud Console のスクリーンショットは、GKE マスターのパブリック IP アドレスへのトレース結果を示しています。これは、Reachable の全体的な結果を表しています。

この結果は、接続テストで送信元の GKE ノードから GKE マスターではなく、GKE ノードから GKE マスターが実行されるネットワークへのネットワーク接続が検証されたことを示しています。パブリック IP アドレスを使用してテストする場合、マスターが実行されている Google 所有プロジェクト内のリソースの構成は分析されません。

パブリック IP アドレスを使用した GKE ノード間のトレース結果が表示されている Cloud Console のスクリーンショット。
パブリック IP アドレスを使用した GKE ノード間のトレース結果が表示されている Cloud Console のスクリーンショット

Google マネージド サービスの接続テストの失敗

Google マネージド サービスの接続テストに失敗し、サービス内でパケットがドロップされたというエラー メッセージ(DROPPED_INSIDE_GKE_SERVICEDROPPED_INSIDE_CLOUD_SQL_SERVICE など)が表示されることがあります。次のようなテストでこのメッセージが返された場合、サービスをホストする Google 所有プロジェクトの構成に問題がある可能性があります。

  • 同じクラスタ内の GKE マスターと GKE ノード間の接続(どちらの方向でも可)。
  • VPC ネットワークから、ネットワークに接続している Cloud SQL インスタンスへの接続(送信元と宛先が同じリージョンにある場合)。

このいずれかで上記のエラー メッセージが表示された場合は、サポートにお問い合わせください。それ以外の場合にエラー メッセージが表示された場合は、入力値が正しくない可能性があります。テスト対象のエンドポイントが存在し、Google 所有プロジェクトのマネージド リソースへの接続が想定されることを確認します。たとえば、GKE ノードから GKE マスターへの接続をテストする場合は、そのノードが存在し、マスターへの接続が想定されることを確認します。

サンプルテストの入力値: 別のリージョンに存在する VM から Cloud SQL インスタンスへの接続

次の表に、VM から Cloud SQL インスタンスへの接続テストの入力値の例を示します。VM は Cloud SQL インスタンスと異なるリージョンに存在します。失敗したテストの出力を表示するには、次のセクションに進んでください。

入力パラメータ 入力値
プロトコル TCP
送信元 VM instance-1
この VM は Cloud SQL インスタンスと異なるリージョンにあります。
ソース プロジェクト my-project
宛先 Cloud SQL インスタンス vm-1
宛先ポート 5432

テストの失敗

このセクションでは、Cloud SQL インスタンスへの接続テストに失敗した場合の結果を示します。

Console

次の Cloud Console のスクリーンショットは、宛先 Cloud SQL インスタンスへのトレース結果を示しています。これは、Unreachable の全体的な結果を表しています。

VM から Cloud SQL へのテストに失敗した場合のトレース結果を示す Cloud Console のスクリーンショット。
VM から Cloud SQL へのテストに失敗した場合のトレース結果を示す Cloud Console のスクリーンショット。

VPC ネットワークから Google Cloud 以外のネットワークへのテスト

接続テストの構成分析を使用すると、Cloud VPN または Cloud Interconnect 経由で VPC ネットワークから Google Cloud ネットワーク以外への接続をテストできます。通常、Google Cloud 以外のネットワークは、オンプレミス ネットワークまたは別のクラウド プロバイダのネットワークです。

構成分析では、ピア ネットワーク内のルーターまたは VPN ゲートウェイの外部 IP アドレスまでのネットワーク パスのみを評価します。

次の例は、VPC ネットワークの VM1 から、静的ルーティングを使用する Classic VPN トンネル経由でオンプレミス ネットワーク内の VM2 にトレースしています。

静的ルートを使用し、Cloud VPN トンネルを介したパケット トレース。
静的ルートを使用し、Cloud VPN トンネルを介したパケット トレース

ピア ネットワークの送信先 IP アドレスに一致する静的または動的ルートがある場合、構成分析はルートの優先順位に従ってルートを照合および検証します。

ネクストホップがあるすべての送信先に対しては、インターネット ゲートウェイのようなデフォルトの静的ルートがあります。このデフォルト ルートが削除または変更されていない限り、接続テストはこのルートと照合されます。

デフォルトの静的ルートがなく、送信先への有効なルートが他にない場合、トレースの最終状態として Drop を返します。

静的ルーティングを使用した Google Cloud 以外のネットワークへのトレースパス
静的ルーティングを使用した Google Cloud 以外のネットワークへのトレースパス


動的ルーティングを使用した Google Cloud 以外のネットワークへのトレースパス。
動的ルーティングを使用した Google Cloud 以外のネットワークへのトレースパス

Google Cloud 以外のネットワークから VPC ネットワークへのテスト

構成分析では、オンプレミス ネットワークからの受信パケットが VPC ネットワークに到着した後に、VPC ネットワークがそのパケットを受信できることを確認します。また、VPC ネットワーク構成で、このパケットが目的の宛先に配信可能かどうかも確認します。構成分析の結果には、パケット配信可能状態であることが示されています(API レスポンスでは、最終状態は Forward になります)。この場合、宛先は到達可能と見なされます。

VPC ネットワークが Cloud Router 経由でオンプレミス ネットワークとピアリングすると、VPC ネットワークはピアリングしたオンプレミス ネットワークから 1 つ以上の動的ルートを受信します。同時に、VPC ネットワークはピアリングしたオンプレミス ネットワークへの独自のルートをアドバタイズします。

接続テストはオンプレミス ネットワーク構成にアクセスできないため、オンプレミス ルーターの正しいルートとファイアウォール ルールの構成を確認できません。したがって、オンプレミス ネットワークから VPC ネットワークへのトラフィックは、接続テストの構成分析によって常に有効とみなされます。

ただし、接続テストでは、VPC 構成によって Google Cloud で宛先へのパケット配信が可能かどうかも評価できます。ネットワーク到達性を評価するため、次の Google Cloud リソースを評価します。

  • VPC ネットワークの上り(内向き)ファイアウォール ルール。
  • VPC ネットワーク内の IP アドレスへのアドバタイズされたルート。Cloud Router によりオンプレミス(ピア)ネットワークにアドバタイズされます。

テスト入力の例

次の表は、前のセクションで説明したテスト用の Google Cloud ロードバランサの入力値の例を示しています。テストが成功した場合の出力を表示するには、次のセクションに進みます。

入力パラメータ 入力値
プロトコル TCP
オンプレミス IP アドレスのサンプル 10.0.29.2
[This is an IP address used in Google Cloud] チェックボックス オンプレミスの送信元 IP アドレスを指定する場合、このチェックボックスをオフにします。

オンプレミス ネットワークからのテスト成功

このセクションでは、オンプレミス ネットワークから VPC ネットワークへのテストに成功した場合の例を示します。

Console

次のテスト結果により、オンプレミスの IP アドレスから VM インスタンスへの Cloud VPN を介した接続性が評価されます。さらに Border Gateway Protocol(BGP)のセッション、ルート、VPC ファイアウォール ルールも評価されます。

オンプレミスから Google Cloud へのテスト成功の出力例。
オンプレミスから Google Cloud へのテスト成功の出力例

Google Cloud 以外の 2 つのネットワーク間のテスト

接続テストの構成分析を使用すると、Network Connectivity Center 経由で接続された 2 つの Google Cloud 以外のネットワーク到達性を評価できます。ここでは、Google Cloud 以外のネットワークは通常、オンプレミスのデータセンターまたはブランチ オフィスです。

接続テストはオンプレミス ネットワークの構成にアクセスしないため、オンプレミス ルーターでルートとファイアウォール ルールの構成を確認できません。したがって、オンプレミス ネットワークから VPC ネットワークへのトラフィックは、常に接続テスト構成分析によって有効とみなされ、Google Cloud 内の構成のみが検証されます。

構成分析は、Network Connectivity Center のスポークに関連付けられている Cloud Router からオンプレミス ネットワークの範囲を学習します。オンプレミス ネットワーク間の接続性に影響する可能性のある VPC ネットワーク構成の問題を特定できます。

すべての Network Connectivity Center のスポークタイプは、Cloud Router を使用して BGP セッション経由でルートを交換します。次に例を示します。

  • Router アプライアンスのスポーク: Cloud Router と Router アプライアンス インスタンスが同じリージョンにあると場合、互いにルートを交換します。
  • Cloud VPN と VLAN アタッチメント スポーク: Cloud Router は、BGP ルートをオンプレミス ネットワーク内のルーターと交換します。

Network Connectivity Center の詳細については、Network Connectivity Center の概要をご覧ください。

Router アプライアンスを介した Google Cloud 以外の 2 つのネットワーク間のテスト

次の例の接続テストでは、オンプレミス ネットワーク間の転送をシミュレートしたパケットのトレースを行います。パケットは、最初のオンプレミス ネットワークに接続している Router アプライアンス スポークから VPC ネットワークに入ります。そこからは、2 番目のオンプレミス ネットワークに接続している Router アプライアンス スポークの Cloud Router がアドバタイズする動的ルートに従います。パケットが 2 番目の Router アプライアンス インスタンスからオンプレミス ネットワークに到達します。

サンプルの入力値

次の表に、オンプレミス ネットワークの IP アドレスからのテストで使用する入力値の例を示します。テストに成功した場合の出力は次のセクションで示します。

入力パラメータ 入力値
プロトコル TCP
送信元エンドポイントの IP アドレス 192.168.1.1
[This is an IP address used in Google Cloud] チェックボックス オンプレミスの送信元 IP アドレスを指定する場合、このチェックボックスをオフにします。
宛先エンドポイントの IP アドレス 172.16.1.1
[This is an IP address used in Google Cloud] チェックボックス オンプレミスの宛先 IP アドレスを指定する場合、このチェックボックスをオフにします。

オンプレミス ネットワークから別のオンプレミス ネットワークへのテストの成功

このセクションでは、あるオンプレミス ネットワークから別のネットワークへの Router アプライアンス スポークを介したテストの成功例を示します。

Console

次のテスト結果では、2 つの Router アプライアンス インスタンスを経由したオンプレミス ネットワーク間の接続性が評価されています。また、BGP セッション、ルート、VPC ファイアウォール ルールも評価されています。

オンプレミスからオンプレミスへのテストに成功した場合の出力例
オンプレミスからオンプレミスへのテストに成功した場合の出力例

Cloud VPN と Cloud Interconnect を介した Google Cloud 以外の 2 つのネットワーク間のテスト

次の例の接続テストでは、オンプレミス ネットワーク間の転送をシミュレートしたパケットのトレースを行います。パケットは、VPN ゲートウェイ経由で VPC ネットワークに入ります。パケットは、相互接続を介して他のオンプレミス ネットワークに到達します。

サンプルの入力値

次の表に、オンプレミス ネットワークの IP アドレスからのテストで使用する入力値の例を示します。テストに成功した場合の出力は次のセクションで示します。

入力パラメータ 入力値
プロトコル TCP
送信元エンドポイントの IP アドレス 10.0.0.1
[This is an IP address used in Google Cloud] チェックボックス オンプレミスの送信元 IP アドレスを指定する場合、このチェックボックスをオフにします。
宛先エンドポイントの IP アドレス 10.240.0.1
[This is an IP address used in Google Cloud] チェックボックス オンプレミスの宛先 IP アドレスを指定する場合、このチェックボックスをオフにします。
宛先ポート 80

オンプレミス ネットワークから別のオンプレミス ネットワークへのサンプルテスト

このセクションでは、VPN と VLAN アタッチメントを経由したオンプレミス ネットワーク間の接続テストの例を示します。

Console

次のテスト結果では、VPN と VLAN アタッチメント スポークを経由したオンプレミス ネットワーク間の接続性が評価されています。

オンプレミスからオンプレミスへのテストに成功した場合の出力例
VPN と VLAN アタッチメント スポークを経由したオンプレミス間のテストに成功した場合の出力例

Google Cloud ロードバランサのテスト

接続テストの構成分析は、全タイプの Google Cloud ロードバランサへのシミュレーション パケットによるトレースをサポートしています。

外部 HTTP(S) ロードバランサのトレースパスは、TCP プロキシ ロードバランサと SSL プロキシ ロードバランサにも適用されます。詳細については、Cloud Load Balancing の概要をご覧ください。

次の例では、接続テストは、外部ホストから外部 HTTP(S) ロードバランサの VIP へのシミュレーション パケットをトレースします。外部ホストからの TCP 接続は、外部 HTTP(S) ロードバランサのプロキシで終了します。外部 HTTP(S) ロードバランサは、ロードバランサのバックエンドとして機能する VM への新しい TCP 接続を開始します。

外部 HTTP(S) ロードバランサへの一般的なトレースパス(凡例付き)
外部 HTTP(S) ロードバランサへの一般的なトレースパス

接続テストの構成分析は、次のトレースパスで 3 つのトレースを生成します。3 つのロードバランサ バックエンドに適用可能なパスごとに 1 つのトレースを生成します。接続テストでは、実際のデータプレーンではなく構成のみを検証するため、このようにします。

外部 HTTP(S) ロードバランサへのパケット トレース
外部 HTTP(S) ロードバランサへのパケット トレース(図の凡例を参照)

テスト入力の例

次の表は、前のセクションで説明した外部 HTTP(S) ロードバランサに対するテストの入力値の例を示しています。テスト成功の出力は、次のセクションで確認できます。

入力パラメータ 入力値
送信先プロトコル TCP
宛先ポート 80
外部ソース IP アドレスの例(表示されていません) 62.35.1.1
ロードバランサの外部 IP アドレス 203.0.113.99
送信先プロジェクト myproject

ロードバランサへのテスト成功

このセクションでは、前述の外部 HTTP(S) ロードバランサに対するテスト成功の例について説明します。

実際のデータプレーンでは、負荷分散アルゴリズムがバックエンド接続ごとに VM インスタンスを選択します。この例には 3 つのロードバランサ バックエンドがあるため、[結果] 画面の [トレースの選択] メニューを使用すると、確認するトレースを選択できます。

Console

以下のテスト成功の結果により、次に挙げる外部 HTTP(S) ロードバランサ用のすべての Google Cloud リソースが正しく構成されていることが検証されます。

  • 転送ルール
  • ロードバランサ バックエンド。これには、ロードバランサがヘルスチェックをバックエンドに正常に送信できることも含まれます。
  • プロキシ接続
  • VPC ファイアウォール ルール

この結果により、外部 IP アドレスからのシミュレーション パケットがバックエンド VM インスタンスに正常に到達できることが表示されます。

3 つすべてのバックエンドに対するトレースの詳細な例については、無効な構成または整合性のない構成の検出をご覧ください。

外部 HTTP(S) ロードバランサへのテストが成功した場合の出力例
外部 HTTP(S) ロードバランサへのテストが成功した場合の出力例

外部 HTTP(S) ロードバランサのネットワーク パスにある Google Cloud リソースを確認する権限がない場合でも、テストの成功結果を含め、Cloud Console に結果が表示されます。ただし、テストされた各リソースのカードには、「PROJECT_NAME のリソースを表示する権限がありません」と表示されます。

ヘルスチェックに対するファイアウォール ルールの欠落を示すテスト

ロードバランサのトレースでは、前述と同じ Google Cloud リソース構成の多くが検証されます。ただし、次のロードバランサ リソースの構成が誤っている場合、分析結果としてパケットがドロップされる可能性があるが示されます(トレースの最終状態は Drop です)。

Console

次のテスト結果は、VPC ネットワークの上り(内向き)ファイアウォール ルールがロードバランサのバックエンドに対するヘルスチェックを許可していないため、バックエンドをロードバランサで利用できないようにしていることを示しています。

欠落しているファイアウォール ルールの出力例。
欠落しているファイアウォール ルールの出力例

無効な VPC ファイアウォール ルールに加え、接続テストにより検出される Google Cloud ロードバランサの一般的な構成の問題を次に示します。

これらの問題を解決するには、次の表に示す解決策を使用します。

構成の問題 解決策
入力パラメータが、ロードバランサの転送ルールで定義したプロトコルまたはポートと一致しない。 転送ルールで定義したプロトコルまたはポートに一致するように入力パラメータを変更した後、テストを実施します。
ロードバランサの転送ルールにバックエンドが構成されていない。 ロードバランサのバックエンドを構成した後、テストを実施します。
ロードバランサに無効な構成または整合性のない構成がある。 無効な構成または整合性のない構成を修正した後、テストを実施します。
内部 TCP / UDP ロードバランサがリージョン サービスのため、リージョンの一致しない内部 TCP / UDP ロードバランサにトラフィックが到達できない。 ロードバランサ コンポーネントを構成して、同じリージョンに配置されるようにした後、テストを実施します。

次のステップ