Masalah pemilihan rute akses dengan Apigee

Anda sedang melihat dokumentasi Apigee dan Apigee Hybrid.
Tidak ada dokumentasi Apigee Edge yang setara untuk topik ini.

Gejala

Dalam beberapa kasus, klien eksternal tidak dapat mengakses/terhubung ke Apigee dengan cara yang diinginkan. Hal ini mencakup kegagalan konektivitas jaringan (TLS handshake gagal) atau respons 4xx/5xx dari Apigee.

Pesan error

Saat mengirim permintaan API dari Klien ke Apigee, Anda melihat kegagalan handshake TLS atau respons 4xx/5xx meskipun proxy API mungkin tampak berfungsi dengan baik di UI Apigee.

Kemungkinan penyebab

Penyebab	Deskripsi	Kode error
Error TLS di load balancer HTTPS	Anda mengelola konfigurasi TLS load balancer HTTPS. Selidiki error TLS di log load balancer HTTPS.	Error handshake TLS dari alamat IP load balancer
Google Cloud Armor memblokir permintaan	Jika Anda menggunakan Google Cloud Armor, mungkin ada aturan yang memblokir permintaan.	Kode respons API dapat bervariasi berdasarkan konfigurasi Google Cloud Armor. Aturan penolakan dapat menampilkan respons `HTTP 403` (Tidak Sah), `404` (Akses Ditolak), atau `502` (Bad Gateway) atau bahkan kode respons lain.
VM proxy Apigee tidak dapat meneruskan traffic ke instance Apigee	Konfigurasi proxy perute traffic API Apigee dan kondisinya perlu diselidiki	`502 Server Error`
Konfigurasi jaringan yang salah	Pastikan jaringan yang benar di-peering dengan VPC Apigee.	`502 Server error`
Lingkungan yang tidak terlampir pada instance Apigee baru yang dibuat sebagai bagian dari perluasan wilayah	Setelah membuat instance baru, misalnya region kedua, Anda harus melampirkan lingkungan ke instance tersebut, atau instance tidak dapat merespons permintaan API.	`503 error response`

Penyebab: Error TLS di load balancer HTTPS

Diagnosis

Temukan sertifikat TLS yang terkait dengan load balancer.

Menggunakan Konsol Google Cloud:
1. Di konsol Google Cloud , buka halaman Load balancing.
  
  Buka load balancing
2. Klik Name load balancer. Halaman Load balancer details akan terbuka.
3. Di area Frontend, di kolom IP:Port, pastikan Anda melihat load balancer yang tepat dengan memverifikasi alamat IP dan port-nya.
4. Di kolom Sertifikat, klik nama sertifikat untuk melihat sertifikat TLS.

Menggunakan perintah gcloud:

Tampilkan daftar load balancer dengan perintah gcloud berikut. Perintah ini juga menampilkan SSL_CERTIFICATES yang terkait dengan setiap load balancer.
```
gcloud compute target-https-proxies list --project=PROJECT_NAME
```
Ganti PROJECT_NAME dengan nama project Anda.

Sesuatu yang mirip dengan berikut akan ditampilkan:
```
NAME: example-proxy-https-proxy
SSL_CERTIFICATES: example-ssl-cert
URL_MAP: example-proxy-url-map
REGION:
CERTIFICATE_MAP: 
```

Lihat sertifikat TLS dengan perintah gcloud berikut (ini mengasumsikan Anda telah menginstal

jq

atau alat serupa di komputer Anda):

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

Ganti CERTIFICATE_NAME dengan nama sertifikat. Contoh, example-ssl-cert.

Sesuatu yang mirip dengan berikut akan ditampilkan:

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

Pastikan nama umum (CN) dalam sertifikat cocok dengan Nama Host yang dikonfigurasi di Apigee > Admin > Environment > Groups. Pastikan sertifikat valid dan masa berlakunya belum habis. Anda dapat menggunakan openssl untuk melakukan pemeriksaan ini.

