Halaman ini diterjemahkan oleh Cloud Translation API.

Mengakses masalah pemilihan rute di Apigee

Anda sedang melihat dokumentasi Apigee dan Apigee hybrid.
Tidak ada padanan Dokumentasi Apigee Edge untuk topik ini.

Gejala

Dalam beberapa kasus, dengan cara yang diinginkan klien eksternal tidak dapat mengakses/terhubung ke Apigee. 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 TLS kegagalan handshake atau respons 4xx/5xx meskipun API proxy mungkin tampak bermanfaat 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 TLS handshake dari alamat IP load balancer
Google Cloud Armor memblokir permintaan	Jika Anda menggunakan Google Cloud Armor, mungkin ada pemblokiran aturan terhadap permintaan.	Kode respons API dapat bervariasi berdasarkan Google Cloud Armor konfigurasi Anda. Aturan penolakan dapat menampilkan `HTTP 403` (Tidak sah), `404` (Akses Ditolak), atau `502` (Gateway Buruk) atau bahkan kode respons lain.
VM proxy Apigee tidak dapat meneruskan traffic ke instance Apigee	Konfigurasi proxy router traffic API Apigee dan responsnya perlu diselidiki	`502 Server Error`
Konfigurasi jaringan salah	Pastikan jaringan yang benar di-peering dengan VPC Apigee.	`502 Server error`
Lingkungan yang tidak terlampir di instance Apigee baru dibuat sebagai bagian dari perluasan region	Setelah membuat instance baru, misalnya region kedua, Anda harus melampirkan lingkungan ke dalamnya, jika tidak maka tidak dapat merespons permintaan API.	`503 error response`

Penyebab: Error TLS pada load balancer HTTPS

Diagnosis

Temukan sertifikat TLS yang terkait dengan load balancer.

Menggunakan Konsol Google Cloud:
1. Di Konsol Google Cloud, buka Load balancing. kami.
  
  Buka load balancing
2. Klik Nama load balancer. Load balancer halaman detail akan terbuka.
3. Di area Frontend, pada kolom IP:Port, pastikan Anda melihat load balancer yang tepat dengan memverifikasi Alamat IP dan port.
4. Di kolom Certificate, klik nama sertifikat untuk melihat sertifikat TLS.

Menggunakan perintah gcloud:

Menampilkan daftar load balancer dengan gcloud. 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 hal berikut ini 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 hal berikut perintah gcloud (dengan asumsi Anda telah

jq

atau alat serupa yang diinstal 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 sertifikat nama. Contoh, example-ssl-cert.

Sesuatu yang mirip dengan hal berikut ini 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 Hostname yang dikonfigurasi di Apigee > Admin > Lingkungan > Grup. Pastikan bahwa sertifikat valid dan tidak kedaluwarsa. Anda dapat menggunakan openssl untuk melakukannya pemeriksaan.

Untuk memeriksa sertifikat TLS yang ditampilkan oleh load balancer, jalankan mengikuti perintah openssl dari komputer klien Anda. Periksa untuk melihat apakah sertifikat ini cocok dengan yang dikembalikan 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 IP load balancer alamat IPv6 Contoh, my-load-balancer.
- LB_HOSTNAME: nama host load balancer. Misalnya, my-hostname.
Untuk memastikan kecocokan sertifikat, 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 > Lingkungan > Grup).

