Apigee でのアクセスルーティングの問題

現在、Apigee と Apigee ハイブリッドのドキュメントを表示しています。
このトピックに対応する Apigee Edge のドキュメントはありません。

症状

外部クライアントが適切な方法で Apigee にアクセスできない、または Apigee に接続できないこれには、ネットワーク接続の失敗（TLS handshake の失敗）または Apigee からの 4xx/5xx レスポンスが含まれます。

エラーメッセージ

クライアントから Apigee に API リクエストを送信すると、Apigee UI で API プロキシが正常であるように見える場合でも、TLS handshake の失敗または 4xx/5xx レスポンスが表示されます。

考えられる原因

原因	説明	エラーコード
HTTPS ロードバランサでの TLS エラー	HTTPS ロードバランサの TLS 構成を管理します。HTTPS ロードバランサのログで TLS エラーを調査します。	ロードバランサの IP アドレスからの TLS handshake エラー
Google Cloud Armor がリクエストをブロックしている	Google Cloud Armor を使用している場合は、ルールでリクエストがブロックされる可能性があります。	API レスポンスコードは、Google Cloud Armor の構成によって異なる場合があります。拒否ルールから `HTTP 403`（未承認）、`404`（アクセス拒否）、`502`（不正なゲートウェイ）のレスポンス、あるいは別のレスポンスコードが返されることができます。
Apigee プロキシ VM が Apigee インスタンスにトラフィックを転送できない	Apigee API トラフィックルータープロキシの構成とその健全性を調査する必要があります。	`502 Server Error`
ネットワーク構成が正しくない	正しいネットワークが Apigee VPC とピアリングされていることを確認します。	`502 Server error`
リージョン拡張の一部として作成された新しい Apigee インスタンス上の非接続環境	新しいインスタンス（2 番目のリージョンなど）を作成したら、環境を接続する必要があります。そうしないと、API リクエストに応答できません。	`503 error response`

原因: HTTPS ロードバランサでの TLS エラー

診断

ロードバランサに関連付けられている TLS 証明書を探します。

Google Cloud コンソールを使用する場合:
1. Google Cloud コンソールで、[ロードバランシング] ページに移動します。
  
  [ロードバランシング] に移動
2. ロードバランサの名前をクリックします。[ロードバランサの詳細] ページが開きます。
3. [フロントエンド] 領域の [IP:ポート] 列で、IP アドレスとポートを確認して、正しいロードバランサが表示されていることを確認します。
4. [証明書] 列で、証明書名をクリックして TLS 証明書を表示します。

gcloud コマンドを使用する場合:

次の gcloud コマンドでロードバランサの一覧を取得します。このコマンドを実行すると、各ロードバランサに関連付けられている SSL_CERTIFICATES も表示されます。
```
gcloud compute target-https-proxies list --project=PROJECT_NAME
```
PROJECT_NAME は、実際のプロジェクト名で置き換えます。

次のような内容が返されます。
```
NAME: example-proxy-https-proxy
SSL_CERTIFICATES: example-ssl-cert
URL_MAP: example-proxy-url-map
REGION:
CERTIFICATE_MAP: 
```

次の gcloud コマンドで TLS 証明書を表示します（

jq

または同様のツールがマシンにインストールされていることを前提としています）。

gcloud compute ssl-certificates describe CERTICATE_NAME \
--project PROJECT_NAME --format json | jq -r '.certificate' | openssl x509 -text -noout

CERTIFICATE_NAME は、証明書名に置き換えます。例: example-ssl-cert

次のような内容が返されます。

certCertificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            51:3b:a4:60:fe:49:34:a2:09:af:14:85:96:a2:4f:d9
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Google Trust Services LLC, CN = GTS CA 1D4
        Validity
            Not Before: Jul 11 11:51:52 2023 GMT
            Not After : Oct  9 12:44:45 2023 GMT
        Subject: CN = 34.149.207.105.nip.io
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                .
                .

                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                A5:DB:7C:6A:8B:0B:7A:22:45:52:1E:85:29:32:77:18:A3:9D:87:76
            X509v3 Authority Key Identifier:
                keyid:25:E2:18:0E:B2:57:91:94:2A:E5:D4:5D:86:90:83:DE:53:B3:B8:92

            Authority Information Access:
                OCSP - URI:http://ocsp.pki.goog/s/gts1d4/qMhEcTt7LjA
                CA Issuers - URI:http://pki.goog/repo/certs/gts1d4.der

            X509v3 Subject Alternative Name:
                DNS:34.149.207.105.nip.io
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.11129.2.5.3

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crls.pki.goog/gts1d4/LjtNmxrQfWE.crl

