Errore di servizio di peering VPC 503 non disponibile con TARGET_CONNECT_TIMEOUT

Stai visualizzando la documentazione relativa a Apigee e Apigee ibrido.
Non esiste una documentazione Apigee Edge equivalente per questo argomento.

Sintomo

Questo problema viene visualizzato come errore "503 - Servizio non disponibile" in Monitoraggio delle API, Debug o in altri strumenti. Il motivo "TARGET_CONNECT_TIMEOUT" indica un timeout della connessione tra l'istanza Apigee e la destinazione quando si utilizza il peering VPC.

L'errore non deve essere confuso con altri errori di timeout, come 504 Gateway Timeout (Timeout del gateway).

Messaggio di errore

Si tratta dell'errore tipico nella sessione di debug o nel payload della risposta. Nota il motivo: TARGET_CONNECT_TIMEOUT.

{"fault":{"faultstring":"The Service is temporarily unavailable",
"detail":{"errorcode":"messaging.adaptors.http.flow.ServiceUnavailable",
"reason":"TARGET_CONNECT_TIMEOUT"}}}

Possibili cause

Tieni presente che queste cause sono specifiche per la configurazione di Apigee con peering VPC. Vedi Opzioni di networking Apigee. Se il target è PSC (collegamento endpoint), consulta invece il playbook PSC.

Causa	Descrizione
Configurazione errata delle route	Le route di destinazione non vengono esportate nel peering con l'istanza Apigee.
Problema di connettività nell'obiettivo	La destinazione non è sempre in grado di accettare una connessione TCP.
Lista consentita degli IP nella destinazione con alcuni o tutti gli IP Apigee NAT non aggiunti	Non tutti gli IP Apigee NAT sono nella lista consentita nella destinazione.
Esaurimento delle porte IP NAT	Numero insufficiente di porte NAT per il traffico.
Il valore diconnect.timeout.millis è impostato su un valore troppo basso	L'impostazione del timeout della connessione è troppo bassa sul lato Apigee.

Passaggi diagnostici comuni

Debug è uno strumento essenziale per acquisire e valutare i seguenti dettagli del problema:

• Durata totale della richiesta. In genere sono necessari tre secondi (impostazione predefinita connect.timeout.millis) fino al timeout della connessione. Se noti una durata inferiore, controlla la configurazione dell'endpoint di destinazione.
• Nome host e indirizzo IP di destinazione. L'indirizzo IP errato visualizzato potrebbe indicare un problema relativo al DNS. Potresti anche notare una correlazione tra diversi IP di destinazione e il problema.
• Frequenza. Sono necessari approcci diversi a seconda che il problema sia intermittente o persistente.

Causa: configurazione errata del percorso

Diagnosi

Se il problema persiste, anche se è stato avviato di recente, potrebbe essere causato da un'errata configurazione della route.