Kemudian, verifikasi bahwa md5 cocok dengan menjalankan perintah berikut Perintah gcloud:
```
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 CA {i>root<i}. Misalnya, my-certificate
Jika langkah 1 dan langkah 2 kecocokan sertifikat (yaitu, jika nilai md5 cocok), maka lanjutkan mengumpulkan packet capture di sisi klien untuk menyelidiki kegagalan handshake TLS. Anda dapat mengambil tangkapan paket di sisi klien Anda dengan alat seperti Wireshark, tcpdump atau resource alat.
Aktifkan log pada load balancer dengan mengikuti petunjuk di Mengaktifkan logging di layanan backend yang ada.
Meninjau load balancer log untuk setiap error.

Resolusi

Jika sertifikat yang dikelola sendiri pada load balancer sudah tidak berlaku atau telah nilai CN/SAN salah, Anda mungkin harus mengganti sertifikat di load balancer.
Jika sertifikat yang ditampilkan oleh load balancer di langkah 1 dan sertifikat di langkah 2 tidak cocok, maka itu mungkin berarti bahwa load balancer melayani sertifikat usang/salah, dan Anda harus mengajukan tiket ke Google Cloud Customer Care.
Jika tcpdump menunjukkan kegagalan handshake TLS, selidiki apakah kegagalan koneksi berasal dari load balancer di sisi klien.
- Jika kegagalan atau pengaturan ulang koneksi berasal dari sisi klien, periksa aplikasi klien Anda untuk memahami mengapa terjadi gangguan. Sebagai misalnya, Anda dapat memeriksa konfigurasi jaringan di sisi klien atau pastikan aplikasi klien memiliki konektivitas dengan Apigee.
- Jika Anda melihat kegagalan/reset dari load balancer, lihat Memecahkan masalah umum terkait konektivitas dan mengajukan tiket dengan Google Cloud Customer Care jika diperlukan.
Jika Anda melihat error di log load balancer, lihat Error 5XX yang tidak dijelaskan dan mengajukan tiket ke Google Cloud Customer Care jika diperlukan.

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

Penyebab: Cloud Armor memblokir permintaan

Diagnosis

Jika Anda melihat error 403, 404, atau 502 respons berdasarkan Cloud Armor konfigurasi, tinjau load balancer dan konfigurasi MIG untuk memverifikasinya dikonfigurasi dengan benar dan tampak sehat.

Jika Anda menggunakan Google Cloud Armor di lingkungan Google Cloud, tinjau konfigurasi Google Cloud Armor untuk aturan apa pun yang mungkin memblokir permintaan. Kebijakan keamanan dapat ditemukan di Konfigurasikan kebijakan keamanan Google Cloud Armor.
Jika Anda tidak yakin aturan mana yang menolak lalu lintas, Anda dapat mencoba mengaktifkan logging di load balancer seperti yang dijelaskan di Mengaktifkan logging di layanan backend yang ada.
Setelah logging diaktifkan, lakukan kueri log untuk menemukan permintaan 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 dalam Panel Query results:

Resolusi

Ubah aturan/konfigurasi Google Cloud Armor agar sesuai dengan kebutuhan Anda mengatasi 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 HTTP 502 error dengan hal berikut pesan error, VM proxy router traffic API Apigee mungkin dalam kondisi tidak sehat.

502 error seperti berikut mungkin diterima oleh klien Anda:
```
<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 pesan error seperti berikut:
```
statusDetails: "failed_to_pick_backend"
severity: "WARNING"
```
Ada sekumpulan VM (dengan awalan apigee-proxy) berjalan di grup instance terkelola (MIG) yang meneruskan traffic ke instance Apigee. Jika Anda melihat pesan seperti di atas, periksa kondisi bagian VM apigee-proxy pada instance mengelompokkan melalui langkah-langkah berikut:
1. Di Konsol Google Cloud, buka Load balancing. kami.
  
  Buka load balancing
2. Klik Nama load balancer. Detail load balancer halaman akan terbuka.
3. Di bagian Backend, pastikan semua load balancer backend memiliki tanda centang hijau di kolom Healthy.
Verifikasi bahwa alamat IP endpoint di template MIG cocok dengan Alamat IP instance Apigee.

VM apigee-proxy dibuat menggunakan instance {i>template<i}. 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 UI Apigee, klik Admin > Instances.
  2. Kolom IP addresses mencantumkan alamat IP:
3. Dapatkan alamat IP ENDPOINT dari template:
  1. Di konsol Google Cloud, buka halaman Load balancing.
    
    Buka load balancing
  2. Klik Nama load balancer. Load balancer halaman detail akan terbuka.
  3. Di area Backend, klik nama layanan backend.
  4. Di area Instance group members, klik Template nama.
  5. Di halaman template, scroll ke Metadata kustom yang tempat Anda akan melihat alamat IP ENDPOINT:
Pastikan alamat IP ENDPOINT cocok dengan Apigee Alamat IP yang ditampilkan pada langkah 2. Jika tidak cocok, buka Resolusi.

Resolusi

Jika VM apigee-proxy dalam grup instance menampilkan tidak responsif, pastikan Anda memiliki aturan {i>firewall<i} yang memungkinkan load balancing untuk rentang alamat IP 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 masuk dengan target-tag sudah ada seperti gke-apigee-proxy dan rentang IP sumber seperti 130.211.0.0/22 dan 35.191.0.0/16 selama Port 443 TCP:

Jika MIG memiliki tag yang berbeda dari gke-apigee-proxy, lalu pastikan tag tersebut ditambahkan ke target-tag di aturan firewall.

Jika aturan firewall tidak ada, tambahkan aturan tersebut.
Jika alamat IP ENDPOINT tidak cocok dengan IP instance Apigee instance, ada kemungkinan bahwa instance tersebut telah dihapus dan dibuat ulang, akan menghasilkan alamat IP yang tidak lagi cocok dengan alamat IP di {i>template<i}. Untuk memperbarui template agar dapat menggunakan alamat IP baru, ikuti petunjuk di Mengubah IP instance.