証明書の共通名（CN）が [Apigee] > [Admin] > [Environments] > [Groups] で構成されたホスト名と一致することを確認します。証明書が有効で、期限切れになっていないことを確認します。これらのチェックは、openssl で実行できます。

ロードバランサから返された TLS 証明書を確認するには、クライアントマシンから次の openssl コマンドを実行します。証明書が上記の手順 1 で返された証明書と一致するかどうかを確認します。
```
openssl s_client -connect LB_HOSTNAME_OR_IP:443 -servername LB_HOSTNAME -showcerts
```
次のように置き換えます。
- LB_HOSTNAME_OR_IP: ロードバランサのホスト名または IP アドレス。例: my-load-balancer
- LB_HOSTNAME: ロードバランサのホスト名。たとえば、my-hostname のようにします。
証明書が一致していることを確認するには、クライアントから次のコマンドを実行します。
```
echo | openssl s_client -connect HOST_NAME:443 -servername HOST_NAME | openssl x509 -noout -text | openssl md5
```
HOST_NAME は、Apigee（[Admin] > [Environments] > [Groups]）で構成されているホスト名に置き換えます。

次に、次の gcloud コマンドを実行して、md5 が一致していることを確認します。
```
gcloud compute ssl-certificates describe CERTIFICATE_NAME --project PROJECT_NAME --format json | jq -r '.certificate' | openssl x509 -noout -text | openssl md5
```
CERTIFICATE_NAME は、証明書の名前に置き換えます。例: my-certificate
ステップ 1 とステップ 2 の証明書が一致する場合（例: md5 値が一致）、クライアントサイドで packet capture を収集し TLS handshake の失敗を調査します。Wireshark、tcpdump またはその他の信頼性の高いツールを使用して、クライアントサイドでパケットキャプチャを行うことができます。
既存のバックエンドサービスでロギングを有効にするの手順に沿って、ロードバランサでログを有効にします。
ロードバランサのログでエラーを確認します。

解決策

ロードバランサのセルフマネージド証明書が期限切れになっているか、CN / SAN 値が正しくない場合は、ロードバランサの証明書を置き換える必要があります。
ステップ 1 のロードバランサから返された証明書とステップ 2 の証明書が一致しない場合、ロードバランサが古い証明書または正しくない証明書を提供している可能性があり、Google Cloud カスタマーケアにチケットを送信する必要があります。
tcpdump が TLS handshake の失敗を示している場合は、接続の失敗がロードバランサからのものか、クライアントサイドからのものかを調査します。
- エラーや接続のリセットがクライアントサイドからのものである場合は、クライアントアプリケーションをチェックして、誤動作の原因を突き止めてください。たとえば、クライアントサイドのネットワーク構成をチェックするか、クライアントアプリケーションが Apigee に接続していることを確認します。
- ロードバランサ自体で障害やリセットが発生した場合は、接続に関する一般的な問題のトラブルシューティングをご覧ください。また、必要に応じて Google Cloud カスタマーケアにチケットを送信してください。
ロードバランサのログにエラーが見つかった場合は、説明のない 5XX エラーをご覧ください。また、必要に応じて Google Cloud カスタマーケアにチケットを送信してください。

さらにサポートが必要な場合は、診断情報の収集が必要な場合をご覧ください。

原因: Cloud Armor がリクエストをブロックしている

診断

Cloud Armor の構成に基づいて 403、404、502 のいずれかのエラーレスポンスが表示される場合は、ロードバランサと MIG が正しく構成されて、正常な状態になっていることを確認します。

