Koneksi direset selama handshake TLS untuk klien non-SNI

Gejala

Aplikasi klien Anda mungkin mengalami reset koneksi, koneksi ditolak, atau error serupa selama handshake TLS saat memanggil endpoint Apigee.

Pesan error

  • Klien Postman atau Node.js mungkin melihat pesan error ECONRESET.

  • Curl dapat menampilkan Connection reset by peer saat melakukan panggilan HTTPS langsung ke alamat IP Apigee Ingress. Contoh: 

    curl https://1.2.3.4/basepath -H "Host: your.apigee.domain" -kv
* Connected to 1.2.3.4 (1.2.3.4) port 443
* (304) (OUT), TLS handshake, Client hello (1):
* Recv failure: Connection reset by peer
* Closing connection

  • Klien lain mungkin menampilkan error yang berbeda. Namun, polanya akan sama; klien tidak dapat sepenuhnya membuat koneksi selama handshake TLS.

Kemungkinan penyebab

Ingress Gateway Apigee Hybrid diaktifkan untuk Server Name Indication (SNI) secara default. Masalah ini dapat terjadi jika klien Anda tidak mendukung SNI dan tidak ada rute Apigee wildcard yang dikonfigurasi untuk mengaktifkan klien non-SNI. Hal ini menyebabkan tidak ada sertifikat server TLS default yang dikirim ke klien, dan reset TCP ingress Apigee terjadi.

Diagnosis

  1. Tentukan apakah klien Anda mendukung SNI. Jika Anda sudah tahu bahwa SNI tidak diaktifkan, lanjutkan ke langkah 4 untuk memvalidasi konfigurasi Apigee Hybrid.

    Tinjau log akses Apigee Ingress untuk melihat tanda-tanda permintaan klien tanpa nama server SNI, dan periksa apakah host virtual tidak dikonfigurasi dengan sertifikat default untuk klien non-SNI.

    • Dapatkan listingan pod apigee-ingressgateway Anda dengan perintah berikut: 
      kubectl -n apigee get pods -l app=apigee-ingressgateway

      Contoh output

      NAME                                                              READY   STATUS    RESTARTS   AGE
apigee-ingressgateway-ext-ingress-myorg-hyb-8f2c412-dvrcp         2/2     Running   0          46h
apigee-ingressgateway-ext-ingress-myorg-hyb-8f2c412-wg26k         2/2     Running   0          46h
    • Dapatkan log untuk pod apigee-ingressgateway. 
      kubectl -n apigee logs APIGEE_INGRESSGATEWAY_POD
       Dengan APIGEE_INGRESSGATEWAY_POD adalah pod apigee-ingressgateway yang tercantum dalam output perintah sebelumnya.
    • Log akses mungkin terlihat seperti berikut: 
      {
  "request_time": 1,
  "tls_protocol": null,
  "upstream_service_time": null,
  "request_method": null,
  "request_protocol": null,
  "upstream_response_time": null,
  "bytes_sent": 0,
  "start_time": "2025-05-19T04:46:20.117Z",
  "bytes_received": 0,
  "host": null,
  "upstream_cluster": null,
  "upstream_address": null,
  "remote_address": "10.138.0.28:19432",
  "request_path": null,
  "request_id": null,
  "user_agent": null,
  "status_details": "filter_chain_not_found",
  "request": "- - -",
  "status": 0,
  "x_forwarded_for": null,
  "apigee_dynamic_data": null,
  "upstream_response_flags": "NR",
  "sni_host": null
}
    • Dengan menganalisis log sebelumnya, Anda dapat menyimpulkan hal berikut:
      1. "sni_host": null: Klien tidak mendukung SNI karena tidak ada nama host SNI. Misalnya, api-test.mydomain.com dikaitkan dengan permintaan ini.
      2. "status_details": "filter_chain_not_found" : Sertifikat server dipilih berdasarkan filter chain yang didasarkan pada sni_host. Jika sni_host tidak ada dan tidak ada default yang dikonfigurasi, filter chain tidak dapat ditemukan. Artinya, tidak ada sertifikat server yang ditampilkan, seperti yang terlihat dalam contoh permintaan klien.
      3. "status": 0: Tidak ada kode status karena koneksi direset.
  2. Daripada meninjau log, cara yang lebih akurat untuk memeriksa apakah klien mendukung SNI adalah dengan mengambil rekaman paket di depan Apigee Ingress atau di Apigee Ingress itu sendiri. Hal ini akan membantu menentukan apakah klien mengirim header SNI untuk handshake TLS.
    1. Untuk berjalan di Apigee Ingress di Google Kubernetes Engine, Anda memerlukan SSH ke node yang menjalankan gateway ingress dan menginstal toolbox dan tcpdump. 
      tcpdump -n -i any -s 0 'host IP_Address' -w FILE_NAME

      Dengan FILE_NAME adalah nama file, termasuk jalur, tempat Anda ingin menyimpan output pengambilan paket.

    2. Analisis pengambilan paket menggunakan Wireshark atau alat serupa.
    3. Berikut contoh analisis pengambilan paket menggunakan Wireshark yang dilakukan di Apigee Ingress. .
      • Dalam output pengambilan paket, pesan #83 menunjukkan bahwa Klien (sumber) mengirim pesan "Client Hello" ke Apigee Ingress (tujuan). client-hello.png
      • Saat Anda memilih pesan Client Hello dan memeriksa Handshake Protocol: Client Hello, Anda akan melihat bahwa Extension: server_name tidak ada. client-hello-extension.png
      • Sebagai contoh, klien yang mendukung SNI akan menampilkan Extension: server_name dalam output seperti yang ditunjukkan dalam contoh berikut. client-hello-extension-sni.png
      • Hal ini mengonfirmasi bahwa klien tidak mengirim server_name ke Apigee Ingress.
      • Karena tidak ada server_name SNI yang disertakan dalam pesan Client Hello, tidak ada sertifikat server yang ditampilkan, dan Apigee Ingress menutup koneksi dengan paket RST.
  3. Periksa apakah klien non-SNI didukung dengan menguji endpoint Apigee menggunakan alat seperti OpenSSL untuk mengirim permintaan dengan atau tanpa header SNI.al.
    1. Periksa apakah klien non-SNI diaktifkan. 
      openssl s_client -connect api-test.mydomain.com:443 -noservername

      Contoh Output

      Connecting to 1.2.3.4
