Questa pagina è stata tradotta dall'API Cloud Translation.

Reimpostazioni della connessione durante l'handshake TLS per i client non SNI

Sintomo

L'applicazione client potrebbe riscontrare errori di reimpostazione della connessione, connessione rifiutata o simili durante l'handshake TLS quando chiama l'endpoint Apigee.

Messaggi di errore

I client Postman o Node.js potrebbero visualizzare messaggi di errore ECONRESET.

Curl potrebbe mostrare Connection reset by peer quando effettua chiamate HTTPS direttamente all'indirizzo IP di Apigee Ingress. Ad esempio:

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

Altri client potrebbero mostrare errori diversi. Tuttavia, il pattern sarebbe lo stesso: il client non è in grado di stabilire una connessione completa durante l'handshake TLS.

Cause possibili

Il gateway di ingresso di Apigee Hybrid è abilitato per impostazione predefinita per Server Name Indication (SNI). Questo problema può verificarsi se il client non è abilitato per SNI e non è configurata alcuna route Apigee con caratteri jolly per abilitare i client non SNI. Di conseguenza, al client non viene inviato alcun certificato del server TLS predefinito e si verifica un ripristino TCP in entrata di Apigee.

Diagnosi

Determina se il client supporta SNI. Se sai già che non è abilitato SNI, vai al passaggio 4 per convalidare la configurazione di Apigee Hybrid.

Esamina i log di accesso di Apigee Ingress per rilevare eventuali richieste client senza il nome del server SNI e verifica se gli host virtuali non sono configurati con un certificato predefinito per i client non SNI.

Visualizza un elenco dei tuoi pod apigee-ingressgateway con il seguente comando:

kubectl -n apigee get pods -l app=apigee-ingressgateway

Esempio di 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

Recupera i log per un pod apigee-ingressgateway.
```
kubectl -n apigee logs APIGEE_INGRESSGATEWAY_POD
```
Dove APIGEE_INGRESSGATEWAY_POD è un pod apigee-ingressgateway elencato nell'output del comando precedente.

Un log degli accessi potrebbe avere il seguente aspetto:

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

Analizzando il log precedente, puoi dedurre quanto segue:
1. "sni_host": null: il client non è abilitato per SNI perché non è presente alcun nome host SNI. Ad esempio, api-test.mydomain.com è associato a questa richiesta.
2. "status_details": "filter_chain_not_found": i certificati server vengono selezionati in base a un filter chain basato su sni_host. Se non esiste alcun sni_host e non è configurato alcun valore predefinito, non è possibile trovare filter chain. Ciò significa che non viene restituito alcun certificato server, come mostrato nella richiesta client di esempio.
3. "status": 0: Non è presente alcun codice di stato perché la connessione è stata reimpostata.

Anziché esaminare i log, un modo più preciso per verificare se un client ha abilitato SNI è acquisire un pacchetto davanti ad Apigee Ingress o su Apigee Ingress stesso. In questo modo, potrai stabilire se il client invia l'intestazione SNI per l'handshake TLS.

Per l'esecuzione su Apigee Ingress in Google Kubernetes Engine, è necessario SSH al nodo che esegue il gateway Ingress e installare toolbox e tcpdump.
Nota:la procedura per eseguire l'acquisizione di pacchetti può variare a seconda della piattaforma su cui è installato Apigee Hybrid.
```
tcpdump -n -i any -s 0 'host IP_Address' -w FILE_NAME
```
Dove FILE_NAME è il nome del file, incluso il percorso, in cui vuoi salvare l'output dell'acquisizione dei pacchetti.
Analizza l'acquisizione dei pacchetti utilizzando Wireshark o uno strumento simile.
Ecco un'analisi di esempio di un'acquisizione di pacchetti utilizzando Wireshark su Apigee Ingress. .
- Nell'output dell'acquisizione dei pacchetti, il messaggio n. 83 indica che il client (origine) ha inviato un messaggio "Client Hello" a Apigee Ingress (destinazione).
- Quando selezioni il messaggio Client Hello ed esamini Handshake Protocol: Client Hello, vedrai che manca Extension: server_name.
- Ad esempio, un client abilitato per SNI mostrerà Extension: server_name nell'output, come mostrato nell'esempio seguente.
- Ciò conferma che il client non ha inviato server_name a Apigee Ingress.
- Poiché nel messaggio Client Hello non è incluso alcun server_name SNI, non viene restituito alcun certificato server e Apigee Ingress chiude la connessione con un pacchetto RST.

