Risolvere i problemi dei test di connettività

Utilizza le seguenti indicazioni per risolvere i problemi comuni relativi a Connectivity Tests.

Per saperne di più su Connectivity Tests, consulta la panoramica.

Per interpretare gli stati di un'analisi della configurazione di Connectivity Test s, consulta Stati dell'analisi della configurazione.

Problemi generici

I risultati dei test richiedono troppo tempo

Poiché Connectivity Tests esegue query sullo snapshot più recente di una configurazione di rete Virtual Private Cloud (VPC), la visualizzazione dei risultati può richiedere un po' di tempo. Per maggiori dettagli, consulta i tempi di risposta previsti per le query.

Se riscontri latenze lunghe o instabili durante l'esecuzione di Connectivity Tests, segnala il problema all' assistenza e descrivi come riprodurre it.

L'analisi della configurazione del mio test non rileva la modifica alla configurazione che ho apportato

Dopo aver apportato una modifica alla configurazione delle Google Cloud risorse nel percorso di test, potresti voler utilizzare l'analisi della configurazione del test per convalidare la modifica. Tuttavia, Connectivity Tests impiega tra 20 e 120 secondi per ricevere un aggiornamento della configurazione e incorporarlo nell'analisi. Per le risorse Google Kubernetes Engine (GKE), questo processo può richiedere fino a 15 minuti. Tieni conto di questo tempo aggiuntivo prima di eseguire i test.

Il completamento di alcuni tipi di configurazioni può richiedere più tempo. Se la modifica alla configurazione non viene verificata da Connectivity Tests dopo un periodo di tempo prolungato ed è riproducibile, segnala il problema all' assistenza e descrivi come riprodurlo.

Questo ritardo non si applica all'analisi del piano dati in tempo reale. Di conseguenza, potresti notare una mancata corrispondenza temporanea tra i risultati mostrati dall'analisi del piano dati in tempo reale e dall'analisi della configurazione. Ad esempio, se crei una regola firewall, l'analisi del piano dati in tempo reale in genere risponde immediatamente alla nuova regola. Tuttavia, potresti dover attendere 20 secondi o più prima che l'analisi della configurazione possa valutare la regola firewall insieme alle altre risorse nel percorso di test.

Problemi relativi allo stato del test

Non riesco ad accedere ai dettagli di un criterio firewall gerarchico

La traccia del test potrebbe fare riferimento a un criterio policy del firewall gerarchico che non hai l'autorizzazione a visualizzare.

Tuttavia, anche se non hai l'autorizzazione a visualizzare il criterio, puoi comunque vedere le regole del criterio che si applicano alla tua rete VPC. Per maggiori dettagli, consulta Regole firewall effettive nella panoramica dei criteri firewall gerarchici.

L'accesso ai criteri firewall gerarchici è definito a livello di organizzazione e cartella. Per informazioni dettagliate sulle autorizzazioni necessarie per visualizzare questi criteri, consulta Ruoli Identity and Access Management (IAM) nella panoramica dei criteri firewall gerarchici.

Il mio test mostra uno stato finale dell'analisi della configurazione Deliver, ma la connettività è interrotta

In alcuni casi, l'analisi della configurazione suggerisce che un endpoint di origine e di destinazione sono raggiungibili. Tuttavia, potresti scoprire che, in pratica, la connettività tra i due endpoint è interrotta o che l'analisi del piano dati in tempo reale mostra una perdita di pacchetti del 100%.

Per comprendere questa situazione, ricorda che Connectivity Tests utilizza due tipi di analisi: un' analisi della configurazione, che rileva i problemi nelle configurazioni attive all'interno del progetto, e l'analisi del piano dati in tempo reale, che invia probe sul piano dati.

Uno stato finale dell'analisi della configurazione Deliver indica che Connectivity Tests non ha rilevato problemi di configurazione. Tuttavia, potrebbero comunque esserci problemi relativi al percorso dei dati che causano problemi di connettività. Per risolvere i problemi, considera quanto segue:

  • La VM di origine o di destinazione presenta problemi del sistema operativo guest, ad esempio un kernel panic del sistema operativo guest, un controller dell'interfaccia di rete (NIC) non inizializzato o driver di rete incompatibili. Controlla lo stato della VM e la configurazione della NIC.
  • Un problema diffuso influisce sul piano dati di rete. Consulta la Performance Dashboard del tuo progetto, prestando particolare attenzione alla perdita di pacchetti per la coppia di zone pertinente. Inoltre, controlla la Google Cloud dashboard dello stato.
  • La tua rete presenta problemi di programmazione di rete sporadici, ad esempio problemi di propagazione della configurazione di rete a entità specifiche Google Cloud. Valuta la possibilità di eseguire di nuovo il test dopo un ritardo di cinque minuti. Se il problema persiste, arresta e avvia la VM di origine o di destinazione, come descritto in Arrestare e avviare un'istanza, quindi esegui di nuovo il test.

