Un caso d'uso comune per Connectivity Tests è testare tra due Istanze di macchine virtuali (VM) Compute Engine nello stesso ambiente o in peering Reti Virtual Private Cloud (VPC).
Per questo tipo di test, Connectivity Tests valuta la raggiungibilità 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 della traccia.
I diagrammi di Trace in questa pagina utilizzano i simboli descritti nella seguente legenda.Il seguente diagramma mostra il percorso traccia tipico 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 checkpoint corrispondenti a ciascun punto del diagramma di traccia. Il controllo potrebbe non riuscire in qualsiasi punto di controllo. I risultati della query mostrano il motivo di ogni errore. Per un elenco completo degli stati dei test e messaggi, vedi Stati dell'analisi della configurazione:
I test di connettività verificano che la VM di origine possa inviare pacchetti in uscita con l'indirizzo IP di origine specificato oppure, in caso contrario, può utilizzare per impostazione predefinita la procedura di controllo dello spoofing.
-
Connectivity Tests eseguono un controllo di spoofing quando un pacchetto simulato verso o da un'istanza VM utilizza un indirizzo IP non di proprietà dell'istanza. Gli indirizzi IP di proprietà di una VM includono tutti gli indirizzi IP interni e secondari della VM.
Se l'indirizzo sembra provenire da traffico esterno, chiamato anche indirizzo straniero, l'indirizzo IP non supera il controllo dello spoofing.
a determinare se è possibile inviare pacchetti di traccia dall'origine, Connectivity Tests verifica l'adeguatezza e le regole firewall in uscita. Nell'ambito di questa procedura, Connectivity Tests inizia valutando eventuali regole di criteri firewall gerarchici esistenti. Per maggiori dettagli su come le regole dei criteri firewall gerarchici e VPC le regole firewall influiscono sulla connettività, vedi Esempi di criteri firewall gerarchici.
Connectivity Tests trova (associa) 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, i test di connettività utilizzano la route statica predefinita con l'hop successivo come gateway internet. Tutte le reti VPC lo utilizzano predefinito, a meno che tu non l'abbia rimosso.
Connectivity Tests verifica che le regole del firewall di 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 gerarchici esistenti.
Se necessario, Connectivity Tests esegue un controllo di spoofing sul pacchetto che arriva alla seconda VM.
I test di connettività verificano che la VM di destinazione possa ricevere un pacchetto con l'indirizzo IP di destinazione specificato. Se questo indirizzo è un un indirizzo IP esterno, la VM di destinazione deve avere in un bucket in cui è abilitato il controllo delle versioni. Un indirizzo IP esterno è un indirizzo che non appartiene alla VM.
Il seguente screenshot della console Google Cloud mostra i risultati di un test VM-to-VM.
L'analisi della configurazione mostra il risultato Il pacchetto potrebbe essere consegnato.
Nella risposta dell'API, questa etichetta corrisponde a un
stato finale di Deliver
.
Questo risultato indica che l'analisi di configurazione ha convalidato la connettività della 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 (chiamata default
) e una creata per questa rete VPC.
Inoltre, Connectivity Tests ha verificato dinamicamente che la VM di destinazione sia raggiungibile utilizzando il rilevamento attivo. Il campo Risultato dell'ultima trasmissione di pacchetto mostra i dettagli di questo risultato.
Puoi espandere ciascuna delle schede nel percorso della traccia per visualizzare ulteriori dettagli.
L'esempio seguente mostra una scheda espansa per una regola firewall di ingresso. Questa scheda include informazioni sulla rete VPC, l'azione configurata per la regola firewall (allow) e la 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 è una VM ma una rete VPC. Questo tipo di traccia convalida le regole e le route del firewall a livello di rete perché l'indirizzo IP sottoposto a test proviene da un intervallo di rete anziché da un'istanza VM.
Le reti in peering possono esistere nello stesso progetto o in progetti diversi. Le seguenti L'esempio di traccia mostra reti in peering in diversi progetti.
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 della traccia |
---|---|---|
Bloccata da una regola del firewall | Il traffico che esce da un endpoint di origine o che entra in un endpoint di destinazione è bloccato da un una regola firewall gerarchica o una regola firewall VPC. |
|
Nessun percorso corrispondente | Impossibile trovare una route all'endpoint di destinazione. |
|
Istanza non in esecuzione | L'istanza VM di destinazione esiste, ma non è in stato di 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 a quell'istanza non è valida. | L'analisi determina che il pacchetto potrebbe essere stato ignorato. |
Lo screenshot seguente mostra una traccia non riuscita perché la connettività è stata bloccata da una regola del criterio firewall gerarchico per il traffico in entrata.
Errori di test per reti VPC condiviso
Nelle reti VPC condivise, non si dispone delle autorizzazioni per l'host o il progetto di servizio possono causare gli errori dei test elencati nel seguente.
Tipo di errore | Comportamento | Risultati della traccia |
---|---|---|
Autorizzazioni solo per il progetto host | Non puoi eseguire la traccia perché non disponi delle autorizzazioni per progetto di servizio in cui si trova l'indirizzo IP di destinazione. | L'analisi della configurazione mostra il risultato Analisi della configurazione interrotta. Nella risposta dell'API, questa etichetta corrisponde a un
stato finale
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 disponi dell'autorizzazione. Poiché il progetto host è proprietario delle configurazioni di rete, viene eseguita una traccia le risorse nel progetto di servizio non possono procedere senza accesso a regole firewall VPC, route di rete o indirizzi IP nel progetto host. |
Il risultato complessivo di raggiungibilità è
Undetermined
perché Connectivity Tests non è in grado di determinare se il pacchetto può essere
vengono consegnati a destinazione. |
Errori di test per le reti del peering di rete VPC
Con il peering di rete VPC, non disponi dell'autorizzazione per peered
di un progetto Google Cloud dalla rete primary
può causare
il risultato del test riportato nella tabella seguente.
Tipo di errore | Comportamento | Risultati di Trace |
---|---|---|
Non disponi delle autorizzazioni per la configurazione del progetto nell'istanza in peering rete VPC. | I test di connettività possono tracciare solo le configurazioni nel progetto della rete principale. | L'analisi della configurazione mostra il risultato Il pacchetto potrebbe essere inoltrato.
Questo risultato indica che un pacchetto lascerà la rete e verrà 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 un
stato finale di
Forward . |
Il seguente percorso traccia mostra lo stato inoltrato per le reti VPC con peering.
Passaggi successivi
- Scenari di test comuni
- Scopri di più su Connectivity Tests
- Risolvere i problemi dei test di connettività