Connectivity Tests può rilasciare un pacchetto di test per uno dei seguenti motivi.
Per un elenco completo dei possibili motivi, vedi Stati dell'analisi della configurazione.
Indirizzo IP straniero 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
Nell'istanza VM non è abilitato l'IP forwarding, ma l'indirizzo IP di origine o di destinazione del pacchetto che lo attraversa non corrisponde agli indirizzi IP dell'istanza. Questo può accadere, ad esempio, quando il pacchetto viene consegnato all'istanza utilizzando una route statica con l'istanza VM come hop successivo.
Suggerimenti
Crea un'istanza Compute Engine con IP forwarding abilitato o imposta l'attributo corrispondente per l'istanza esistente. Per ulteriori informazioni, consulta Abilitare l'IP forwarding per le istanze.
Eliminato a causa di una regola firewall
Il pacchetto può essere ignorato a causa di una regola firewall, tranne quando il pacchetto è consentito a causa del monitoraggio della connessione.
Probabile causa
Connectivity Tests potrebbe rifiutare un pacchetto di test perché corrisponde a una regola firewall o a una regola di criterio firewall di blocco. Tuttavia, il piano dati effettivo potrebbe consentire il passaggio del pacchetto a causa del monitoraggio delle connessioni sulla regola firewall. Il monitoraggio delle connessioni consente la restituzione dei pacchetti per una connessione esistente nonostante la regola firewall.
Ogni rete VPC prevede due regole firewall implicite che consentono il traffico in uscita verso ogni luogo e bloccano il traffico in entrata da qualunque origine. Potresti anche avere una regola firewall per il traffico in uscita da negare a priorità più alta.
Affinché la connettività vada a buon fine, sono necessarie una regola firewall in uscita all'origine che consenta l'accesso all'endpoint di destinazione e una regola firewall in entrata nella destinazione per consentire questa connessione.
Le regole firewall VPC sono stateful. Se l'endpoint di destinazione specificato è in genere il lato che avvia la comunicazione, il traffico di risposta viene consentito automaticamente con il monitoraggio delle connessioni e non è necessaria una regola firewall in entrata.
Suggerimenti
Elimina la regola di negazione o creane una in base ai dettagli nei risultati di Connectivity Tests. Per maggiori informazioni, consulta Criteri firewall e Utilizzare le regole firewall VPC.
Eliminato a causa della mancanza di una route corrispondente
Il pacchetto viene eliminato a causa della mancanza di route corrispondenti.
Probabile causa
Non esiste una route attiva corrispondente agli attributi del pacchetto (come un indirizzo IP di destinazione) nella rete e nella regione dei pacchetti.
Suggerimenti
Verifica l'elenco delle route effettive nella console Google Cloud. Se hai appena creato una nuova route, tieni presente che potrebbe trascorrere del tempo prima che Connectivity Tests riceva un aggiornamento della configurazione e lo incorpora nell'analisi.
Se provi ad accedere all'endpoint di destinazione utilizzando il relativo indirizzo IP interno, assicurati che le reti di origine e di destinazione siano connesse (ad esempio, utilizzando il peering di rete VPC, il Centro connettività di rete o una soluzione di connettività ibrida come Cloud VPN).
Tieni presente che il peering VPC transitorio non è supportato. Potresti connettere le reti di origine e di destinazione direttamente o usando una soluzione di connettività ibrida.
Se provi ad accedere all'endpoint di destinazione tramite internet, assicurati di avere una route per l'indirizzo IP di destinazione con il gateway internet dell'hop successivo.
Se il pacchetto passa attraverso il gruppo di endpoint di rete con connettività ibrida, valuta ulteriori requisiti per l'applicabilità delle route. Alcune route che vedi nella tabella di visualizzazione delle route potrebbero non essere disponibili per il traffico proveniente da NEG ibridi.
Per ulteriori informazioni, vedi 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.
Probabile causa
La rete network-1 ha una route con un intervallo di destinazione che include l'indirizzo IP dell'istanza di destinazione con l'hop successivo in una rete diversa (network-3 nell'esempio precedente).
Suggerimenti
Verifica l'elenco di route effettive e l'elenco di route applicabili all'istanza di origine nella console Google Cloud. Per saperne di più sulla creazione e sull'applicability delle route, vedi Route e Utilizzare le 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'indirizzo 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 principale o un indirizzo IPv6 dell'istanza 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 un indirizzo del bilanciatore del carico di rete passthrough interno (le regole di forwarding utilizzate da altri bilanciatori del carico, il forwarding del protocollo o gli endpoint Private Service Connect non sono supportate). L'indirizzo IP deve essere assegnato a una risorsa nella rete VPC della route o in una rete connessa con il peering di rete VPC.
Suggerimenti
Verifica che l'indirizzo IP dell'hop successivo appartenga a una risorsa supportata. Per ulteriori informazioni, vedi Considerazioni per le 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'hop successivo, l'istanza Compute Engine che non ha un NIC (Network Interface Controller) nella rete della route.
Probabile causa
L'istanza Compute Engine utilizzata come hop successivo della route deve avere un NIC nella rete della route (non una rete VPC in peering).
Suggerimenti
Verifica che l'istanza Compute Engine dell'hop successivo abbia un NIC nella rete della route. Per ulteriori informazioni, consulta Considerazioni sulle istanze dell'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 in cui l'indirizzo IP dell'hop successivo (next-hop-address) non è un indirizzo IP principale dell'istanza Compute Engine.
Probabile causa
L'indirizzo IP dell'hop successivo della route (next-hop-address) deve essere un indirizzo IPv4 interno principale dell'istanza Compute Engine.
Gli intervalli di indirizzi IP alias non sono supportati.
Suggerimenti
Verifica che l'indirizzo IP dell'hop successivo sia un indirizzo IPv4 interno principale dell'istanza Compute Engine. Per ulteriori informazioni, consulta Considerazioni sulle istanze dell'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 e la regola di forwarding dell'hop successivo (next-hop-ilb) non è una regola di forwarding del bilanciatore del carico di rete passthrough interno.
Probabile causa
La regola di forwarding dell'hop successivo della route deve essere una regola di forwarding del bilanciatore del carico di rete passthrough interno. Per maggiori informazioni, consulta Considerazioni sugli hop successivi del bilanciatore del carico di rete passthrough interno.
Suggerimenti
Crea una route che abbia come target una regola di forwarding supportata anziché una route non valida.
Traffico privato su 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 è raggiungibile tramite internet. Tuttavia, il pacchetto lascia l'istanza Compute Engine di origine e abbina una route al gateway internet dell'hop successivo.
Suggerimenti
Se vuoi accedere alla destinazione tramite internet, assicurati che l'istanza Compute Engine di origine disponga di una connettività a internet, ad esempio che abbia un indirizzo IP esterno o utilizzi Cloud NAT, quindi utilizza l'indirizzo IP esterno dell'endpoint di destinazione nel test.
Per accedere alla destinazione tramite il suo indirizzo IP interno, devi stabilire la connettività (creare route) tra le reti di origine e di destinazione. Puoi farlo in uno dei seguenti modi:
- Se l'endpoint di destinazione si trova in una rete on-premise, utilizza una soluzione del Network Connectivity Center o una soluzione di connettività ibrida, come 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 le reti VPC.
- Configura Cloud VPN tra le reti VPC.
- Configura la connettività di rete utilizzando gli spoke VPC di Network Connectivity Center.
Se disponi già di 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 attraverso il gateway internet. Verifica l'elenco di route effettive e l'elenco di route applicabili all'istanza di origine nella console Google Cloud. Per maggiori informazioni sulla creazione e sull'applicability delle route, vedi Route e Utilizzare le route.
Se stai testando la connettività a una rete on-premise da una rete in peering, vedi questo esempio per la pubblicità personalizzata, la modalità di routing di rete e lo scambio di route personalizzate.
Il peering di rete VPC transitorio non è supportato. Puoi utilizzare la VPN o il peering per queste due reti VPC.
L'accesso privato Google non è consentito
L'istanza di 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.
Suggerimenti
Puoi consentire all'istanza VM di Compute Engine di raggiungere l'indirizzo IP esterno delle API e dei servizi Google in uno dei seguenti modi:
- Abilita l'accesso privato Google per la subnet dell'istanza.
- Assegna un indirizzo IP esterno al 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 delle API e dei servizi Google viene instradato tramite il tunnel Cloud VPN, ma questa configurazione non è supportata.
Suggerimenti
Se l'endpoint di origine è un endpoint Google Cloud (ad esempio un'istanza VM di Compute Engine), valuta la possibilità di abilitare l'accesso privato Google nella rispettiva subnet di origine.
Se l'endpoint di origine è un endpoint on-premise, consulta 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.
Probabile causa
Il pacchetto viene inviato utilizzando un protocollo non supportato dalla regola di forwarding oppure viene inviato a una porta di destinazione che non corrisponde alle porte supportate dalla regola di forwarding.
Suggerimenti
Conferma il protocollo e le porte della regola di forwarding di destinazione.
Mancata corrispondenza della regione della regola di forwarding
Per la regola di forwarding non è abilitato l'accesso globale e la sua regione non corrisponde a quella del pacchetto.
Probabile causa
A seconda del bilanciatore del carico e del relativo livello, una regola di forwarding è globale o regionale. Per maggiori dettagli, consulta la tabella dei tipi di bilanciatore del carico.
Se la regola di forwarding è a livello di regione, il client (ad esempio, la VM o il connettore VPC) deve trovarsi nella stessa regione del bilanciatore del carico.
Suggerimenti
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 forwarding.
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 maggiori dettagli, vedi Bilanciatori del carico delle applicazioni interni e reti connesse.
Puoi abilitare l'accesso globale sui bilanciatori del carico delle applicazioni interni e sui 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 del bilanciatore del carico. Per saperne di più, vedi Attivare l'accesso globale per i bilanciatori del carico delle applicazioni interni e Attivare 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 rendono non disponibili i backend per il traffico proveniente dal bilanciatore del carico.
Probabile causa
Affinché i controlli di integrità funzionino, devi creare regole firewall di autorizzazione in entrata che consentano al traffico dai probe di Google Cloud di raggiungere i tuoi backend. In caso contrario, i backend sono considerati in stato non integro.
Suggerimenti
Crea regole firewall di autorizzazione in entrata in base alla tabella Intervalli IP e regole firewall del probe. 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. Previsto quando Cloud NAT non è abilitato nella subnet o quando non sono presenti altre route predefinite che utilizzano 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 disponeva di un indirizzo IP esterno oppure Cloud NAT non era abilitato nella subnet.
Suggerimenti
Se vuoi accedere a endpoint esterni, puoi assegnare un indirizzo IP esterno alla tua istanza. In alternativa, puoi abilitare Cloud NAT sulla rispettiva subnet, a meno che la connessione non passi attraverso un'istanza proxy che concede l'accesso a internet.
Regola di forwarding senza istanze
Per la regola di forwarding non sono configurati backend.
Probabile causa
La regola di forwarding che stai cercando di raggiungere non ha backend configurati.
Suggerimenti
Controlla la configurazione del bilanciatore del carico e assicurati che nel servizio di backend del bilanciatore del carico siano configurati backend.
Il tipo di traffico è bloccato
Il tipo di traffico è bloccato e non puoi configurare una regola firewall per abilitarlo. Per maggiori dettagli, vedi Traffico sempre bloccato.
Probabile causa
Questo tipo di traffico è bloccato per impostazione predefinita e non può essere abilitato 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 maggiori dettagli, vedi Traffico sempre bloccato.
- Invio di traffico a una porta non supportata su un'istanza Cloud SQL. Ad esempio, inviare traffico sulla 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 Cloud Function o da una revisione di Cloud Run che utilizza un protocollo diverso da TCP o UDP.
Suggerimenti
Per il traffico SMTP (traffico in uscita verso una destinazione esterna con la porta TCP 25) in uscita, consulta Invio di email da un'istanza.
Per il protocollo DHCP, inclusi i pacchetti UDP IPv4 sulla porta 68 di destinazione (risposte DHCPv4) e i pacchetti IPv6 UDP sulla porta di destinazione 546 (risposte DHCPv6), il traffico DHCP è consentito solo dal server 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 eliminato perché la versione dell'ambiente standard di App Engine, la Cloud Function o la revisione Cloud Run non dispongono di un connettore di accesso VPC serverless configurato.
Probabile causa
L'indirizzo IP di destinazione è un indirizzo IP privato, che non è raggiungibile tramite internet. Il pacchetto lascia l'origine, ma non è configurato alcun connettore di accesso VPC serverless per la versione dell'ambiente standard di App Engine, la Cloud Function o la revisione di Cloud Run.
Suggerimenti
Se provi ad accedere all'endpoint di destinazione utilizzando il relativo indirizzo IP privato, assicurati di aver configurato un connettore di accesso VPC serverless per la versione dell'ambiente standard di App Engine, la funzione Cloud Function o la revisione di Cloud Run.
Il connettore di accesso VPC serverless non è in esecuzione
Il pacchetto è stato eliminato perché il connettore di accesso VPC serverless non è in esecuzione.
Probabile causa
Il pacchetto è stato ignorato perché tutte le istanze del connettore di accesso VPC serverless sono arrestate.
Suggerimenti
Per un elenco delle procedure di risoluzione dei problemi, vedi Risoluzione dei problemi.
La connessione Private Service Connect non è accettata
Il pacchetto è stato ignorato perché la connessione di Private Service Connect non è stata accettata.
Probabile causa
L'endpoint Private Service Connect si trova in un progetto non approvato per la connessione al servizio. Per maggiori informazioni, consulta Visualizzare i dettagli degli endpoint.
Suggerimenti
Assicurati che l'endpoint Private Service Connect si trovi in un 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.
Suggerimenti
Potresti utilizzare uno dei pattern di connettività descritti nella pagina Pattern di deployment di Private Service Connect. Puoi anche accedere alle API di Google e ai servizi pubblicati utilizzando i backend Private Service Connect.