Il mio test ha restituito un risultato complessivo dell'analisi della configurazione Undetermined

Un risultato di raggiungibilità complessivo Undetermined indica che l'analisi della configurazione non è riuscita a determinare la connettività. Questo risultato può essere visualizzato per uno dei seguenti motivi:

  • Si è verificato un errore di autorizzazioni, ad esempio l'utente potrebbe non avere le autorizzazioni di lettura per tutte le risorse denominate nel test.
  • Si è verificato un errore interno.
  • L'analizzatore ha ricevuto un argomento non valido o non supportato oppure non è riuscito a identificare un endpoint noto.
  • Stai tentando di verificare una route che si estende oltre Google Cloud. Connectivity Tests non ha accesso alle configurazioni di rete esterne outside Google Cloud.

Il mio test ha restituito un risultato complessivo dell'analisi della configurazione Ambiguous

Un risultato complessivo dell'analisi della configurazione Ambiguous indica che Connectivity Tests ha restituito più tracce e che esiste uno stato finale misto.

La seguente tabella elenca alcuni motivi e correzioni comuni per questo stato.

Motivo Esempio Soluzione
La località di origine non è univoca. Hai specificato un indirizzo IP di origine interno senza specificare anche la rete VPC in cui si trova l'indirizzo IP (un indirizzo IP di origine interno è un indirizzo a cui non puoi accedere da internet). Poiché è possibile accedere a questo indirizzo da più reti VPC, Connectivity Tests potrebbe avviare una traccia da ogni località. Aggiorna il test con la rete VPC in cui si trova questo indirizzo IP.
La traccia ha più destinazioni possibili. La destinazione Trace è un bilanciatore del carico con più backend o un backend con un criterio di selezione dell'indirizzo IP PREFER_IPV6 e non tutti i backend sono raggiungibili per tutte le versioni IP configurate. Indaga sul motivo di questo problema e risolvi i problemi, se necessario, prima di eseguire di nuovo il test.

Il mio test ha restituito un risultato complessivo dell'analisi della configurazione Abort con un messaggio Invalid Argument

Di seguito sono riportati alcuni motivi comuni per un messaggio Invalid Argument:

  • L'indirizzo IP che hai fornito non è supportato. Esempi includono un indirizzo di loopback, un indirizzo IP multicast o un indirizzo IPv6 a un'istanza VM a cui è assegnato solo un indirizzo IPv4.
  • L'istanza VM o la rete specificata non esiste. Questa situazione può verificarsi quando l'istanza VM o la rete VPC è stata eliminata durante la creazione del test.

Quando si utilizza l'API Network Management, il messaggio Invalid Argument viene in genere restituito per uno dei seguenti motivi:

  • Un nome con errori di ortografia o una località errata per l'URI della VM o della rete.
  • Un ID progetto specificato in modo errato. Questo errore si verifica se hai utilizzato il nome del progetto anziché l'ID progetto.
  • Una mancata corrispondenza tra l'indirizzo IP interno specificato e la rete selezionata. Anche se la Google Cloud console per Connectivity Tests esegue una convalida rigorosa dell'istanza Compute Engine, della rete e del progetto specificati, questo tipo di mancata corrispondenza può comunque verificarsi.

Il risultato dell'analisi della configurazione è Packet could not be delivered, ma l'analisi del piano dati in tempo reale indica che tutti i pacchetti sono stati consegnati

Questa apparente mancata corrispondenza può verificarsi per diversi motivi. Considera le seguenti possibili cause e soluzioni:

  • Le recenti modifiche alla configurazione della rete VPC hanno causato un'incoerenza tra l'analisi della configurazione e il probing attivo. Esegui di nuovo il test, assicurandoti, se possibile, che la configurazione di rete non cambi immediatamente prima o durante il test.

  • Si sono verificati problemi di programmazione di rete sporadici. Arresta e avvia la VM di origine o di destinazione, come descritto in Arrestare e avviare un'istanza, quindi esegui di nuovo il test.