Untuk memeriksa sertifikat TLS yang ditampilkan oleh load balancer, jalankan perintah openssl berikut dari mesin klien Anda. Periksa apakah sertifikat ini cocok dengan sertifikat yang ditampilkan di langkah 1 di atas.
```
openssl s_client -connect LB_HOSTNAME_OR_IP:443 -servername LB_HOSTNAME -showcerts
```
Ganti kode berikut:
- LB_HOSTNAME_OR_IP: nama host atau alamat IP load balancer. Contoh, my-load-balancer.
- LB_HOSTNAME: nama host load balancer. Misalnya, my-hostname.
Untuk memverifikasi bahwa sertifikat cocok, jalankan perintah berikut dari klien Anda:
```
echo | openssl s_client -connect HOST_NAME:443 -servername HOST_NAME | openssl x509 -noout -text | openssl md5
```
Ganti HOST_NAME dengan nama host yang dikonfigurasi di Apigee (Admin > Environments > Groups).

Kemudian, verifikasi bahwa md5 cocok dengan menjalankan perintah gcloud berikut:
```
gcloud compute ssl-certificates describe CERTIFICATE_NAME --project PROJECT_NAME --format json | jq -r '.certificate' | openssl x509 -noout -text | openssl md5
```
Ganti CERTIFICATE_NAME dengan nama sertifikat. Misalnya, my-certificate
Jika sertifikat langkah 1 dan langkah 2 cocok (yaitu, jika nilai md5 cocok), lanjutkan pengumpulan packet capture di sisi klien untuk menyelidiki kegagalan handshake TLS. Anda dapat mengambil rekaman paket di sisi klien dengan alat seperti Wireshark, tcpdump atau alat andal lainnya.
Aktifkan log di load balancer dengan mengikuti petunjuk di Mengaktifkan logging di layanan backend yang ada.
Tinjau log load balancer untuk menemukan error.

Resolusi

Jika sertifikat yang dikelola sendiri di load balancer sudah tidak berlaku atau memiliki nilai CN/SAN yang salah, Anda mungkin perlu mengganti sertifikat di load balancer.
Jika sertifikat yang ditampilkan oleh load balancer pada langkah 1 dan sertifikat pada langkah 2 tidak cocok, berarti load balancer mungkin menyajikan sertifikat yang sudah tidak berlaku/salah, dan Anda harus mengajukan tiket ke Dukungan Pelanggan Google Cloud.
Jika tcpdump menunjukkan kegagalan TLS handshake, selidiki apakah kegagalan koneksi berasal dari load balancer atau dari sisi klien.
- Jika kegagalan atau reset koneksi berasal dari sisi klien, periksa aplikasi klien Anda untuk memahami penyebabnya. Misalnya, Anda dapat memeriksa konfigurasi jaringan di sisi klien atau memverifikasi bahwa aplikasi klien memiliki konektivitas dengan Apigee.
- Jika Anda melihat kegagalan/reset dari load balancer itu sendiri, lihat Memecahkan masalah konektivitas umum dan ajukan tiket ke Google Cloud Customer Care jika diperlukan.
Jika Anda melihat error di log load balancer, lihat Error 5XX yang tidak dapat dijelaskan dan ajukan tiket ke Customer Care Google Cloud jika diperlukan.

Jika Anda masih memerlukan bantuan, lihat Harus mengumpulkan informasi diagnostik.

Penyebab: Cloud Armor memblokir permintaan

Diagnosis

Jika Anda melihat respons error 403, 404, atau 502 berdasarkan konfigurasi Cloud Armor, tinjau konfigurasi load balancer dan MIG untuk memverifikasi bahwa keduanya dikonfigurasi dengan benar dan terlihat dalam kondisi baik.

