Un caso d'uso comune di Connectivity Tests è il test tra due istanze di macchine virtuali (VM) Compute Engine nella stessa rete Virtual Private Cloud (VPC) o in peering.
Per questo tipo di test, Connectivity Tests valuta la connettività utilizzando sia l'analisi della configurazione sia l'analisi del piano dati in tempo reale. Per analizzare la configurazione, Connectivity Tests identifica e valuta un percorso di traccia.
I diagrammi di Trace in questa pagina utilizzano i simboli descritti nella seguente legenda.Il seguente diagramma mostra il tipico percorso di traccia tra due istanze VM. L'oggetto Match routes
può rappresentare route che indirizzano il traffico in una singola rete VPC o tra due reti VPC in peering.
I passaggi seguenti descrivono i punti di controllo corrispondenti a ciascun punto nel diagramma di traccia. A ogni checkpoint, il controllo potrebbe non riuscire. I risultati della query mostrano il motivo di ogni errore. Per un elenco completo degli stati e dei messaggi dei test, consulta Stati dell'analisi della configurazione.
Connectivity Tests verifica che la VM di origine possa inviare pacchetti in uscita con l'indirizzo IP di origine specificato, oppure può utilizzare come valore predefinito il processo di controllo dello spoofing.
-
Connectivity Tests esegue un controllo di spoofing quando un pacchetto simulato da o verso un'istanza VM utilizza un indirizzo IP non di proprietà di tale istanza. Gli indirizzi IP di proprietà di una VM includono tutti gli indirizzi IP interni e quelli secondari.
Se l'indirizzo sembra provenire da traffico esterno, chiamato anche indirizzo esterno, l'indirizzo IP non supera il controllo di spoofing.
Per determinare se i pacchetti di traccia possono essere inviati dall'origine, Connectivity Tests verifica le regole firewall in uscita appropriate. Nell'ambito di questo processo, Connectivity Tests inizia valutando qualsiasi regola esistente di criteri firewall gerarchici. Per maggiori dettagli su come le regole dei criteri firewall gerarchici e le regole firewall VPC influiscono sulla connettività, consulta Esempi di criteri firewall gerarchici.
Connectivity Tests trova (corrisponde) una route per l'indirizzo IP di destinazione, in base all'ordine di routing. Se non sono disponibili altre route per l'istanza VM di destinazione, Connectivity Tests utilizza la route statica predefinita con l'hop successivo come gateway internet. Tutte le reti VPC utilizzano questa route predefinita, a meno che tu non l'abbia rimossa.
Connectivity Tests verifica che le regole firewall in entrata della rete consentano al pacchetto di arrivare alla VM di destinazione. Anche in questo caso, Connectivity Tests inizia valutando eventuali regole di criterio firewall gerarchico esistenti.
Se necessario, Connectivity Tests esegue un controllo dello spoofing sul pacchetto che arriva alla seconda VM.
Connectivity Tests verifica che la VM di destinazione possa ricevere un pacchetto con l'indirizzo IP di destinazione specificato. Se questo indirizzo è un indirizzo IP esterno, la VM di destinazione deve avere l'IP forwarding abilitato. Un indirizzo IP esterno è un indirizzo che non appartiene alla VM.
Il seguente screenshot della console Google Cloud mostra i risultati di un test da VM a VM.
L'analisi della configurazione mostra un risultato di Il pacchetto potrebbe essere stato consegnato.
Nella risposta dell'API, questa etichetta corrisponde a uno
stato finale di Deliver
.
Questo risultato mostra che l'analisi della configurazione ha convalidato la connettività di rete per ogni risorsa Google Cloud nel percorso dalla VM di origine alla VM di destinazione. In questo caso, la route includeva due regole firewall VPC: una regola firewall VPC implicita (denominata default
) e una creata per questa rete VPC.
Inoltre, Connectivity Tests ha verificato dinamicamente che la VM di destinazione sia raggiungibile utilizzando probe attivi. Il campo Risultato ultima trasmissione pacchetto mostra i dettagli di questo risultato.
Puoi espandere ciascuna scheda nel percorso della traccia per visualizzare ulteriori dettagli.
L'esempio seguente mostra una scheda espansa per una regola firewall in entrata. Questa scheda include informazioni sulla rete VPC, sull'azione configurata per la regola firewall (consenti) e sulla priorità della regola.
Quando una traccia contiene una route di rete VPC con l'hop successivo come rete VPC in peering, l'inizio della traccia non è un'istanza VM, ma una rete VPC. Questo tipo di traccia convalida le regole e le route firewall a livello di rete, perché l'indirizzo IP che testi proviene da un intervallo di rete anziché da un'istanza VM.
Le reti in peering possono esistere nello stesso progetto o in progetti diversi. L'esempio di traccia riportato di seguito mostra le reti in peering in progetti diversi.
Errori di test per le reti VPC
La seguente tabella elenca gli errori comuni per i test all'interno delle reti VPC.
Tipo di errore | Descrizione | Risultati delle tracce |
---|---|---|
Bloccata da una regola firewall | Il traffico in uscita da un endpoint di origine o in entrata in un endpoint di destinazione è bloccato da una regola del criterio firewall gerarchico o da una regola firewall VPC. |
|
Nessuna route corrispondente | Impossibile trovare una route per l'endpoint di destinazione. |
|
Istanza non in esecuzione | L'istanza VM di destinazione esiste, ma non è in esecuzione. | L'analisi determina che il pacchetto potrebbe essere ignorato. |
Hop successivo non valido | L'hop successivo configurato per un'istanza VM non esiste più e la route per quell'istanza non è valida. | L'analisi determina che il pacchetto potrebbe essere ignorato. |
Il seguente screenshot mostra una traccia non riuscita perché la connettività è stata bloccata da una regola del criterio firewall gerarchico in entrata.
Errori di test per le reti VPC condiviso
Nelle reti VPC condivise, non disporre delle autorizzazioni per il progetto host o il progetto di servizio può causare gli errori di test elencati nella tabella seguente.
Tipo di errore | Comportamento | Risultati delle tracce |
---|---|---|
Autorizzazioni solo per il progetto host | Non puoi eseguire la traccia perché non hai le autorizzazioni per il progetto di servizio in cui si trova l'indirizzo IP di destinazione. | L'analisi della configurazione mostra un risultato di Analisi della configurazione interrotta. Nella risposta dell'API, questa etichetta corrisponde a uno
stato finale di
Abort . |
Autorizzazioni solo per il progetto di servizio |
Non puoi eseguire la traccia o selezionare la rete del progetto host nella console Google Cloud perché non hai l'autorizzazione. Poiché le configurazioni di rete sono di proprietà del progetto host, un'analisi delle risorse nel progetto di servizio non può procedere senza l'accesso alle regole firewall VPC, alle route di rete o agli indirizzi IP nel progetto host. |
Il risultato complessivo della connettività è
Undetermined
perché Connectivity Tests non riesce a determinare se il pacchetto può essere
consegnato alla destinazione. |
Errori di test delle reti di peering di rete VPC
Con il peering di rete VPC, non disporre dell'autorizzazione per il progetto Google Cloud della rete peered
dalla rete primary
può causare il risultato del test elencato nella seguente tabella.
Tipo di errore | Comportamento | Risultati delle tracce |
---|---|---|
Non disponi di autorizzazioni per la configurazione del progetto nella rete VPC in peering. | Connectivity Tests può tenere traccia solo delle configurazioni nel progetto della rete principale. | L'analisi della configurazione mostra un risultato di Il pacchetto potrebbe essere inoltrato.
Questo risultato indica che un pacchetto lascerebbe la rete e verrebbe inviato a una rete a cui non hai accesso. In questo caso, il pacchetto è stato inoltrato a un gateway di rete in peering. Nella risposta dell'API, questo stato corrisponde a uno stato finale di Forward . |
Il seguente percorso della traccia mostra lo stato di inoltro per le reti VPC in peering.
Passaggi successivi
- Scenari di test comuni
- Scopri di più su Connectivity Tests
- Risolvere i problemi relativi a Connectivity Tests