Google Cloud 環境で Google Cloud Armor を使用している場合は、Google Cloud Armor の構成を調べて、リクエストをブロックしている可能性のあるルールがないか確認します。セキュリティポリシーは、Google Cloud Armor セキュリティポリシーを構成するで確認できます。
トラフィックを拒否しているルールがわからない場合は、既存のバックエンドサービスでロギングを有効にするの説明に従って、ロードバランサでロギングを有効にすることを検討してください。
ロギングを有効にしたら、ログクエリを実行して、Google Cloud Armor ポリシーによってブロックされたリクエストを特定します。
1. Google Cloud コンソールで、[ログエクスプローラ] ページに移動します。
  
  [ログエクスプローラ] に移動
2. 次の内容を [クエリ] ペインに貼り付けます。
```
jsonPayload.enforcedSecurityPolicy.outcome="DENY"
```
3. [クエリを実行] をクリックします。
4. 適用されたポリシーの名前が [クエリ結果] ペインの jsonPayload.enforcedSecurityPolicy.name に表示されます。

解決策

この問題を解決するために、Google Cloud Armor のルールや構成をニーズに合わせて変更します。サポートが必要な場合は、Google Cloud カスタマーケアまでお問い合わせください。

原因: Apigee プロキシ VM が Apigee インスタンスにトラフィックを転送できない

診断

API クライアントが次のエラーメッセージで HTTP 502 エラーを受け取った場合は、Apigee API トラフィックルータープロキシ VM が異常な状態にある可能性があります。

次のような 502 エラーがクライアントに受信されることがあります。
```
<html><head> <meta http-equiv="content-type"
  content="text/html;charset=utf-8"> <title>502 Server Error</title> </head>
  <body text=#000000 bgcolor=#ffffff> <h1>Error: Server Error</h1> <h2>The
  server encountered a temporary error and could not complete your
  request.<p>Please try again in 30 seconds.</h2> <h2></h2> </body></html>
```
ロードバランサのログで、次のようなエラーメッセージを確認します。
```
statusDetails: "failed_to_pick_backend"
severity: "WARNING"
```
マネージドインスタンスグループ（MIG）で実行されている VM のセット（apigee-proxy 接頭辞付き）があり、トラフィックを Apigee インスタンスに転送しています。このようなメッセージが表示された場合は、次の手順でインスタンスグループの apigee-proxy VM 部分の正常性を確認してください。
1. Google Cloud コンソールで、[ロードバランシング] ページに移動します。
  
  [ロードバランシング] に移動
2. ロードバランサの名前をクリックします。[ロードバランサの詳細] ページが開きます。
3. [バックエンド] セクションの「正常」列で、すべてのロードバランサのバックエンドに緑色のチェックマークが表示されていることを確認します。
MIG テンプレートのエンドポイント IP アドレスが Apigee インスタンスの IP アドレスと一致していることを確認します。

apigee-proxy VM は、インスタンステンプレートを使用して作成されます。このテンプレートは、Apigee インスタンスの IP アドレスに接続するための ENDPOINT IP アドレスを定義します。
1. Apigee インスタンスの IP アドレスを取得します。
```
curl -s -H "Authorization: Bearer (gcloud auth print-access-token)" \
"https://apigee.googleapis.com/v1/organizations/ORG_NAME/instances/INSTANCE_NAME"
```
  次のように置き換えます。
  - ORG_NAME: 組織の名前。たとえば、my-org のようにします。
  - INSTANCE_NAME: インスタンスの名前。たとえば、apigee-proxy-example のようにします。
2. または、Apigee UI を使用して Apigee インスタンスの IP アドレスを取得します。
  1. Apigee UI で、[Admin] > [Instances] をクリックします。
  2. [IP addresses] 列に IP アドレスが表示されます。
3. テンプレートから ENDPOINT IP アドレスを取得します。
  1. Google Cloud コンソールで、[ロードバランシング] ページに移動します。
    
    [ロードバランシング] に移動
  2. ロードバランサの名前をクリックします。[ロードバランサの詳細] ページが開きます。
  3. [バックエンド] 領域で、バックエンドサービス名をクリックします。
  4. [インスタンスグループのメンバー] 領域で、[テンプレート] の名前をクリックします。
  5. テンプレートページで、[カスタムメタデータ] までスクロールします。ここで、エンドポイントの IP アドレスが表示されます。