Jika Anda menggunakan Google Cloud Armor di lingkungan Google Cloud , tinjau konfigurasi Google Cloud Armor untuk mengetahui aturan yang mungkin memblokir permintaan. Kebijakan keamanan dapat ditemukan di Mengonfigurasi kebijakan keamanan Google Cloud Armor.
Jika tidak yakin aturan mana yang menolak traffic, Anda dapat mencoba mengaktifkan logging di load balancer seperti yang dijelaskan dalam Mengaktifkan logging di layanan backend yang ada.
Setelah logging diaktifkan, jalankan kueri log untuk menemukan permintaan yang diblokir oleh kebijakan Google Cloud Armor:
1. Di konsol Google Cloud , buka halaman Logs Explorer.
  
  Buka Logs Explorer
2. Tempel perintah berikut ke panel Query:
```
jsonPayload.enforcedSecurityPolicy.outcome="DENY"
```
3. Klik Run query.
4. Nama kebijakan yang diterapkan ditampilkan di jsonPayload.enforcedSecurityPolicy.name di panel Query results:

Resolusi

Ubah aturan/konfigurasi Google Cloud Armor agar sesuai dengan kebutuhan Anda untuk menyelesaikan masalah ini. Jika Anda memerlukan bantuan terkait hal ini, hubungi Google Cloud Customer Care.

Penyebab: VM proxy Apigee tidak dapat meneruskan traffic ke instance Apigee

Diagnosis

Jika klien API menerima error HTTP 502 dengan pesan error berikut, VM proxy perute traffic API Apigee mungkin dalam kondisi tidak sehat.

Error 502 seperti berikut dapat diterima oleh klien:
```
<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>
```
Tinjau log load balancer untuk melihat apakah ada pesan error seperti berikut:
```
statusDetails: "failed_to_pick_backend"
severity: "WARNING"
```
Ada serangkaian VM (dengan awalan apigee-proxy) yang berjalan dalam grup instance terkelola (MIG) yang meneruskan traffic ke instance Apigee. Jika Anda melihat pesan seperti di atas, periksa kesehatan apigee-proxy VM yang merupakan bagian dari grup instance melalui langkah-langkah berikut:
1. Di konsol Google Cloud , buka halaman Load balancing.
  
  Buka load balancing
2. Klik Name load balancer. Halaman Load balancer details akan terbuka.
3. Di bagian Backend, pastikan semua backend load balancer memiliki tanda centang hijau di kolom Healthy.
Pastikan alamat IP endpoint dalam template MIG cocok dengan alamat IP instance Apigee.

VM apigee-proxy dibuat menggunakan template instance. Template menentukan alamat IP ENDPOINT untuk terhubung ke alamat IP instance Apigee.
1. Dapatkan alamat IP instance Apigee:
```
curl -s -H "Authorization: Bearer (gcloud auth print-access-token)" \
"https://apigee.googleapis.com/v1/organizations/ORG_NAME/instances/INSTANCE_NAME"
```
  Ganti kode berikut:
  - ORG_NAME: nama organisasi Anda. Misalnya, my-org.
  - INSTANCE_NAME: nama instance Anda. Misalnya, apigee-proxy-example.
2. Atau, dapatkan alamat IP instance Apigee menggunakan UI Apigee:
  1. Di Apigee UI, klik Admin > Instances.
  2. Kolom Alamat IP mencantumkan alamat IP:
3. Dapatkan alamat IP ENDPOINT dari template:
  1. Di konsol Google Cloud , buka halaman Load balancing.
    
    Buka load balancing
  2. Klik Name load balancer. Halaman Load balancer details akan terbuka.
  3. Di area Backend, klik nama layanan backend.
  4. Di area Instance group members, klik nama Template.
  5. Di halaman template, scroll ke Metadata kustom tempat Anda akan melihat alamat IP ENDPOINT:
Pastikan alamat IP ENDPOINT cocok dengan alamat IP Apigee yang ditampilkan di langkah 2. Jika tidak cocok, buka Resolusi.

Resolusi

Jika VM apigee-proxy dalam grup instance menampilkan status tidak responsif, pastikan Anda telah menerapkan aturan firewall yang memungkinkan rentang alamat IP load balancing 130.211.0.0/22 dan 35.191.0.0/16 mengakses MIG.
Di konsol Google Cloud , buka halaman Firewall.

