Connectivity Tests può rilasciare un pacchetto di test per qualsiasi dei seguenti motivi.
Per un elenco completo dei possibili motivi, consulta Stati dell'analisi della configurazione.
Indirizzo IP estero non consentito
Il pacchetto viene ignorato perché un'istanza Compute Engine può inviare o Ricevere pacchetti con un indirizzo IP esterno solo quando l'IP forwarding è abilitato.
Probabile causa
L'IP forwarding non è abilitato per l'istanza VM, ma l'origine o all'indirizzo IP di destinazione del pacchetto che sta passando non corrisponde gli indirizzi IP dell'istanza. Questo può accadere, ad esempio, quando il pacchetto viene vengono consegnati all'istanza utilizzando una route statica con l'istanza VM come hop successivo.
Consigli
Crea un'istanza Compute Engine con l'IP forwarding abilitato oppure imposta l'attributo corrispondente per l'istanza esistente. Per ulteriori informazioni, vedi Abilitare l'IP forwarding per le istanze.
Ignorato a causa di una regola del firewall
Il pacchetto può essere ignorato a causa di una regola firewall, tranne quando viene consentito a causa del monitoraggio della connessione.
Probabile causa
Connectivity Tests potrebbe rifiutare un pacchetto di test perché corrisponde a un che bloccano una regola firewall o una regola del criterio firewall. Tuttavia, il piano dati effettivo potrebbe consentire il passaggio del pacchetto a causa del monitoraggio della connessione nella regola del firewall. Il monitoraggio delle connessioni consente connessione esistente da restituire nonostante la regola firewall.
Ogni rete VPC ha due regole firewall implicite che consentono il traffico in uscita verso qualsiasi luogo e bloccano il traffico in entrata ovunque. Potresti anche avere una regola firewall per il traffico in uscita da negare la priorità più alta.
Affinché la connettività vada a buon fine, è necessaria una regola firewall in uscita all'origine che consente l'accesso all'endpoint di destinazione e una regola firewall in entrata la destinazione per consentire questa connessione.
Le regole firewall VPC sono stateful. Se l'endpoint di destinazione specificato è normalmente il lato che avvia la comunicazione, il traffico di risposta è consentito automaticamente con il monitoraggio delle connessioni e non è necessaria una regola del firewall in entrata.
Consigli
Elimina la regola di rifiuto o crea una regola di autorizzazione in base ai dettagli riportati nei risultati dei test di connettività. Per ulteriori informazioni, vedi Criteri firewall e Utilizza le regole firewall VPC.
Ignorato per assenza di route corrispondenti
Il pacchetto viene eliminato a causa della mancanza di route corrispondenti.
Probabile causa
Non esiste una route attiva che corrisponda agli attributi del pacchetto (ad esempio un indirizzo IP di destinazione) nella rete e nella regione del pacchetto.
Consigli
Verifica l'elenco delle route effettive nella console Google Cloud. Se hai appena creato un nuovo percorso, tieni presente che potrebbe essere necessario del tempo perché Connectivity Tests riceva un aggiornamento della configurazione e lo incorpori nell'analisi.
Se provi ad accedere all'endpoint di destinazione utilizzando il suo indirizzo IP interno, e assicurarsi che le reti di origine e di destinazione siano connesse (ad esempio utilizzando il peering di rete VPC, Centro connettività di rete o una soluzione di connettività ibrida come Cloud VPN).
Tieni presente che il peering VPC transitorio non è supportato. Valuta la possibilità di collegare le reti di origine e di destinazione o utilizzando una soluzione di connettività ibrida.
Se provi ad accedere all'endpoint di destinazione tramite internet, assicurati che hai una route per l'indirizzo IP di destinazione con l'hop successivo un gateway internet standard.
Se il pacchetto passa attraverso il gruppo di endpoint di rete con connettività ibrida, prendi in considerazione i requisiti aggiuntivi per l'applicabilità delle route. Alcune route visualizzate nella tabella della visualizzazione route potrebbero non essere disponibili per il traffico proveniente da NEG ibride.
Per ulteriori informazioni, consulta Route e Utilizzare le route.
Il pacchetto viene inviato a una rete errata
Il pacchetto viene inviato a una rete non intenzionale. Ad esempio, esegui un
test da un'istanza Compute Engine nella rete network-1 all'istanza Compute Engine nella rete network-2, ma il pacchetto viene inviato alla rete network-3.
Causa probabile
La rete network-1 ha una route con un intervallo di destinazione che include
indirizzo IP dell'istanza di destinazione con l'hop successivo in una rete diversa
(network-3 nell'esempio sopra).
Consigli
Verifica l'elenco delle route operative e l'elenco di route applicabili all'istanza di origine, nella console Google Cloud. Per ulteriori informazioni sulla creazione delle route e applicability, vedi Route e Utilizza route.
L'indirizzo IP dell'hop successivo della route non è stato risolto
Il pacchetto viene inviato a una destinazione utilizzando una route non valida con l'IP dell'hop successivo non assegnato ad alcuna risorsa.
Probabile causa
Se si tratta di una route con next-hop-address, l'indirizzo dell'hop successivo deve essere
un indirizzo IPv4 interno primario o un indirizzo IPv6 di Compute Engine
nella rete VPC della route. Gli indirizzi nelle reti in peering non sono
supportati.
Se si tratta di una route con next-hop-ilb, l'indirizzo dell'hop successivo deve essere una
dell'indirizzo del bilanciatore del carico di rete passthrough interno (regole di forwarding utilizzate da altri bilanciatori del carico,
o perché gli endpoint Private Service Connect non sono
supportati). L'indirizzo IP deve essere assegnato a una risorsa nella rete VPC della route o in una rete connessa tramite il peering di rete VPC.
Consigli
Verifica che l'indirizzo IP dell'hop successivo appartenga a una risorsa supportata. Per maggiori informazioni informazioni, consulta Considerazioni sulle istanze dell'hop successivo e Considerazioni sugli hop successivi del bilanciatore del carico di rete passthrough interno.
L'istanza dell'hop successivo della route ha un NIC nella rete errata
Il pacchetto viene inviato a una destinazione utilizzando una route non valida con l'istanza Compute Engine dell'hop successivo che non ha un controller di interfaccia di rete (NIC) nella rete della route.
Causa probabile
L'istanza Compute Engine utilizzata come hop successivo della route deve avere un NIC nella rete della route (non una rete VPC in peering).
Consigli
Verifica che l'istanza Compute Engine dell'hop successivo abbia un NIC nella rete della route. Per ulteriori informazioni, consulta Considerazioni per le istanze di hop successivo.
L'indirizzo dell'hop successivo della route non è un indirizzo IP principale della VM
Il pacchetto viene inviato a una destinazione utilizzando una route non valida con l'indirizzo IP dell'hop successivo (next-hop-address) che non è un indirizzo IP principale dell'istanza Compute Engine.
Causa probabile
L'indirizzo IP dell'hop successivo della route (next-hop-address) deve essere un indirizzo interno principale
Indirizzo IPv4 dell'istanza Compute Engine.
Gli intervalli di indirizzi IP alias non sono supportati.
Consigli
Verifica che l'indirizzo IP dell'hop successivo sia un indirizzo IPv4 interno principale del di Compute Engine. Per ulteriori informazioni, consulta Considerazioni per le istanze di hop successivo.
Il tipo di regola di forwarding dell'hop successivo della route non è valido
Il pacchetto viene inviato a una destinazione utilizzando una route non valida con la regola di inoltro dell'hop successivo (next-hop-ilb) che non è una regola di inoltro del bilanciatore del carico di rete passthrough interno.
Causa probabile
La regola di forwarding dell'hop successivo della route deve essere una regola di forwarding del bilanciatore del carico di rete passthrough interno. Per ulteriori informazioni, consulta Considerazioni per gli hop successivi del bilanciatore del carico di rete passthrough interno.
Consigli
Crea una route che abbia come target una regola di forwarding supportata anziché quella non valida percorso.
Traffico privato verso internet
Un pacchetto con un indirizzo di destinazione interno è stato inviato a un gateway internet.
Probabile causa
L'indirizzo IP di destinazione del pacchetto è un indirizzo IP privato, che non può essere raggiunto tramite internet. Tuttavia, il pacchetto esce dall'istanza Compute Engine di origine e corrisponde a una route con il gateway internet di hop successivo.
Consigli
Se vuoi accedere alla destinazione tramite internet, assicurati che l'istanza Compute Engine di origine abbia connettività a internet, ad esempio che abbia un indirizzo IP esterno o che utilizzi Cloud NAT, e utilizza l'indirizzo IP esterno dell'endpoint di destinazione nel test.
Per accedere alla destinazione tramite il suo indirizzo IP interno, occorre stabilire la connettività (creare route) tra l'origine e reti di destinazione. Puoi farlo in uno dei seguenti modi:
- Se l'endpoint di destinazione si trova all'interno di una rete on-premise, utilizza un Centro connettività di rete o una soluzione di connettività ibrida, ad esempio Cloud VPN o Cloud Interconnect.
- Se il tuo endpoint di destinazione si trova all'interno di Google Cloud:
- Configura il peering di rete VPC tra reti VPC.
- Configura la VPN Cloud tra le reti VPC.
- Configura la connettività di rete utilizzando gli spoke VPC di Network Connectivity Center.
Se hai già una connessione alla rete di destinazione:
- La rete dell'endpoint di origine non ha una route attraverso questa connessione o utilizza la route predefinita che passa per il gateway internet. Verifica l'elenco delle route effettive e l'elenco delle route applicabili all'istanza di origine nella console Google Cloud. Per ulteriori informazioni sulla creazione e sull'applicabilità delle route, consulta Route e Utilizzare le route.
Se stai testando la connettività a una rete on-premise da una rete in peering, consulta questo esempio per informazioni su annunci personalizzati, modalità di routing della rete e scambio di route personalizzati.
Il peering di rete VPC transitivo non è supportato. Puoi utilizzare VPN o peering per questi due VPC reti.
L'accesso privato Google non è consentito
L'istanza Compute Engine con solo un indirizzo IP interno tenta di raggiungere l'indirizzo IP esterno delle API e dei servizi Google, ma l'accesso privato Google non è abilitato nella subnet dell'istanza.
Consigli
Puoi consentire all'istanza VM di Compute Engine di raggiungere l'IP esterno delle API e dei servizi Google in uno dei seguenti modi:
- Abilita l'accesso privato Google per nella subnet dell'istanza.
- Assegna un indirizzo IP esterno alla NIC di Compute Engine.
- Abilita Cloud NAT per la subnet dell'istanza VM.
L'accesso privato Google tramite tunnel VPN non è supportato
Un endpoint di origine con un indirizzo IP interno tenta di raggiungere l'indirizzo IP esterno delle API e dei servizi Google tramite il tunnel VPN su un'altra rete, ma l'accesso privato Google deve essere abilitato nella rete dell'endpoint di origine.
Probabile causa
Il pacchetto dall'endpoint di origine all'indirizzo IP esterno del server Google Le API e i servizi vengono instradati tramite il tunnel Cloud VPN, ma non è supportata.
Consigli
Se l'endpoint di origine è un endpoint Google Cloud (ad esempio un'istanza VM Compute Engine), valuta la possibilità di attivare l'accesso privato Google nella sottorete di origine.
Se l'endpoint di origine è un endpoint on-premise, consulta la sezione Accesso privato Google per gli host on-premise per istruzioni dettagliate.
Regola di forwarding non corrispondente
Il protocollo e le porte della regola di forwarding non corrispondono all'intestazione del pacchetto.
Causa probabile
Il pacchetto viene inviato utilizzando un protocollo non supportato dalla regola di forwarding. Oppure il pacchetto viene inviato a una porta di destinazione che non corrisponde alle porte supportate dalla regola di forwarding.
Consigli
Verifica il protocollo e le porte della regola di inoltro di destinazione.
Mancata corrispondenza della regione della regola di forwarding
Per la regola di forwarding non è abilitato l'accesso globale né la relativa regione che corrisponda alla regione del pacchetto.
Causa probabile
A seconda del bilanciatore del carico e del livello, viene regola di forwarding è globale o regionale. Per ulteriori dettagli, vedi la tabella dei tipi di bilanciatore del carico.
Se la regola di inoltro è a livello di regione, il client (ad esempio la VM o il connettore VPC) deve trovarsi nella stessa regione del bilanciatore del carico.
Consigli
Se ti connetti al bilanciatore del carico da un endpoint Google Cloud, ad esempio un'istanza VM di Compute Engine, assicurati che si trovi nella stessa regione della regola di inoltro.
Durante la connessione da una rete on-premise, assicurati che il client acceda al bilanciatore del carico tramite tunnel Cloud VPN o collegamenti VLAN che si trovano nella stessa regione del bilanciatore del carico. Per ulteriori dettagli, vedi Bilanciatori del carico delle applicazioni interni e reti connesse.
Puoi abilitare l'accesso globale su bilanciatori del carico delle applicazioni interni e bilanciatori del carico di rete proxy interni regionali per accedere ai client in qualsiasi regione. Per impostazione predefinita, i client di questi bilanciatori del carico devono trovarsi nella stessa regione come bilanciatore del carico. Per ulteriori informazioni, consulta Abilitare l'accesso globale per i bilanciatori del carico delle applicazioni interni e Abilitare l'accesso globale per i bilanciatori del carico di rete proxy interni regionali.
Firewall che blocca il controllo di integrità del backend del bilanciatore del carico
I firewall bloccano i probe del controllo di integrità verso i backend e causano il per il traffico proveniente dal bilanciatore del carico.
Causa probabile
Affinché i controlli di integrità funzionino, devi creare regole firewall di autorizzazione in entrata che consenti al traffico dai probe di Google Cloud di raggiungere i tuoi backend. In caso contrario, i backend vengono considerati non integri.
Consigli
Crea regole firewall di autorizzazione in entrata in base alla tabella Regole firewall e intervalli IP di controllo. Per maggiori informazioni, consulta la sezione Regole firewall obbligatorie.
Nessun indirizzo esterno disponibile
Un'istanza VM con solo un indirizzo IP interno ha tentato di accedere a host esterni tramite una route il cui hop successivo è il gateway internet predefinito. Si verifica quando Cloud NAT non è abilitato nella subnet o quando non è presente un'altra route predefinita che utilizza un tipo diverso di hop successivo (ad esempio una VM proxy).
Probabile causa
Un'istanza con solo un indirizzo IP interno ha tentato di accedere a un host esterno, ma non aveva un indirizzo IP esterno o Cloud NAT non era abilitato nella subnet.
Consigli
Se vuoi accedere a endpoint esterni, puoi assegnare indirizzo IP esterno alla tua istanza. In alternativa, puoi abilitare Cloud NAT sulla rispettiva subnet, a meno che connessione passa attraverso un'istanza proxy che dà accesso a internet.
Regola di forwarding senza istanze
La regola di forwarding non presenta backend configurati.
Probabile causa
La regola di inoltro che stai tentando di raggiungere non ha backend configurati.
Consigli
Controlla la configurazione del bilanciatore del carico e assicurati che il servizio di backend del bilanciatore del carico abbia i backend configurati.
Il tipo di traffico è bloccato
Il tipo di traffico è bloccato e non puoi configurare una regola firewall per abilitarlo. Per maggiori dettagli, consulta Traffico sempre bloccato.
Causa probabile
Questo tipo di traffico è bloccato per impostazione predefinita e non può essere attivato creando regole firewall. Gli scenari comuni sono i seguenti:
- Invio del traffico in uscita a una destinazione esterna con la porta TCP 25 (SMTP). Per ulteriori dettagli, vedi Traffico sempre bloccato.
- Invio di traffico a una porta non supportata su un'istanza Cloud SQL. Ad esempio, l'invio di traffico alla porta TCP 3310 a un'istanza MySQL Cloud SQL con la porta 3306 aperta.
- Invio di traffico in uscita da una versione dell'ambiente standard di App Engine, da una funzione Cloud Run o da una revisione Cloud Run che utilizza un protocollo diverso da TCP o UDP.
Consigli
Per il traffico SMTP in uscita (traffico in uscita verso una destinazione esterna con porta TCP 25), consulta Invio di email da un'istanza.
Per il protocollo DHCP, inclusi i pacchetti IPv4 UDP alla porta di destinazione 68 (risposte DHCPv4) e i pacchetti IPv6 UDP alla porta di destinazione 546 (risposte DHCPv6), il traffico DHCP è consentito solo dal server di metadati (169.254.169.254).
Per la connettività Cloud SQL, assicurati che la porta utilizzata sia corretta.
Il connettore di accesso VPC serverless non è configurato
Il pacchetto è stato ignorato perché la versione dell'ambiente standard App Engine, la funzione Cloud Run o la revisione di Cloud Run non ha un connettore di accesso VPC serverless configurato.
Causa probabile
L'indirizzo IP di destinazione è un IP privato indirizzo, che non può essere raggiunto tramite internet. Il pacchetto lascia l'origine, ma non c'è Connettore di accesso VPC serverless configurato per La versione dell'ambiente standard di App Engine, la funzione Cloud Run o la funzione Cloud Run revisione.
Consigli
Se provi ad accedere all'endpoint di destinazione utilizzando il suo indirizzo IP privato, assicurati di aver configurato un accesso VPC serverless per la versione dell'ambiente standard di App Engine, la funzione Cloud Run, o la revisione di Cloud Run.
Il connettore di accesso VPC serverless non è in esecuzione
Il pacchetto è stato ignorato perché il connettore di accesso VPC serverless non è in esecuzione.
Probabile causa
Il pacchetto è stato ignorato perché tutte le istanze del connettore Accesso VPC serverless sono state interrotte.
Consigli
Per un elenco delle procedure di risoluzione dei problemi, vedi Risoluzione dei problemi.
La connessione Private Service Connect non è accettata
Il pacchetto è stato eliminato perché la connessione Private Service Connect non è stato accettato.
Causa probabile
L'endpoint Private Service Connect si trova in un progetto che non è approvato per la connessione al servizio. Per maggiori informazioni, vedi Visualizzare i dettagli dell'endpoint.
Consigli
Assicurati che l'endpoint Private Service Connect si trovi in una progetto approvato per la connessione al servizio gestito.
È possibile accedere all'endpoint Private Service Connect da una rete in peering
Il pacchetto viene inviato all'endpoint Private Service Connect nella rete in peering, ma questa configurazione non è supportata.
Consigli
Valuta la possibilità di utilizzare uno dei pattern di connettività descritti nella pagina Pattern di implementazione di Private Service Connect. Puoi anche accedere alle API di Google e ai servizi pubblicati utilizzando Backend Private Service Connect.