エンドポイントの IP アドレスが、ステップ 2 で返された Apigee IP アドレスと一致していることを確認します。一致しない場合は、解決策に進みます。

解決策

インスタンスグループ内の apigee-proxy VM に異常ステータスが表示される場合、ロードバランシング IP アドレス範囲 130.211.0.0/22 と 35.191.0.0/16 に MIG へのアクセスを許可するファイアウォールルールが設定されていることを確認します。
Google Cloud コンソールで [ファイアウォール] ページに移動します。

[ファイアウォール] に移動
gke-apigee-proxy のような target-tag が設定され、送信元 IP 範囲に 443 TCP ポート経由の 130.211.0.0/22、35.191.0.0/16 が含まれている Ingress ファイアウォールルールが存在することを確認します。

MIG に gke-apigee-proxy とは異なるタグがある場合は、タグがファイアウォールルールの target-tag に追加されていることを確認してください。

ファイアウォールルールが存在しない場合は、追加します。
エンドポイント IP アドレスが Apigee インスタンスの IP アドレスと一致しない場合は、インスタンスが削除されて再作成されるため、テンプレートの IP アドレスと一致しなくなる可能性があります。新しい IP アドレスを使用するようにテンプレートを更新するには、インスタンス IP の変更の説明に従ってください。

原因: ネットワーク構成が正しくない

診断

次の API 呼び出しを実行して、authorizedNetwork の値を見つけます。

curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/ORG_NAME"

次のような内容が返されます。

{
  "name": "apigee-example-org",
  "createdAt": "1621287579456",
  "lastModifiedAt": "1674063833580",
  "environments": [
    "test"
  ],
  "properties": {
    "property": [
      {
        "name": "features.mart.connect.enabled",
        "value": "true"
      },
      {
        "name": "features.hybrid.enabled",
        "value": "true"
      }
    ]
  },
  "analyticsRegion": "us-west1",
  "authorizedNetwork": "default",
  "runtimeType": "CLOUD",
  "subscriptionType": "PAID",
  "caCertificate": "certificate-number",
  "runtimeDatabaseEncryptionKeyName": "projects/apigee-example-org/locations/us-west1/keyRings/my-database-key-ring/cryptoKeys/my-database-key",
  "projectId": "apigee-example-org",
  "state": "ACTIVE",
  "billingType": "SUBSCRIPTION",
  "addonsConfig": {
    "advancedApiOpsConfig": {},
    "integrationConfig": {},
    "monetizationConfig": {}
  },
  "apigeeProjectId": "l09587a43efde330cp-tp"
}

この例では、authorizedNetwork の値がデフォルトです。

authorizedNetwork 値が servicenetworking とピアリングされているネットワークと同じであることを確認します。
1. ホストプロジェクトの Google Cloud コンソールで、[VPC ネットワークピアリング] ページに移動します。
  
  [VPC ネットワークピアリング] に移動
2. [VPC ネットワーク] の servicenetworking-googleapis-com に表示される値は、API 呼び出しから返された値と同じである必要があります。例: default
共有 VPC を使用している場合は、authorizedNetwork 値が servicenetworking とピアリングされているホストプロジェクトの実際の VPC の値になっていることを確認します。
1. Google Cloud コンソールで、[共有 VPC] ページに移動します。
  
  [共有 VPC] に移動
2. ホストプロジェクトを選択します。
3. [VPC ネットワーク] の servicenetworking-googleapis-com に表示される値は、API 呼び出しから返された authorizedNetwork 値と同じである必要があります。たとえば、default のようにします。
ロードバランサに関連付けられたインスタンスグループが authorizedNetwork 値と同じネットワークであることを確認します。
1. Google Cloud コンソールで、[ロードバランシング] ページに移動します。
  
  [ロードバランシング] に移動
2. ロードバランサ名をクリックします。[ロードバランサの詳細] ページが開きます。インスタンスグループのリストが [バックエンド] 領域に表示されます。
3. インスタンスグループの名前をクリックします。インスタンスグループの [概要] ページが表示されます。
4. [詳細] タブをクリックします。
5. [ネットワーキング] セクションまでスクロールします。
6. [プライマリネットワーク] が authorizedNetwork の値と同じであることを確認します。例: default
7. [概要] タブをクリックします。
8. [インスタンスグループのメンバー] セクションで、インスタンスの名前をクリックします。[詳細] ページが表示されます。
9. [ネットワークインターフェース] セクションまでスクロールします。
10. [ネットワーク] の値が authorizedNetwork の値と同じであることを確認します。例: default
11. [概要] タブに移動し、[インスタンスグループのメンバー] セクションのすべてのインスタンスでステップ h～ステップ j を繰り返します。