CONNECTED(00000005)
write:errno=54
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 299 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
    2. Respons di atas menunjukkan no peer certificate available yang berarti klien SNI tidak diaktifkan dalam rute Apigee, karena kita meneruskan opsi -noservername dalam perintah. Jika sertifikat peer ditampilkan saat menggunakan flag -noservername, hal ini akan menunjukkan bahwa rute karakter pengganti dikonfigurasi.
  4. Tinjau konfigurasi rute Apigee saat ini untuk melihat apakah rute wildcard dikonfigurasi dan diaktifkan di host virtual.
    1. Dapatkan daftar rute Apigee yang ditentukan dengan perintah berikut: 
      kubectl -n apigee get apigeeroutes

      Contoh output

      NAME                                  STATE     AGE
myorg-hyb-dev-grp-000-33620d0         running   2d1h
non-sni                               running   17s
    2. Periksa setiap rute Apigee untuk nama host yang menyertakan karakter pengganti.

      Untuk setiap rute Apigee, jalankan perintah yang diberikan untuk mengambil array JSON dari nama host yang ditentukan. Rute karakter pengganti akan ditunjukkan dengan tanda bintang (*) dalam output.

      kubectl -n apigee get apigeeroute APIGEE_ROUTE_NAME

      Contoh untuk rute myorg-hyb-dev-grp-000-33620d0:

      kubectl -n apigee get apigeeroute myorg-hyb-dev-grp-000-33620d0 -o jsonpath='{.spec.hostnames}'

      Contoh output

      ["api-test.mydomain.com"]

      Contoh untuk rute non-sni:

      kubectl -n apigee get apigeeroute non-sni -o jsonpath='{.spec.hostnames}'

      Contoh output

      ["*"]

      Apigeeroute non-sni adalah rute karakter pengganti karena berisi (*) sebagai nama host.

    3. Jika rute wildcard dikonfigurasi, klien non-SNI akan diaktifkan.
    4. Untuk rute karakter pengganti, pastikan tanda enableNonSniClient ditetapkan ke benar (true). Perintah berikut berjalan di rute wildcard dengan klien non-sni. 
      kubectl -n apigee get apigeeroute non-sni -o jsonpath='{.spec.enableNonSniClient}'

      Contoh output

      true
    5. Jika rute wildcard ada dan klien non-SNI diaktifkan, tinjau konfigurasi host virtual dalam file overrides.yaml untuk memastikan rute wildcard tercantum dalam additionalGateways. 
      virtualhosts:
- name: dev-grp
  selector:
    app: apigee-ingressgateway
    ingress_name: ext-ingress
  sslCertPath: ./certs/keystore_dev-grp.pem
  sslKeyPath: ./certs/keystore_dev-grp.key
  additionalGateways: ["non-sni"]
    6. additionalGateways akan muncul di rute Apigee yang ditentukan oleh konfigurasi host virtual Anda. Gunakan perintah berikut untuk mengonfirmasi bahwa additionalGateway yang Anda konfigurasi muncul dalam konfigurasi rute Apigee. 
        kubectl -n apigee get apigeeroute APIGEE_ROUTE_NAME -o jsonpath='{.spec.additionalGateways}

      Misalnya, rute myorg-hyb-dev-grp-000-33620d0 harus menampilkan rute non-sni sebagai additionalGateway.

        kubectl -n apigee get apigeeroute myorg-hyb-dev-grp-000-33620d0 -o jsonpath='{.spec.additionalGateways}'

      Contoh output

      ["non-sni"]

    Resolusi

    Jika langkah-langkah diagnostik menunjukkan bahwa klien Anda adalah klien yang tidak mendukung SNI dan klien yang tidak mendukung SNI tidak diaktifkan atau dikonfigurasi dengan benar di penginstalan Apigee Hybrid Anda, ikuti dokumentasi mengaktifkan klien yang tidak mendukung SNI untuk mengizinkan traffic dari klien yang tidak mendukung SNI.

    Harus mengumpulkan informasi diagnostik

    Jika masalah berlanjut bahkan setelah mengikuti petunjuk sebelumnya, kumpulkan informasi diagnostik berikut, lalu hubungi Layanan Pelanggan Google Cloud:
    • Overrides.yaml
    • Output dari perintah berikut
      • kubectl -n apigee get apigeeroutes
      • Untuk setiap rute yang dinyatakan, jalankan: kubectl -n apigee describe apigeeroute
    • Grup Lingkungan yang mengalami masalah