Il risultato dell'analisi della configurazione è Packet could be delivered, ma l'analisi del piano dati in tempo reale indica una perdita di pacchetti parziale

Questa apparente mancata corrispondenza può verificarsi per diversi motivi. Le possibili cause e soluzioni includono le seguenti:

  • La VM di origine o di destinazione è soggetta a limitazione mentre supera la larghezza di banda in uscita o in entrata consentita. Analizza il volume di traffico della VM andando alla pagina dei dettagli dell'istanza VM ed esaminando i dettagli nella scheda Monitoraggio. Esamina la metrica Byte di rete e confrontala con i limiti di larghezza di banda descritti per il tipo di macchina in Larghezza di banda di rete.

  • Un problema diffuso influisce sul piano dati di rete. Consulta la Performance Dashboard del tuo progetto, prestando particolare attenzione alla coppia di zone pertinente. Inoltre, controlla la Google Cloud dashboard dello stato.

Il risultato dell'analisi della configurazione è Packet could be delivered e l'analisi del piano dati in tempo reale mostra la consegna completa, ma la mia applicazione subisce perdite

Questa apparente mancata corrispondenza può verificarsi per diversi motivi. Le possibili cause e soluzioni includono le seguenti:

  • Il traffico potrebbe essere bloccato dal sistema operativo guest (ad esempio, dalle regole firewall interne). Verifica che il traffico non sia bloccato e riprova a eseguire il test.
  • I pacchetti di dati dell'applicazione potrebbero attraversare un percorso di rete diverso rispetto alle probe di analisi del piano dati in tempo reale. Valuta la possibilità di ristabilire la connessione di rete. Ad esempio, prova a utilizzare una porta di origine diversa.
  • L'analisi del piano dati in tempo reale rileva la perdita di pacchetti unidirezionale. Nel tuo caso, la perdita di pacchetti potrebbe verificarsi sul percorso di ritorno. Valuta la possibilità di eseguire un test nella direzione opposta.

I risultati dei test non includono un risultato dell'analisi del piano dati in tempo reale

Non tutte le configurazioni supportate da Connectivity Tests possono essere verificate con l'analisi del piano dati in tempo reale. Assicurati che il test soddisfi le condizioni richieste per l'analisi del piano dati in tempo reale, come specificato nella panoramica.

L'API di gestione della rete ha restituito un INTERNAL_ERROR

Questo evento non dovrebbe verificarsi normalmente. In caso contrario, segnala il problema all' assistenza e descrivi come riprodurlo.

Cause di interruzione specifiche

Questa sezione descrive scenari specifici che possono causare l'interruzione di un test, fornendo le cause probabili e i consigli per ciascuno.

Nessun intervallo IP serverless

Il test è stato interrotto perché alla revisione o al job non sono assegnati indirizzi in uscita VPC diretti.

Causa probabile

Per i servizi o i job Cloud Run configurati con il traffico in uscita VPC diretto, gli indirizzi IP allocati sono temporanei. Questi indirizzi vengono allocati solo quando la revisione gestisce attivamente il traffico o il job è in esecuzione. Questo problema si verifica in genere quando non viene inviato traffico attivo alla revisione Cloud Run o il job non è in esecuzione.

Per saperne di più sulla durata della conservazione degli indirizzi IP, consulta Consumo di indirizzi IP per servizi e pool di worker.

Consigli

  1. Visualizza gli indirizzi IP allocati per la revisione o il job come descritto in Visualizzare gli indirizzi IP allocati.
  2. Verifica che gli indirizzi IP siano in uso da Serverless e siano associati alla subnet configurata per la revisione o il job Cloud Run. Se non sono presenti indirizzi IP di questo tipo, invia traffico alla revisione Cloud Run o esegui il job per attivare l'allocazione.

Google Cloud Problemi relativi alla console

La Google Cloud console per Connectivity Tests si è arrestata in modo anomalo

La Google Cloud console non dovrebbe arrestarsi in modo anomalo. In caso contrario, segnala il problema all'assistenza e descrivi come riprodurlo.

Passaggi successivi