解決策

ステップ 2 またはステップ 3 のいずれかで、authorizedNetwork 値が servicenetworking とピアリングされたネットワークと同じでない場合、ステップ 4: サービスネットワーキングを構成するの手順に沿って操作し、servicenetworking で正しい VPC ネットワークとピアリング済みであることを確認します。
ステップ 4f と 4j でネットワーク値が authorizedNetwork 値と同じでない場合は、authorizedNetwork が servicenetworking. でピアリングされたネットワークであることを確認します。正しくピアリングされ、ネットワークが authorizedNetwork, と同じでない場合は、インスタンスグループが正しく作成されていないことを意味しますので、Google Cloud カスタマーケアにお問い合わせください。

原因: リージョン拡張の一部として作成された新しい Apigee インスタンスの非接続環境

診断

クライアントサイドで 503 エラーが表示されています。次に例を示します。
```
HTTP/2 503
date: Thu, 08 Jun 2023 07:22:15 GMT
content-length: 0
via: 1.1 google
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
```
注: リクエストがランタイム Message Processor に到達しないため、この 503 エラーはデバッグトレースには表示されません。
リージョン拡張の直後に 2 番目のリージョンで 503 エラーが発生した場合:
1. 次の API 呼び出しを実行して、環境が新しいインスタンスに接続していることを確認します。
```
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/ORG_NAME/instances/NEW_INSTANCE/attachments"
```
  次に例を示します。
```
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/apigee-example-org/instances/apigee-proxy-example/attachments"
```
  次のような内容が返されます。
```
{
  "attachments": [
    {
      "name": "9ed157df-5ef2-4cdc-b1d5-2643b480eb33",
      "environment": "dev",
      "createdAt": "1628153855420"
    },
    {
      "name": "a9e04dff-4ca4-4749-902f-5058e28c26a5",
      "environment": "prod",
      "createdAt": "1664517347106"
    }
  ]
}
```
  この例では、apigee-proxy-example という名前のインスタンスが dev と prod の 2 つの環境に接続しています。
2. 2 番目のリージョンのマネージドインスタンスグループ（MIG）が作成され、正常な状態になっていることを確認します。
  1. Google Cloud コンソールで、[ロードバランシング] ページに移動します。
    
    [ロードバランシング] に移動
  2. ロードバランサの名前をクリックします。[ロードバランサの詳細] ページが開きます。
  3. [バックエンド] に 2 つの MIG が表示されます。1 つはリージョン 1 用、もう 1 つはリージョン 2 用です。両方が正常であることを確認します。
  4. Apigee プロキシ VM が Apigee インスタンスにトラフィックを転送できないの手順に沿って、2 番目の MIG を検証します。

解決策

新しいインスタンスが環境に接続されていない場合は、新しいインスタンスに環境を接続するの手順に沿ってインスタンスを環境に接続します。

また、ロードバランサが、環境に接続している正しいバックエンドにリクエストを転送するようにする方法もあります。たとえば、非本番環境の場合です。1 つのリージョンだけに接続することもできますが、ロードバランサが誤ったリージョンにリクエストをルーティングしている可能性があります。ロードバランサの構成を更新して、正しいリージョンにルーティングされるようにする必要があります。
MIG が異常な場合は、Apigee プロキシ VM が Apigee インスタンスにトラフィックを転送できないの診断と解決策をご覧ください。

診断情報の収集が必要な場合

上記の手順でも問題が解決しない場合は、次の診断情報を収集して Google Cloud カスタマーケアに連絡してください。

Apigee 組織
問題が生じている環境と API プロキシ
ダウンロードしたデバッグセッション（問題が断続的に発生する場合）
失敗したリクエストの冗長な curl 出力。
API 呼び出しを Apigee に送信するように構成されたロードバランサ