Verifica se i client non SNI sono supportati testando un endpoint Apigee con uno strumento come OpenSSL per inviare richieste con o senza l'intestazione SNI.al.
1. Controlla se i client non SNI sono attivi.
```
openssl s_client -connect api-test.mydomain.com:443 -noservername
```
  Output di esempio
```
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. La risposta precedente mostra che non è disponibile alcun certificato peer, il che significa che i client SNI non sono abilitati all'interno della route Apigee, poiché abbiamo passato l'opzione -noservername nel comando. Se è stato restituito un certificato peer durante l'utilizzo del flag -noservername, significa che è configurata una route jolly.
  Nota:le versioni precedenti di OpenSSL non supportano SNI per impostazione predefinita e richiedono l'opzione -servername per inviare l'intestazione SNI.
Esamina la configurazione attuale della route Apigee per verificare se una route jolly è configurata e abilitata sull'host virtuale.
1. Ottieni un elenco delle route Apigee definite con il seguente comando:
```
kubectl -n apigee get apigeeroutes 
```
  Esempio di output
```
NAME                                  STATE     AGE
myorg-hyb-dev-grp-000-33620d0         running   2d1h
non-sni                               running   17s
```
2. Controlla ogni route Apigee per i nomi host che includono un carattere jolly.
  Per ogni route Apigee, esegui il comando fornito per recuperare una matrice JSON dei relativi nomi host definiti. Un percorso jolly sarà indicato da un asterisco (*) nell'output.
```
kubectl -n apigee get apigeeroute APIGEE_ROUTE_NAME
```
  Esempio per l'itinerario myorg-hyb-dev-grp-000-33620d0:
```
kubectl -n apigee get apigeeroute myorg-hyb-dev-grp-000-33620d0 -o jsonpath='{.spec.hostnames}'
```
  Esempio di output
```
["api-test.mydomain.com"]
```
  Esempio per l'itinerario non-sni:
```
kubectl -n apigee get apigeeroute non-sni -o jsonpath='{.spec.hostnames}'
```
  Esempio di output
```
["*"]
```
  non-sni apigeeroute è una route jolly perché contiene (*) come nome host.
3. Se è configurata una route jolly, i client non SNI sono abilitati.
4. Per la route jolly, assicurati che il flag enableNonSniClient sia impostato su true. Il seguente comando viene eseguito sulla route jolly con il client non-sni.
```
kubectl -n apigee get apigeeroute non-sni -o jsonpath='{.spec.enableNonSniClient}'
```
  Esempio di output
```
true
```
5. Se la route con caratteri jolly esiste e i client non SNI sono abilitati, esamina la configurazione dell'host virtuale nel file overrides.yaml per assicurarti che la route con caratteri jolly sia elencata in 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 verrà visualizzato nella route Apigee definita dalla configurazione dell'host virtuale. Utilizza il seguente comando per verificare che il additionalGateway configurato venga visualizzato nella configurazione della route Apigee.
```
  kubectl -n apigee get apigeeroute APIGEE_ROUTE_NAME -o jsonpath='{.spec.additionalGateways}
```
  Ad esempio, l'itinerario myorg-hyb-dev-grp-000-33620d0 dovrebbe mostrare l'itinerario non-sni come additionalGateway.
```
  kubectl -n apigee get apigeeroute myorg-hyb-dev-grp-000-33620d0 -o jsonpath='{.spec.additionalGateways}'
```
  Esempio di output
```
["non-sni"]
```
Risoluzione

Se i passaggi di diagnostica indicano che il tuo client non è abilitato per SNI e i client non SNI non sono abilitati o configurati correttamente nell'installazione di Apigee Hybrid, segui la documentazione relativa all'abilitazione dei client non SNI per consentire il traffico dai client non SNI.

Deve raccogliere informazioni diagnostiche
Se il problema persiste anche dopo aver seguito le istruzioni precedenti, raccogli le seguenti informazioni diagnostiche e contatta l'assistenza clienti Google Cloud:
- Overrides.yaml
- Output dei seguenti comandi
- Gruppo o gruppi di ambienti che presentano il problema