次のガイダンスを使用して、接続テストに関する一般的な問題のトラブルシューティングを行います。
接続テストの詳細については、概要をご覧ください。
接続テストの構成分析のステータスを確認するには、構成分析の状態をご覧ください。
一般的な問題
テスト結果を得るまでに時間がかかりすぎる
接続テストは Virtual Private Cloud（VPC）のネットワーク構成の最新のスナップショットを照会するため、結果の取得には時間がかかる場合があります。詳細については、予想されるクエリのレスポンス時間をご覧ください。
接続テストの実施中に長いレイテンシや不安定なレイテンシが発生している場合は、問題をサポートに報告し、再現方法を説明してください。
テストの構成分析で構成の変更が認識されない
テスト工程の中で Google Cloud リソースの構成を変更した後は、テストの構成分析を使用して変更を検証することをおすすめします。ただし、接続テストが構成の更新を受信して分析に組み込むまでには 20～120 秒を要します。構成を変更してからテストを実施するまでの間に、十分な待機時間を設けるようにしてください。
一部の構成では、完了するまでに時間がかかるタイプのものがあります。長い間、構成の変更が接続テストによって検証されず、再現可能な場合は、問題をサポートに報告し、再現方法を説明してください。
この遅延は、ダイナミック検証には当てはまりません。そのため、ダイナミック検証と構成分析によって表示された結果の間に、一時的に不整合が生じる場合があります。たとえば、ファイアウォール ルールを作成した場合、通常、ダイナミック検証は新しいルールに直ちに応答します。ただし、構成分析がファイアウォール ルールをテストパス内の他のリソースと一緒に評価するようになるまで、20 秒以上待たなければならない場合があります。
テストの状態の問題
階層型ファイアウォール ポリシーの詳細情報にアクセスできない
テストのトレースで、表示する権限がユーザーに付与されていない階層型ファイアウォール ポリシーが参照されている場合があります。
ただし、ポリシーの表示権限を付与されていない場合でも、VPC ネットワークに適用されるポリシールールを確認できます。詳細については、階層型ファイアウォール ポリシーの概要で有効になっているファイアウォール ルールをご覧ください。
階層型ファイアウォール ポリシーへのアクセスは、組織とフォルダレベルで定義されます。これらのポリシーを表示するのに必要な権限の詳細については、階層型ファイアウォール ポリシーの概要で Identity and Access Management（IAM）のロールをご覧ください。
構成分析で Deliver の最終状態が示されているが、接続が切断されている
構成分析で、送信元エンドポイントと宛先エンドポイントが到達可能であることが示されることもあります。ただし、実際には、この 2 つのエンドポイント間で接続が切断される場合や、ダイナミック検証によって 100% パケットロスが発生していることがあります。
このような状況を把握するために、接続テストでは構成分析とダイナミック検証という 2 種類の分析が使用されることに注意してください。前者がプロジェクト内のアクティブな構成の問題を検出し、後者がデータプレーンにプローブを送信します。
構成分析の最終状態が Deliver の場合、接続テストで構成の問題が検出されなかったことを意味します。ただし、接続の問題を引き起こす可能性のあるデータパスの問題が依然として存在する可能性があります。この問題を解決するには、次の点を考慮してください。
- 送信元 VM または宛先 VM でゲスト OS の問題が発生している。たとえば、ゲスト OS でカーネル パニックが発生した、ネットワーク インターフェース コントローラ（NIC）が初期化されていない、ネットワーク ドライバの互換性がない、などの問題が発生しています。VM の状態と NIC の構成を確認します。
- 広範囲にわたる問題がネットワーク データプレーンに影響を与えている。プロジェクトのパフォーマンス ダッシュボードをご覧ください。特に、関連するゾーンペアでパケットロスが発生していないかどうかに注意します。また、Google Cloud ステータス ダッシュボードも確認します。
- 特定の Google Cloud エンティティに対するネットワーク構成の伝播に問題があり、ネットワーク上でプログラミングの問題が発生している。5 分ほど待ってからテストを再実行します。問題が解決しない場合は、インスタンスの停止と起動の説明に沿って、送信元または宛先の VM を停止し起動してからテストを再実行します。
全体的な構成解析の分析結果で Undetermined が返された
全体的な到達性の結果が Undetermined の場合、構成分析で接続を判断できませんでした。この結果は、次のいずれかの理由で表示されます。
- 権限エラーが発生しています。たとえば、テストで指定されたすべてのリソースに対する読み取り権限がユーザーにない可能性があります。
- 内部エラーが発生しました。
- アナライザが無効な引数またはサポートされていない引数を受け取ったか、既知のエンドポイントを特定できませんでした。
- Google Cloud の外部にまたがるルートを確認しようとしています。接続テストは Google Cloud の外部にあるネットワーク構成にアクセスできません。
全体的な構成解析の分析結果で Ambiguous が返された
全体的な構成分析の結果が Ambiguous の場合、接続テストが複数のトレースを返し、最終状態が混在していることを意味します。
次の表に、この状態の一般的な理由と修正方法を示します。
| 理由 | 例 | 解消策 |
|---|---|---|
| ソースのロケーションが一意でない。 | IP アドレスが存在する VPC ネットワークも指定せずに内部ソース IP アドレスを指定しました（内部ソース IP アドレスは、インターネットからアクセスできないアドレスです）。このアドレスは複数の VPC ネットワークからアクセスできるため、接続テストは各ロケーションからトレースを開始する可能性があります。 | この IP アドレスが配置されている VPC ネットワークでテストを更新します。 |
| トレースに複数の可能な宛先が存在している | 複数のバックエンドがあり、すべてのバックエンドに到達できるわけではないロードバランサ VIP としてトレースの宛先を指定しました。 | 発生理由を調査し、テストを再実施する前に必要に応じて問題を修正してください。 |
全体的な構成分析のテスト結果が Abort で、Invalid Argument メッセージが返された
Invalid Argument メッセージの一般的な理由は次のとおりです。
- 指定した IP アドレスはサポートされていない。例として、ループバック アドレス、マルチキャスト IP アドレス、IPv4 アドレスのみが割り当てられている VM インスタンスへの IPv6 アドレスがあります。
- VM インスタンスまたは指定されたネットワークが存在しない。この状況は、テストの作成中に VM インスタンスまたは VPC ネットワークが削除された場合に発生する可能性があります。
Network Management API を使用する場合、通常、次のいずれかの理由で Invalid Argument メッセージが返されます。
- VM またはネットワーク URI の名前の誤りまたは場所が間違っている。
- プロジェクト ID が正しくない。このエラーは、プロジェクト ID ではなくプロジェクト名を使用した場合に発生します。
- 指定された内部 IP アドレスと選択されたネットワークの間の不一致。接続テスト用の Google Cloud コンソールは、指定された Compute Engine インスタンス、ネットワーク、プロジェクトについて厳密な検証を行いますが、このタイプの不一致が発生する可能性があります。
構成分析で Packet could not be delivered という結果が返されたが、ダイナミック検証ではすべてのパケットが配信されている
この不一致にはいくつかの理由が考えられます。次の原因と対処方法を検討してください。
最近の VPC ネットワーク構成の変更により、構成分析とアクティブなプローブの間で整合性がない可能性があります。テストを再実行し、可能であればテスト前またはテスト中にネットワーク構成が変わらないようにします。
Sporadic ネットワーク プログラミングの問題が発生しました。インスタンスの停止と起動の説明に沿って送信元または宛先の VM を停止し起動してからテストを再実行します。
構成分析の結果は Packet could be delivered であるが、ダイナミック検証では部分的なパケットロスが表示される
この不一致にはいくつかの理由が考えられます。考えられる原因と解決策は以下のとおりです。
送信 VM または宛先 VM が、許可されている下り（外向き）または上り（内向き）の帯域幅を超えたため、制限を受けています。[VM インスタンスの詳細] ページに移動し、[モニタリング] タブで詳細を確認して、VM のトラフィック ボリュームを分析します。ネットワーク バイトの指標を確認し、ネットワーク帯域幅のマシンタイプで説明されている帯域幅制限と比較します。
広範囲にわたる問題がネットワーク データプレーンに影響を与えている。プロジェクトのパフォーマンス ダッシュボードを確認します。特に、関連するゾーンペアに注意します。また、Google Cloud ステータス ダッシュボードも確認します。
構成分析の結果が Packet could be delivered であり、ダイナミック検証で完全な配信が示されるが、アプリケーションでは切断されている
この不一致にはいくつかの理由が考えられます。考えられる原因と解決策は以下のとおりです。
- ゲスト OS によってトラフィックがブロックされている可能性があります（内部ファイアウォール ルールなど）。トラフィックがブロックされていないことを確認してから、もう一度テストしてください。
- アプリケーション データパケットは、ダイナミック検証プローブとは異なるネットワーク パスを通過する場合があります。ネットワーク接続の再確立も検討してください。たとえば、別の送信元ポートを使用します。
- ダイナミック検証は一方向でパケットロスを検出します。その場合、リターンパスでパケットロスが発生している可能性があります。テストを反対方向で実行することを検討してください。
テスト結果にダイナミック検証の結果が含まれていない
接続テストでサポートされているすべての構成が動的に検証できるわけではありません。概要の説明に沿って、テストがダイナミック検証に必要な条件を満たすようにする必要があります。
Network Management API が INTERNAL_ERROR を返した
この問題は通常発生しません。実際に発生した場合は、問題をサポートに報告し、再現方法を説明してください。
Google Cloud コンソールに関する問題
接続テスト用の Google Cloud コンソールがクラッシュした
通常、Google Cloud コンソールはクラッシュしません。実際に発生した場合は、問題をサポートに報告し、再現方法を説明してください。
次のステップ
- ICMP の問題を特定して修正する（チュートリアル）