Questo potrebbe influire sia su destinazioni interne (instradate all'interno di VPC in peering) sia su destinazioni esterne (internet).

1. Identifica innanzitutto l'indirizzo IP della destinazione risolta dall'istanza Apigee. Uno dei metodi è utilizzare una sessione di Debug. In Debug, vai ad AnalyticsPublisher (o AX nella versione classica di Debug):
   
   

   Cerca il valore target.ip sul lato destro dello schermo.

   In questo esempio, l'IP è 10.2.0.1. Poiché questo intervallo è privato, richiede l'applicazione di determinate misure di routing per garantire che Apigee possa raggiungere la destinazione.

   Tieni presente che se la destinazione è su internet, devi seguire questo passaggio se i Controlli di servizio VPC sono abilitati per Apigee, poiché ciò impedisce la connettività a internet.

2. Prendi nota della regione in cui viene eseguito il deployment dell'istanza Apigee interessata. Nella UI di Apigee nella console Cloud, fai clic su Istanze. Nel campo Località puoi trovare la regione esatta dell'istanza.
   
   
   
3. Nel progetto in peering con Apigee, vai alla sezione Rete VPC -> Peering di rete VPC nell'interfaccia utente. Tieni presente che se utilizzi un VPC condiviso, questi passaggi devono essere eseguiti nel progetto host anziché nel progetto Apigee.
   
   
4. Fai clic su servicenetworking-googleapis-com, seleziona la scheda ROUTE ESPORTATE e filtra in base alla regione ottenuta nel passaggio 2.
   
   Questo esempio mostra la route 10.2.0.0/24 come esportata e include l'IP di destinazione di esempio 10.2.0.1. Se non vedi un percorso corrispondente al tuo target, è questo la causa del problema.
   
   Nota: se la destinazione è esterna, le route normalmente non sono presenti nelle route esportate e le richieste Apigee vengono instradate direttamente a internet. Potrebbe non essere sempre così, quindi assicurati di chiarire la topologia di rete desiderata. Ad esempio, se i Controlli di servizio VPC sono abilitati, devi esportare anche le route predefinite o altre route per raggiungere destinazioni esterne.
   
   

Risoluzione

Esamina la tua architettura di rete e assicurati che le route vengano esportate nel peering VPC con Apigee. Molto probabilmente la route mancante è statica o dinamica. La mancanza di route dinamiche necessarie indica un problema con la funzionalità corrispondente, ad esempio Cloud Interconnect.

Tieni presente che il peering transitivo non è supportato. In altre parole, se la rete VPC N1 è connessa in peering con N2 e N3, ma N2 e N3 non sono connesse direttamente, la rete VPC N2 non può comunicare con la rete VPC N3 tramite peering di rete VPC.

Per saperne di più, leggi Pattern di networking di Southbound.

Causa: problema di connettività nella destinazione

Diagnosi

La destinazione potrebbe non essere raggiungibile dal VPC o non essere in grado di accettare una connessione. Sono disponibili due opzioni per diagnosticare il problema.

Connectivity Tests (indirizzi IP di destinazione privati)

Se la destinazione si trova su una rete privata, puoi utilizzare la funzionalità Test di connettività per diagnosticare le cause comuni.

1. Identifica l'indirizzo IP della destinazione risolta dall'istanza Apigee. Uno dei metodi è utilizzare una sessione di Debug.
   
   In Debug, vai ad AnalyticsPublisher (o AX nella versione classica di Debug). Cerca il valore target.ip sul lato destro dello schermo.
   
   In questo esempio, l'IP è 10.2.0.1. Si tratta di un indirizzo IP privato, il che significa che possiamo utilizzare il test di connettività.
   
   
2. Prendi nota dell'indirizzo IP dell'istanza Apigee che non è in grado di connettersi alla destinazione. In Istanze nella console Apigee, trova l'indirizzo IP dell'istanza Apigee nel campo Indirizzo IP.
   
   
3. Vai a Connectivity Tests e fai clic su Crea test di connettività. Fornisci questi dettagli:
   1. Indirizzo IP di origine: utilizza l'IP dell'istanza Apigee ottenuto nel passaggio 2 precedente. Tieni presente che questo non è l'IP di origine esatto utilizzato da Apigee per inviare una richiesta alla destinazione, ma è sufficiente per il test, poiché si trova nella stessa subnet.
   2. Questo è un indirizzo IP usato in Google Cloud: lascia deselezionata a meno che l'indirizzo non sia in uno dei tuoi progetti Google Cloud. Se selezioni questo valore, fornisci anche il progetto e la rete.
   3. Inserisci l'indirizzo di destinazione (passaggio 1) e la porta rispettivamente come Indirizzo IP di destinazione e Porta di destinazione.
   
4. Fai clic su Crea e attendi che il test termini la prima esecuzione.
5. Nell'elenco dei test di connettività, fai clic su Visualizza per vedere i risultati dell'esecuzione.
6. Se il risultato è "Non raggiungibile", significa che hai un problema con la configurazione. Lo strumento dovrebbe indirizzarti alla documentazione relativa agli stati di Connectivity Tests per andare avanti. Se lo stato è "Accessibile", sono esclusi molti problemi di configurazione. Tuttavia, questo non garantisce che il target sia raggiungibile. Non c'è stato un tentativo effettivo di stabilire una connessione TCP con la destinazione. Solo la prossima diagnostica riportata di seguito ti aiuterà a testarlo.
   
   

Test di connettività delle VM (tutti i target)

1. Nello stesso VPC in peering con Apigee, crea un'istanza VM su Linux.
2. Esegui test di connettività dalla VM, preferibilmente nel momento in cui il problema è riproducibile da Apigee. Puoi utilizzare telnet, curl e altre utilità per stabilire una connessione. Questo esempio di curl viene eseguito in un loop con un timeout di tre secondi. Se curl non è in grado di stabilire una connessione TCP entro tre secondi, non riesce.

   for i in {1..100}; do curl -m 3 -v -i https://[TARGET_HOSTNAME] ; sleep 0.5 ; done

3. Controlla l'output completo e cerca questo errore:

   * Closing connection 0
    curl: (28) Connection timed out after 3005 milliseconds

   La presenza di questo errore conferma che il problema è riproducibile al di fuori di Apigee.

   Tieni presente che se vengono visualizzati altri errori, ad esempio errori relativi a TLS, codici di stato errati e così via, non confermano il timeout della connessione e non sono correlati a questo problema.

4. Se la destinazione richiede la lista consentita IP, potresti non essere in grado di testarla da una VM a meno che non autorizzi anche l'IP di origine dell'istanza VM.

Risoluzione

Se hai identificato un problema in base ai Connectivity Tests, procedi con i passaggi di risoluzione documentati.

Se il timeout viene riprodotto da una VM, non esistono indicazioni definitive su come risolvere il problema sul lato di destinazione. Quando il timeout della connessione è riproducibile all'esterno di Apigee, analizza ulteriormente il problema dal VPC. Prova a testare la connettività il più vicino possibile alla destinazione.

Se la destinazione è protetta da una connessione VPN, potresti riuscire a testarla anche dalla rete locale.

Se la destinazione è su internet, potresti provare a riprodurre il problema all'esterno della console Google Cloud.

Se il problema si verifica nelle ore di punta, la destinazione potrebbe essere sovraccarica di connessioni.

Se in questa fase devi inviare una richiesta di assistenza per Google Cloud, non devi più selezionare il componente Apigee, poiché il problema è ora riproducibile direttamente dal VPC.

Causa: lista consentita IP nella destinazione con alcuni o tutti gli IP Apigee NAT non aggiunti

Diagnosi

Riguarda le destinazioni esterne (Internet) con la lista consentita degli IP abilitata. Assicurati che tutti gli IP Apigee NAT vengano aggiunti sul lato di destinazione interessato. Se nella destinazione non è presente una lista consentita, puoi saltare questa sezione.

Il problema è più facile da individuare se gli errori sono intermittenti, perché in questo caso potresti riuscire a trovare una correlazione tra determinati IP NAT e gli errori.

Se il problema persiste (tutte le chiamate non vanno a buon fine), assicurati che gli IP NAT siano abilitati su Apigee e recuperali seguendo questi passaggi:

Elenca gli IP NAT per un'istanza:

curl -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG_ID/instances/$INSTANCE_NAME/natAddresses"

Un esempio di risposta:

{
  "natAddresses": [
    {
      "name": "nat-1",
      "ipAddress": "35.203.160.18",
      "state": "ACTIVE"
    },
    {
      "name": "nat-2",
      "ipAddress": "35.230.14.174",
      "state": "RESERVED"
    }
  ]
}

Se non ricevi indirizzi nell'output, gli IP NAT non vengono aggiunti sul lato Apigee. Se ricevi indirizzi, ma nessuno di questi è ATTIVO, nessuno degli indirizzi utilizzati consente l'accesso a internet, il che rappresenta un problema.

Se disponi di almeno un indirizzo ATTIVO, questo può essere inserito nella lista consentita a livello di destinazione. Di conseguenza, non sono presenti errori di configurazione sul lato Apigee. In questo caso, l'indirizzo potrebbe non essere presente nella lista consentita nella destinazione.

Se il problema è intermittente, potrebbe indicare che solo un sottoinsieme di IP NAT è stato consentito nella destinazione. Per identificarlo:

1. Creare un nuovo proxy inverso in cui la destinazione interessata è specificata in TargetEndpoint. Puoi anche riutilizzare il proxy esistente e andare al passaggio successivo:
   
   
2. Aggiungi un criterio ServiceCallout in Request PreFlow. Il ServiceCallout deve chiamare "https://icanhazip.com", "https://mocktarget.apigee.net/ip" o qualsiasi altro endpoint pubblico che restituisce l'indirizzo IP del chiamante nella risposta. Archivia la risposta nella variabile "response" in modo che il contenuto sia visibile in Debug. Ecco un esempio di configurazione del criterio ServiceCallout:
   

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <ServiceCallout continueOnError="false" enabled="true" name="Service-Callout-1">
       <DisplayName>Service Callout-1</DisplayName>
       <Properties/>
       <Request clearPayload="true" variable="myRequest">
           <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
       </Request>
       <Response>response</Response>
       <HTTPTargetConnection>
           <Properties/>
           <URL>https://icanhazip.com</URL>
       </HTTPTargetConnection>
   </ServiceCallout>

   Puoi anche memorizzare la risposta in una variabile personalizzata, ma dovresti leggere il file ".content" di questa variabile con il criterioAssignMessage per mostrarla nello strumento di debug.

   Assicurati che la destinazione sia configurata nello stesso modo esatto del proxy interessato.

   Nota: la richiesta ServiceCallout e la richiesta Target devono avvenire entrambe in un'unica transazione. Questo serve a garantire che lo stesso server elabori una richiesta in modo che l'IP NAT della richiesta interessata corrisponda all'IP NAT ottenuto da ServiceCallout.
3. Esegui una sessione di debug e fai clic sul passaggio ServiceCallout:
   
   
4. Nell'angolo in basso a destra, dovresti vedere una sezione Response content contenente l'IP NAT (nel corpo) dell'istanza Apigee che effettua la richiesta. In alternativa, se memorizzi la risposta ServiceCallout in una posizione diversa, dovresti vederla lì.
   
   Tieni presente che, più avanti nel flusso, il proxy chiamerà il target e i contenuti della risposta verranno sovrascritti con l'errore o una risposta del target.
5. Prova a correlare gli IP NAT al problema. Se noti che solo alcuni IP hanno errore, significa che alcuni, ma non tutti, sono nella lista consentita nella destinazione.
6. Se non vedi una correlazione tra gli IP NAT e gli errori, ad esempio, se lo stesso IP non funziona in una richiesta, ma non nell'altra, molto probabilmente non si tratta di un problema di inserimento nella lista consentita. Potrebbe trattarsi di un'esaurimento della funzionalità NAT. Vedi Causa: esaurimento della porta IP NAT.

Risoluzione

Assicurati di aver eseguito il provisioning e l'attivazione degli IP NAT e che vengano aggiunti tutti sul lato di destinazione.

Causa: esaurimento della porta IP NAT

Diagnosi

Nota: questa causa non è comune ed è rilevante se il problema non è riproducibile dal tuo VPC o da qualsiasi altra posizione al di fuori di Apigee. Se non hai eseguito il test, consulta la sezione Problema di connettività nella destinazione sopra per le indicazioni. Inoltre, questa sezione non è pertinente se non utilizzi IP NAT.

Se il problema è riproducibile solo da Apigee e viene eseguito il provisioning di IP NAT per la tua organizzazione e vedi che si verifica contemporaneamente per destinazioni diverse, è possibile che le porte di origine NAT siano esaurite:

1. Prendi nota del periodo di tempo in cui si è verificato il problema. Ad esempio: ogni giorno tra le 17:58 e le 18:08.
2. Verifica se altre destinazioni sono interessate dal problema nello stesso lasso di tempo. L'altra destinazione deve essere accessibile via internet e non deve essere ospitata nella stessa località della destinazione originale interessata.
3. Stabilisci se gli errori si verificano solo al di sopra di un determinato volume di traffico in TPS. A questo scopo, prendi nota dell'intervallo di tempo in cui si è verificato il problema e vai alla dashboard Prestazioni proxy.
4. Prova a correlare la finestra temporale dell'errore con l'aumento delle transazioni medie al secondo (tps).

In questo esempio, il tps sale a 1000 alle 17:58. Supponendo che, in questo esempio, le 17:58 siano il momento esatto in cui si verifica il problema e che quest'ultimo riguardi due o più obiettivi non correlati, questo è un segnale di un problema di esaurimento di NAT.

Risoluzione

Ricalcola i requisiti IP NAT seguendo le istruzioni in Calcolo dei requisiti IP NAT statici.

Puoi anche aggiungere altri IP NAT e vedere se il problema si risolve. Tieni presente che l'aggiunta di altri IP potrebbe richiedere prima di inserirli nella lista consentita in tutte le destinazioni.

Causa: il valore di connect.timeout.millis è impostato su un valore troppo basso

Diagnosi

Il valore di timeout potrebbe essere configurato in modo errato nel proxy.

Per verificare, vai al proxy interessato e controlla il TargetEndpoint in questione. Osserva la proprietà "connect.timeout.millis" e il suo valore. In questo esempio, il valore è 50, ovvero 50 millisecondi e in genere è troppo basso per garantire lo stabilire una connessione TCP. Un valore inferiore a 1000 è probabilmente la causa del problema. Se non vedi la proprietà "connect.timeout.millis", significa che è impostato il valore predefinito e la causa non è confermata.

Risoluzione

Correggi il valore connect.timeout.millis, assicurandoti che le unità di tempo siano espresse in millisecondi. Il valore predefinito è 3000, ovvero 3000 millisecondi. Per maggiori informazioni, consulta il riferimento sulle proprietà degli endpoint.

Contatta l'assistenza per ulteriore supporto

Se il problema persiste dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche per l'assistenza Google Cloud:

1. ID progetto e nome organizzazione Apigee
2. Nomi del proxy e ambiente
3. Periodo di tempo in cui si è verificato il problema
4. Frequenza del problema
5. Nome host di destinazione
6. Sessione di debug con il problema
7. Risultato dei controlli eseguiti per le possibili cause sopra indicate. Ad esempio, l'output del comando curl da una VM