Buka Firewall
Pastikan aturan firewall traffic masuk ada dengan target-tag seperti gke-apigee-proxy dan rentang IP sumber seperti 130.211.0.0/22 dan 35.191.0.0/16 melalui port 443 TCP:

Jika MIG memiliki tag yang berbeda dengan gke-apigee-proxy, pastikan tag tersebut ditambahkan ke target-tag dalam aturan firewall.

Jika aturan firewall tidak ada, tambahkan.
Jika alamat IP ENDPOINT tidak cocok dengan alamat IP instance Apigee, kemungkinan instance tersebut telah dihapus dan dibuat ulang, sehingga alamat IP tidak lagi cocok dengan alamat IP dalam template. Untuk memperbarui template agar menggunakan alamat IP baru, ikuti petunjuk di Mengubah IP instance.

Penyebab: Konfigurasi jaringan salah

Diagnosis

Temukan nilai untuk authorizedNetwork dengan menjalankan panggilan API berikut:

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

Sesuatu yang mirip dengan berikut akan ditampilkan:

{
  "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"
}

Dalam contoh ini, nilai untuk authorizedNetwork adalah default.

Verifikasi bahwa nilai authorizedNetwork sama dengan jaringan yang di-peering dengan servicenetworking:
1. Di konsol Google Cloud project host, buka halaman VPC network peering.
  
  Buka VPC network peering
2. Nilai yang tercantum untuk servicenetworking-googleapis-com di Jaringan VPC Anda harus sama dengan nilai yang ditampilkan dari panggilan API. Misalnya, default.
Jika Anda menggunakan VPC Bersama, pastikan nilai authorizedNetwork memiliki nilai VPC sebenarnya di project host yang di-peering dengan servicenetworking.
1. Di konsol Google Cloud , buka halaman Shared VPC.
  
  Buka Shared VPC
2. Pilih project host.
3. Nilai yang tercantum untuk servicenetworking-googleapis-com di Jaringan VPC Anda harus sama dengan nilai authorizedNetwork yang ditampilkan dari panggilan API. Misalnya, default.
Pastikan grup instance yang terkait dengan load balancer berada di jaringan yang sama dengan nilai authorizedNetwork:
1. Di konsol Google Cloud , buka halaman Load balancing.
  
  Buka load balancing
2. Klik nama load balancer. Halaman Load balancer details akan terbuka. Daftar grup instance ditampilkan di area Backend:
3. Klik nama grup instance. Halaman Overview grup instance akan ditampilkan.
4. Klik tab Details.
5. Scroll ke bagian Networking:
6. Pastikan bahwa Primary network di sini sama dengan nilai authorizedNetwork. Misalnya, default.
7. Klik tab Overview.
8. Di bagian Instance Group Members, klik nama instance. Halaman Details akan ditampilkan.
9. Scroll ke bagian Network Interfaces:
10. Pastikan nilai Network sama dengan nilai authorizedNetwork. Misalnya, default.
11. Buka tab Ringkasan dan ulangi langkah h hingga langkah j untuk setiap instance di bagian Anggota Grup Instance.

Resolusi

Jika pada langkah 2 atau langkah 3, nilai authorizedNetwork tidak sama dengan jaringan yang di-peering dengan servicenetworking, pastikan Anda telah melakukan peering jaringan VPC yang benar dengan servicenetworking dengan mengikuti langkah-langkah di Langkah 4: Konfigurasi jaringan layanan.
Jika pada langkah 4f dan 4j, nilai jaringan tidak sama dengan nilai authorizedNetwork, maka verifikasi bahwa authorizedNetwork adalah jaringan yang di-peering dengan servicenetworking. Jika di-peering dengan benar, dan jaringan masih tidak sama dengan authorizedNetwork,, berarti grup instance dibuat dengan tidak benar dan Anda harus menghubungi Dukungan Pelanggan Google Cloud.

