接続テストで、次のいずれかの理由によりテストパケットがドロップされることがあります。
考えられる理由の一覧については、構成分析の状態をご覧ください。
外部 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 と公開サービスにアクセスすることもできます。