接続テストで、次のいずれかの理由によりテストパケットがドロップされることがあります。
考えられる理由の一覧については、構成分析の状態をご覧ください。
外部 IP アドレスは許可されません
IP 転送が有効になっている場合にのみ Compute Engine インスタンスが外部 IP アドレスを持つパケットを送受信できるため、パケットがドロップされます。
考えられる原因
VM インスタンスで IP 転送が有効になっていないが、それを通過するパケットの送信元 IP アドレスまたは宛先 IP アドレスがインスタンスの IP アドレスと一致しません。これは、VM インスタンスをネクストホップとする静的ルートを使用してパケットがインスタンスに配信された場合などです。
推奨事項
IP 転送が有効になっている Compute Engine インスタンスを作成するか、既存のインスタンスに対応する属性を設定します。詳細については、インスタンスに対する IP 転送の有効化をご覧ください。
ファイアウォール ルールによりドロップされた
接続トラッキングによりパケットが許可された場合を除き、ファイアウォール ルールによってパケットがドロップされることがあります。
考えられる原因
パケットがブロック ファイアウォール ルールまたはファイアウォール ポリシー ルールと一致するため、接続テストでテストパケットが拒否されている可能性があります。ただし、ファイアウォール ルールでの接続トラッキングにより、実際のデータプレーンではパケットが通過する可能性があります。既存の接続のパケットは、ファイアウォール ルールに関係なく、接続トラッキングによって戻されます。
すべての VPC ネットワークには、あらゆる場所への下り（外向き）トラフィックを許可し、あらゆる場所からの受信トラフィックをブロックする 2 つの暗黙のファイアウォール ルールがあります。優先度の高い下り（外向き）拒否ファイアウォール ルールを使用することもできます。
接続を成功させるには、宛先エンドポイントへのアクセスを許可する送信元の下り（外向き）ファイアウォール ルールと、接続を許可する宛先の上り（内向き）ファイアウォール ルールが必要です。
VPC ファイアウォール ルールはステートフルです。指定された宛先エンドポイントが通常通信を開始する側である場合、接続トラッキングによりレスポンス トラフィックが自動的に許可され、上り（内向き）ファイアウォール ルールは必要ありません。
推奨事項
接続テストの結果の詳細に基づいて、拒否ルールを削除するか、許可ルールを作成します。詳細については、ファイアウォール ポリシーと VPC ファイアウォール ルールの使用をご覧ください。
一致するルートがないためドロップされました
一致するルートがないため、パケットがドロップされます。
考えられる原因
パケット ネットワークとリージョンに、パケット属性（宛先 IP アドレスなど）に一致するアクティブなルートがない。
推奨事項
Google Cloud コンソールで適用されているルートのリストを確認します。新しいルートを作成したばかりの場合は、接続テストが構成の更新を受信して分析に組み入れるまでに時間がかかることがあります。
内部 IP アドレスを使用して宛先エンドポイントにアクセスしようとしている場合は、送信元ネットワークと宛先ネットワークが接続されていることを確認してください（例えば、VPC ネットワーク ピアリング、Network Connectivity Centerまたは Cloud VPN などのハイブリッド接続ソリューションを使用）。
推移的 VPC ピアリングはサポートされていません。ソース ネットワークと宛先ネットワークを直接接続するか、ハイブリッド接続ソリューションを使用することを検討してください。
インターネット経由で宛先エンドポイントにアクセスしようとしている場合は、ネクストホップ インターネット ゲートウェイを持つ宛先 IP アドレスのルートがあることを確認してください。
パケットがハイブリッド接続ネットワーク エンドポイント グループを通過する場合は、ルートの適用範囲に関する追加要件を検討してください。ルートビュー テーブルに表示される一部のルートは、ハイブリッド NEG からのトラフィックに使用できない場合があります。
パケットが間違ったネットワークに送信されている
パケットが意図しないネットワークに送信される。たとえば、network-1 ネットワークの Compute Engine インスタンスから network-2 ネットワークの Compute Engine インスタンスに対してテストを実行しますが、パケットは network-3 ネットワークに送信されます。
考えられる原因
network-1 ネットワークには、別のネットワークのネクストホップ（上記の例では network-3）を持つ宛先インスタンスの IP アドレスを含む、宛先範囲のルートがあります。
推奨事項
Google Cloud コンソールで、適用されているルートのリストと移行元インスタンスに適用されるルートのリストを確認します。ルートの作成と適用範囲の詳細については、ルートとルートの使用をご覧ください。
ルートのネクストホップ IP アドレスが解決されない
パケットは、ネクストホップ IP アドレスがどのリソースにも割り当てられていない無効なルートを使用して宛先に送信されます。
考えられる原因
これが next-hop-address を含むルートの場合、ネクストホップ アドレスは、プライマリ内部 IPv4 アドレスか、ルートの VPC ネットワーク内の Compute Engine インスタンスの IPv6 アドレスである必要があります。ピアリングされたネットワーク内のアドレスはサポートされません。
これが next-hop-ilb を含むルートの場合、ネクストホップ アドレスは、内部パススルー ネットワーク ロードバランサのアドレスである必要があります。（他のロードバランサ、プロトコル転送で使用される転送ルール、または Private Service Connect エンドポイントとして使用される転送ルールはサポートされていません）。IP アドレスは、ルートの VPC ネットワークまたは VPC ネットワーク ピアリングで接続されたネットワーク内のリソースに割り当てる必要があります。
推奨事項
ネクストホップ IP アドレスがサポートされているリソースに属していることを確認します。詳細については、ネクストホップ インスタンスに関する考慮事項と内部パススルー ネットワーク ロードバランサのネクストホップに関する考慮事項をご覧ください。
ルートのネクストホップ インスタンスに間違ったネットワークの NIC があります
パケットは、ネクストホップの Compute Engine インスタンスに、ルートのネットワークの NIC（ネットワーク インターフェース コントローラ）がない無効なルートを使用して、宛先に送信されます。
考えられる原因
ルートのネクストホップとして使用される Compute Engine インスタンスには、（ピアリングされた VPC ネットワークではなく）ルートのネットワーク内に NIC が必要です。
推奨事項
ネクストホップの Compute Engine インスタンスに、ルートのネットワークの NIC があることを確認します。詳しくは、ネクストホップ インスタンスに関する考慮事項をご覧ください。
ルートのネクストホップ アドレスが VM のプライマリ IP アドレスではありません
パケットは、ネクストホップ IP アドレス（next-hop-address）が Compute Engine インスタンスのプライマリ IP アドレスではない無効なルートを使用して宛先に送信されます。
考えられる原因
ルートのネクストホップ IP アドレス（next-hop-address）は、Compute Engine インスタンスのプライマリ内部 IPv4 アドレスである必要があります。エイリアス IP アドレス範囲はサポートされていません。
推奨事項
ネクストホップ IP アドレスが Compute Engine インスタンスのプライマリ内部 IPv4 アドレスであることを確認します。詳しくは、ネクストホップ インスタンスに関する考慮事項をご覧ください。
ルートのネクストホップ転送ルールのタイプが無効です
パケットは、ネクストホップ転送ルール（next-hop-ilb）が内部パススルー ネットワーク ロードバランサの転送ルールではない無効なルートを使用して宛先に送信されます。
考えられる原因
ルートのネクストホップ転送ルールは、内部パススルー ネットワーク ロードバランサの転送ルールである必要があります。詳細については、内部パススルー ネットワーク ロードバランサのネクストホップに関する考慮事項をご覧ください。
推奨事項
無効なルートではなく、サポートされている転送ルールをターゲットにしたルートを作成します。
インターネットへのプライベート トラフィック
内部の送信先アドレスを持つパケットがインターネット ゲートウェイに送信されました。
考えられる原因
パケットの宛先 IP アドレスがプライベート IP アドレスで、インターネット経由でアクセスすることはできません。ただし、パケットは送信元の Compute Engine インスタンスから送信され、ネクストホップのインターネット ゲートウェイとルートを照合します。
推奨事項
インターネット経由で宛先にアクセスする場合は、移行元の Compute Engine インスタンスがインターネットに接続していること（外部 IP アドレスがある、または Cloud NAT を使用していることなど）を確認します。そして、テストで宛先エンドポイントの外部 IP アドレスを使用します。
内部 IP アドレスを使用して宛先にアクセスする場合は、送信元ネットワークと宛先ネットワーク間の接続を確立（ルートを作成）する必要があります。これは、次のいずれかの方法で行うことができます。
- 宛先エンドポイントがオンプレミス ネットワーク内にある場合は、Network Connectivity Center ソリューションまたはハイブリッド接続ソリューションを使用します。例: Cloud VPN または Cloud Interconnect。
- 宛先エンドポイントが Google Cloud 内にある場合:
- VPC ネットワーク間の VPC ネットワーク ピアリングを構成します。
- VPC ネットワーク間に Cloud VPN を構成します。
- Network Connectivity Center の VPC スポークを使用してネットワーク接続を構成する。
すでに移行先のネットワークに接続している場合:
- 送信元エンドポイント ネットワークに、この接続を経由するルートがないか、インターネット ゲートウェイを経由するデフォルト ルートが使用されている。Google Cloud コンソールで適用されているルートのリストと移行元インスタンスに適用されるルートのリストを確認します。ルートの作成と適用範囲の詳細については、ルートとルートの使用をご覧ください。
ピアリング対象のネットワークからオンプレミス ネットワークへの接続をテストする場合は、カスタム アドバタイズ、ネットワーク ルーティング モード、カスタムルートの交換に関するこちらの例をご覧ください。
推移的 VPC ネットワーク ピアリングはサポートされていません。この 2 つの VPC ネットワークには VPN またはピアリングを使用できます。
限定公開の Google アクセスが許可されていません
内部 IP アドレスのみを持つ Compute Engine インスタンスは、Google API とサービスの外部 IP アドレスにアクセスしようとしますが、限定公開の Google アクセスがインスタンスのサブネットで有効になっていません。
推奨事項
次のいずれかの方法で、Compute Engine VM インスタンスが Google API とサービスの外部 IP アドレスにアクセスできるようにします。
- インスタンスのサブネットで限定公開の Google アクセスを有効にします。
- Compute Engine NIC に外部 IP アドレスを割り当てます。
- VM インスタンスのサブネットの Cloud NAT を有効にします。
VPN トンネルを介した限定公開の Google アクセスはサポートされていません
内部 IP アドレスを持つ送信元エンドポイントは、VPN トンネル経由で Google API とサービスの外部 IP アドレスに到達しようとしますが、送信元エンドポイント ネットワークで限定公開の Google アクセスを有効にする必要があります。
考えられる原因
送信元エンドポイントから Google API とサービスの外部 IP アドレスへのパケットは、Cloud VPN トンネル経由でルーティングされますが、このような構成はサポートされていません。
推奨事項
送信元エンドポイントが Google Cloud エンドポイント（Compute Engine VM インスタンスなど）の場合は、送信元サブネットで限定公開の Google アクセスを有効にすることを検討してください。
送信元エンドポイントがオンプレミス エンドポイントの場合は、オンプレミス ホスト用の限定公開の Google アクセスで詳しい手順をご覧ください。
転送ルールの不一致
転送ルールのプロトコルとポートがパケット ヘッダーと一致しません。
考えられる原因
パケットが、転送ルールでサポートされていないプロトコルを使用して送信されたか、転送ルールでサポートされているポートと一致しない宛先ポートに送信された。
推奨事項
宛先転送ルールのプロトコルとポートを確認します。
転送ルールのリージョンの不一致
転送ルールでグローバル アクセスが有効になっていません。そのリージョンがパケットのリージョンと一致しません。
考えられる原因
転送ルールは、ロードバランサとその階層に応じてグローバルまたはリージョンのいずれかになります。詳細については、ロードバランサの種類の表をご覧ください。
転送ルールがリージョンの場合は、クライアント（VM や VPC コネクタなど）はロードバランサと同じリージョンに配置する必要があります。
推奨事項
Compute Engine VM インスタンスなどの Google Cloud エンドポイントからロードバランサに接続している場合は、ロードバランサが転送ルールと同じリージョンに配置されていることを確認してください。
オンプレミス ネットワークから接続する場合は、クライアントがロードバランサと同じリージョンの Cloud VPN トンネルまたは VLAN アタッチメント経由でロードバランサにアクセスしていることを確認する必要があります。詳細については、内部ロードバランサと接続ネットワークをご覧ください。
内部アプリケーション ロードバランサとリージョン内部プロキシ ネットワーク ロードバランサでグローバル アクセスを有効にして、任意のリージョンのクライアントにアクセスできます。デフォルトでは、これらのロードバランサのクライアントは、ロードバランサと同じリージョンに存在する必要があります。詳細については、内部アプリケーション ロードバランサのグローバル アクセスを有効にするとリージョン内部プロキシ ネットワーク ロードバランサのグローバル アクセスを有効にするをご覧ください。
ファイアウォールをブロックするロードバランサのバックエンド ヘルスチェック
ファイアウォールによって、バックエンドに対するヘルスチェックのプローブがブロックされており、ロードバランサからのトラフィックがバックエンドに到達できなくなっています。
考えられる原因
ヘルスチェックを機能させるには、Google Cloud プローバーからのトラフィックがバックエンドに到達できるように、上り（内向き）許可ファイアウォール ルールを作成する必要があります。それ以外の場合、バックエンドは異常とみなされます。
推奨事項
プローブ IP 範囲とファイアウォール ルールの表に従って、上り（内向き）許可ファイアウォール ルールを作成します。詳細については、必要なファイアウォール ルールをご覧ください。
外部アドレスを使用できない
内部 IP アドレスのみを持つ VM インスタンスから、ネクストホップがデフォルトのインターネット ゲートウェイであるルート経由で外部ホストにアクセスしようとしました。この問題は、サブネットで Cloud NAT が有効になっていない場合、または別の種類のネクストホップ（プロキシ VM など）を使用するデフォルト ルートが他にない場合に発生する可能性があります。
考えられる原因
内部 IP アドレスのみを持つインスタンスが外部ホストにアクセスしようとしましたが、外部 IP アドレスがないか、Cloud NAT がサブネットで有効になっていません。
推奨事項
外部エンドポイントにアクセスする場合は、外部 IP アドレスをインスタンスに割り振ります。また、インターネットにアクセスできるプロキシ インスタンス経由で接続が通過する場合を除き、サブネットで Cloud NAT を有効にできます。
インスタンスのない転送ルール
転送ルールでバックエンドが構成されていません。
考えられる原因
アクセスしようとしている転送ルールにバックエンドが構成されていません。
推奨事項
ロードバランサの構成を確認し、ロードバランサのバックエンド サービスにバックエンドが構成されていることを確認します。
トラフィック タイプがブロックされている
トラフィック タイプがブロックされ、それを有効にするファイアウォール ルールを構成できません。詳細については、常にブロックされるトラフィックをご覧ください。
考えられる原因
このトラフィック タイプはデフォルトでブロックされており、ファイアウォール ルールを作成して有効にすることはできません。一般的なシナリオは次のとおりです。
- TCP ポート 25（SMTP）で外部宛先への下り（外向き）トラフィックを送信する。詳細については、常にブロックされるトラフィックをご覧ください。
- Cloud SQL インスタンスで、サポートされていないポートにトラフィックを送信する。たとえば、TCP ポート 3310 へのトラフィックを、ポート 3306 が開いている MySQL Cloud SQL インスタンスに送信する場合などです。
- TCP または UDP 以外のプロトコルを使用する App Engine スタンダード環境のバージョン、Cloud Functions の関数、または Cloud Run のリビジョンから、下り（外向き）トラフィックを送信する。
推奨事項
下り（外向き）SMTP トラフィック（TCP ポート 25 での外部下り（外向き）トラフィック）については、インスタンスからのメールの送信をご覧ください。
宛先ポート 68 への UDP IPv4 パケット（DHCPv4 レスポンス）と宛先ポート 546 への UDP IPv6 パケット（DHCPv6 レスポンス）などの DHCP プロトコルの場合、DHCP トラフィックはメタデータ サーバー（169.254.169.254）からのみ許可されます。
Cloud SQL 接続の場合は、使用するポートが正しいことを確認します。
サーバーレス VPC アクセス コネクタが構成されていない
App Engine スタンダード環境のバージョン、Cloud Functions の関数、または Cloud Run のリビジョンにサーバーレス VPC アクセス コネクタが構成されていないため、パケットがドロップされました。
考えられる原因
宛先 IP アドレスがプライベート IP アドレスで、インターネット経由でアクセスすることはできません。パケットは送信元から送信されますが、App Engine スタンダード環境のバージョン、Cloud Functions の関数、Cloud Run のリビジョンにサーバーレス VPC アクセス コネクタが構成されていません。
推奨事項
プライベート IP アドレスを使用して宛先のエンドポイントにアクセスしようとしている場合は、App Engine スタンダード環境のバージョン、Cloud Functions の関数、または Cloud Run のリビジョンにサーバーレス VPC アクセス コネクタが構成されていることを確認してください。
サーバーレス VPC アクセス コネクタが実行されていない
サーバーレス VPC アクセス コネクタが実行されていないため、パケットがドロップされました。
考えられる原因
すべてのサーバーレス VPC アクセス コネクタ インスタンスが停止しているため、パケットが破棄されています。
推奨事項
トラブルシューティングの手順については、トラブルシューティングをご覧ください。
Private Service Connect の接続が受け入れられない
Private Service Connect の接続が受け入れられなかったため、パケットがドロップされました。
考えられる原因
Private Service Connect エンドポイントが、サービスへの接続を承認されていないプロジェクトにあります。詳細については、エンドポイントの詳細を表示するをご覧ください。
推奨事項
Private Service Connect エンドポイントが、マネージド サービスへの接続を承認されたプロジェクトにあることを確認します。
Private Service Connect エンドポイントがピアリングされたネットワークからアクセスされる
パケットは、ピアリングされたネットワーク内の Private Service Connect エンドポイントに送信されますが、このような構成はサポートされていません。
推奨事項
Private Service Connect のデプロイ パターンで説明されている接続パターンのいずれかの使用を検討してください。Private Service Connect バックエンドを使用して、Google API と公開サービスにアクセスすることもできます。