Penyebab: Lingkungan yang tidak terlampir pada instance Apigee baru yang dibuat sebagai bagian dari perluasan wilayah

Diagnosis

Anda melihat error 503 di sisi klien. Contoh:
```
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
```
Catatan: Error 503 ini tidak ditampilkan dalam rekaman aktivitas debug karena permintaan tidak pernah mencapai Pemroses Pesan runtime.
Jika Anda melihat error 503 di region kedua segera setelah perluasan region:
1. Pastikan lingkungan terlampir ke instance baru dengan menjalankan panggilan API berikut:
```
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/ORG_NAME/instances/NEW_INSTANCE/attachments"
```
  Contoh:
```
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/apigee-example-org/instances/apigee-proxy-example/attachments"
```
  Sesuatu yang mirip dengan berikut akan ditampilkan:
```
{
  "attachments": [
    {
      "name": "9ed157df-5ef2-4cdc-b1d5-2643b480eb33",
      "environment": "dev",
      "createdAt": "1628153855420"
    },
    {
      "name": "a9e04dff-4ca4-4749-902f-5058e28c26a5",
      "environment": "prod",
      "createdAt": "1664517347106"
    }
  ]
}
```
  Dalam contoh ini, instance bernama apigee-proxy-example dilampirkan ke dua lingkungan: dev dan prod.
2. Pastikan grup instance terkelola (MIG) untuk region kedua telah dibuat dan ditampilkan sebagai sehat:
  1. Di konsol Google Cloud , buka halaman Load balancing.
    
    Buka load balancing
  2. Klik Name load balancer. Halaman Load balancer details akan terbuka.
  3. Di bagian Backend, Anda akan melihat dua MIG; satu untuk region 1, dan satu untuk region 2. Pastikan keduanya responsif:
  4. Validasi MIG kedua dengan mengikuti langkah-langkah di VM proxy Apigee tidak dapat meneruskan traffic ke instance Apigee.

Resolusi

Jika instance baru tidak dilampirkan ke lingkungan, lampirkan instance ke lingkungan dengan mengikuti petunjuk di Melampirkan lingkungan ke instance baru.

Opsi lainnya adalah memastikan load balancer merutekan permintaan ke backend yang benar tempat lingkungan sudah terlampir. Misalnya, dari lingkungan non-produksi. Anda mungkin ingin melampirkannya hanya ke satu region; namun, load balancer mungkin merutekan permintaan ke region yang salah. Anda perlu memperbarui konfigurasi load balancer untuk memastikan load balancer merutekan ke region yang benar.
Jika MIG tidak responsif, lihat Diagnosis dan Penyelesaian di VM proxy Apigee tidak dapat meneruskan traffic ke instance Apigee.

Harus mengumpulkan informasi diagnostik

Jika masalah berlanjut bahkan setelah mengikuti petunjuk di atas, kumpulkan informasi diagnostik berikut, lalu hubungi Layanan Pelanggan Google Cloud:

Organisasi Apigee
Lingkungan dan proxy API yang mengalami masalah
Sesi debug yang didownload (jika masalah terjadi sesekali)
Output curl verbose dari permintaan yang gagal.
Load balancer yang dikonfigurasi untuk mengirim panggilan API ke Apigee

Masalah pemilihan rute akses dengan Apigee Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Gejala

Pesan error

Kemungkinan penyebab

Penyebab: Error TLS di load balancer HTTPS

Diagnosis

Resolusi

Penyebab: Cloud Armor memblokir permintaan

Diagnosis

Resolusi

Penyebab: VM proxy Apigee tidak dapat meneruskan traffic ke instance Apigee

Diagnosis

Resolusi

Penyebab: Konfigurasi jaringan salah

Diagnosis

Resolusi

Penyebab: Lingkungan yang tidak terlampir pada instance Apigee baru yang dibuat sebagai bagian dari perluasan wilayah

Diagnosis

Resolusi

Harus mengumpulkan informasi diagnostik

Masalah pemilihan rute akses dengan Apigee