Penyebab: Konfigurasi jaringan salah

Diagnosis

Temukan nilai untuk authorizedNetwork dengan menjalankan mengikuti Panggilan API:

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

Sesuatu yang mirip dengan hal berikut ini 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 untuk project host, buka Peering jaringan VPC.
  
  Buka VPC network peering
2. Nilai yang tercantum untuk servicenetworking-googleapis-com dalam 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 yang sebenarnya di project host yang di-peering dengan servicenetworking.
1. Di Konsol Google Cloud, buka halaman VPC Bersama.
  
  Buka VPC Bersama
2. Pilih project host.
3. Nilai yang tercantum untuk servicenetworking-googleapis-com dalam Jaringan VPC Anda harus sama dengan nilai authorizedNetwork ditampilkan dari panggilan API. Misalnya, default.
Verifikasi bahwa grup instance yang terkait dengan load balancer adalah jaringan yang sama dengan nilai authorizedNetwork:
1. Di konsol Google Cloud, buka halaman Load balancing.
  
  Buka load balancing
2. Klik nama load balancer. Halaman Detail load balancer terbuka. Daftar grup instance ditampilkan di Backend area:
3. Klik nama grup instance. Ringkasan grup instance ditampilkan.
4. Klik tab Detail.
5. Scroll ke bagian Jaringan:
6. Pastikan bahwa Jaringan utama di sini sama dengan Nilai authorizedNetwork. Misalnya, default.
7. Klik tab Ringkasan.
8. Di bagian Instance Group Members, klik nama di instance Compute Engine. Halaman Details akan ditampilkan.
9. Scroll ke bagian Antarmuka Jaringan:
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, lalu pastikan Anda memiliki telah melakukan peering jaringan VPC yang benar menggunakan servicenetworking dengan mengikuti langkah-langkah dalam Langkah 4: Konfigurasi jaringan layanan.
Jika pada langkah 4f dan 4j, jaringan nilainya tidak sama dengan nilai authorizedNetwork, maka pastikan bahwa authorizedNetwork adalah jaringan yang di-peering dengan servicenetworking. Jika di-peering dengan benar, dan jaringan masih tidak sama dengan authorizedNetwork, maka ini berarti pembuatan grup instance dengan tidak benar dan Anda harus menghubungi Google Cloud Customer Care.

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

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 di trace debug karena permintaan tidak pernah mencapai Pemroses Pesan runtime.
Jika Anda langsung melihat 503 error di region kedua setelah 1 perluasan wilayah:
1. Pastikan lingkungan sudah terpasang ke instance baru dengan menjalankan perintah Panggilan API:
```
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 hal berikut ini 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 bahwa grup instance terkelola (MIG) untuk region kedua memiliki telah dibuat dan ditampilkan sebagai responsif:
  1. Di konsol Google Cloud, buka halaman Load balancing.
    
    Buka load balancing
  2. Klik Nama load balancer. Tujuan Halaman Detail load balancer akan terbuka.
  3. Di bagian Backend, Anda akan melihat dua MIG; satu untuk wilayah 1, dan satu untuk region 2. Pastikan keduanya responsif:
  4. Validasi MIG kedua dengan mengikuti langkah-langkah dalam VM proxy Apigee tidak dapat meneruskan traffic ke instance Apigee.

Resolusi

Jika instance baru tidak terpasang ke lingkungan, lampirkan ke lingkungan dengan mengikuti petunjuk di Menambahkan lingkungan ke instance baru.

Opsi lainnya adalah memastikan load balancer merutekan permintaan ke backend yang benar tempat lingkungan terpasang. Misalnya, dari lingkungan nonprod. Anda mungkin ingin melampirkan ini hanya ke satu wilayah; Namun, load balancer mungkin merutekan permintaan ke region yang salah. Anda perlu untuk memperbarui konfigurasi load balancer guna memastikan diarahkan ke teritorial Anda.
Jika MIG tidak sehat, Lihat Diagnosis dan Resolusi di VM proxy Apigee tidak dapat meneruskan traffic ke instance Apigee.

Harus mengumpulkan informasi diagnostik

Jika masalah berlanjut bahkan setelah mengikuti instruksi di atas, kumpulkan informasi diagnostik berikut, lalu hubungi Google Cloud Customer Care:

Organisasi Apigee
Proxy API dan lingkungan mengalami masalah
Sesi debug yang didownload (jika masalah ini terputus-putus)
Output curl panjang dari permintaan yang gagal.
Load balancer dikonfigurasi untuk mengirim panggilan API ke Apigee