Connectivity Tests possono eliminare un pacchetto di test per uno qualsiasi dei seguenti motivi.
Per un elenco completo dei possibili motivi, vedi Stati dell'analisi della configurazione.
Indirizzo IP straniero non consentito
Il pacchetto viene eliminato perché un'istanza Compute Engine può inviare o ricevere pacchetti con un indirizzo IP esterno solo quando è abilitato l'IP forwarding.
Probabile causa
L'istanza VM non ha l'IP forwarding abilitato, ma l'indirizzo IP di origine o di destinazione del pacchetto che la attraversa non corrisponde agli indirizzi IP dell'istanza. Ciò può accadere, ad esempio, quando il pacchetto viene recapitato all'istanza utilizzando una route statica con l'istanza VM come hop successivo.
Consigli
Crea un'istanza Compute Engine con l'inoltro IP abilitato o imposta l'attributo corrispondente per l'istanza esistente. Per saperne di più, vedi Attivare l'inoltro IP per le istanze.
Ignorato a causa di una regola firewall
Il pacchetto può essere eliminato a causa di una regola firewall, tranne quando è consentito per il monitoraggio delle connessioni.
Probabile causa
Connectivity Tests potrebbe rifiutare un pacchetto di test perché corrisponde a una regola firewall di blocco o a una regola di criterio firewall. Tuttavia, il piano dati effettivo potrebbe consentire il passaggio del pacchetto a causa del monitoraggio della connessione nella regola firewall. Il monitoraggio delle connessioni consente ai pacchetti di una connessione esistente di essere restituiti nonostante la regola firewall.
Ogni rete VPC ha due regole firewall implicite che consentono il traffico in uscita ovunque e bloccano il traffico in entrata da ovunque. Potresti anche avere una regola firewall in uscita di negazione con priorità più alta.
Perché la connettività funzioni, è necessaria una regola firewall in uscita nell'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 è normalmente il lato che avvia la comunicazione, il traffico di risposta viene consentito automaticamente con il monitoraggio della connessione e non è necessaria una regola firewall in entrata.
Consigli
Elimina la regola di negazione o crea una regola di autorizzazione in base ai dettagli nei risultati dei test di connettività. Per ulteriori informazioni, vedi Policy dei firewall e Utilizzo delle regole firewall VPC. Se la regola della policy del firewall che ha negato il traffico ha un tipo di rete specificato, consulta le regole della policy del firewall per determinare se la regola si applica al tuo caso d'uso.
Ignorato perché non è stata trovata una route corrispondente
Il pacchetto viene ignorato perché non sono presenti 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 un po' di tempo prima che Connectivity Tests riceva un aggiornamento della configurazione e lo incorpori nell'analisi.
Se tenti di 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, Network Connectivity Center o una soluzione di connettività ibrida come Cloud VPN).
Tieni presente che il peering VPC transitivo non è supportato. Valuta la possibilità di connettere le reti di origine e di destinazione direttamente o utilizzando una soluzione di connettività ibrida.
Se tenti di accedere all'endpoint di destinazione tramite internet, assicurati di avere una route per l'indirizzo IP di destinazione con il gateway internet hop successivo.
Se il pacchetto passa attraverso il gruppo di endpoint di rete con connettività ibrida, valuta la possibilità di requisiti aggiuntivi per l'applicabilità delle route. Alcune route visualizzate nella tabella della visualizzazione delle route potrebbero non essere disponibili per il traffico proveniente dai 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).
Consigli
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 di route e sulla loro applicabilità, vedi Route e Utilizzare le route.
L'indirizzo IP dell'hop successivo della route non è risolto
Il pacchetto viene inviato a una destinazione utilizzando una route non valida con l'indirizzo IP dell'hop successivo non assegnato a nessuna risorsa.
Probabile causa
Se si tratta di una route con next-hop-address, l'indirizzo del next hop 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 come 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 a essa connessa tramite il peering di rete VPC.
Consigli
Verifica che l'indirizzo IP dell'hop successivo appartenga a una risorsa supportata. Per saperne di più, vedi Considerazioni per le istanze di hop successivo e Considerazioni per gli hop successivi del bilanciatore del carico di rete passthrough interno.
L'istanza di 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 di hop successivo che non ha un controller di interfaccia di rete (NIC) nella rete della route.
Probabile causa
L'istanza Compute Engine utilizzata come hop successivo di una route deve avere un NIC nella rete della route (non in 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, vedi 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.
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.
Consigli
Verifica che l'indirizzo IP dell'hop successivo sia un indirizzo IPv4 interno principale dell'istanza Compute Engine. Per ulteriori informazioni, vedi 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 forwarding dell'hop successivo (next-hop-ilb) che 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 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é la route non valida.
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 la connettività a internet, ad esempio abbia un indirizzo IP esterno o utilizzi Cloud NAT, e utilizza l'indirizzo IP esterno dell'endpoint di destinazione nel test.
Se vuoi 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 all'interno di una rete on-premise, utilizza una soluzione Network Connectivity Center o una soluzione di connettività ibrida, come Cloud VPN o Cloud Interconnect.
- Se l'endpoint di destinazione si trova all'interno di Google Cloud:
- Configura il peering di rete VPC tra reti VPC.
- Configura Cloud VPN tra 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 tramite questa connessione o utilizza la route predefinita che passa attraverso 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, vedi Route e Utilizzare le route.
Se stai testando la connettività a una rete on-premise da una rete in peering, consulta questo esempio per la pubblicità personalizzata, la modalità di routing di rete e lo scambio di route personalizzate.
Il peering di rete VPC transitivo non è supportato. Puoi utilizzare la VPN o il peering per queste due reti VPC.
L'accesso privato Google non è consentito
L'istanza Compute Engine con solo un indirizzo IP interno tenta di raggiungere l'indirizzo IP esterno di servizi e API di Google, ma l'accesso privato Google non è abilitato nella subnet dell'istanza.
Consigli
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 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 di servizi e API di 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.
Consigli
Se l'endpoint di origine è un endpoint Google Cloud (ad esempio un'istanza VM di Compute Engine), valuta la possibilità di attivare l'accesso privato Google nella relativa subnet 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.
Mancata corrispondenza della regola di forwarding
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.
Consigli
Conferma il protocollo e le porte della regola di forwarding di destinazione.
Mancata corrispondenza della regione della regola di forwarding
L'accesso globale non è attivato per la regola di forwarding 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 bilanciatori del carico.
Se la regola di forwarding è regionale, 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 forwarding.
Quando ti connetti 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 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.
Il firewall 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 proveniente dai prober Google Cloud di raggiungere i backend. In caso contrario, i backend vengono considerati in stato non integro.
Consigli
Crea regole firewall di autorizzazione in entrata in base alla tabella Intervalli IP e regole firewall dei probe. Per saperne di più, consulta Regole firewall richieste.
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 esiste 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 un indirizzo IP esterno alla tua istanza. In alternativa, puoi abilitare Cloud NAT nella relativa subnet, a meno che la connessione non passi attraverso un'istanza proxy che consente l'accesso a internet.
Regola di forwarding senza istanze
La regola di forwarding non presenta backend configurati.
Probabile causa
La regola di forwarding 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.
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 porta TCP 25 (SMTP). Per maggiori dettagli, consulta 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 Cloud SQL MySQL 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), vedi Invio di email da un'istanza.
Per il protocollo DHCP, inclusi i pacchetti UDP IPv4 alla porta di destinazione 68 (risposte DHCPv4) e i pacchetti UDP IPv6 alla porta di destinazione 546 (risposte DHCPv6), il traffico DHCP è consentito solo dal server dei metadati (169.254.169.254).
Per la connettività Cloud SQL, assicurati che la porta utilizzata sia corretta.
I tag di rete non sono supportati dal traffico VPC diretto in uscita nelle regole firewall in entrata
Il pacchetto viene eliminato perché l'uscita VPC diretta non supporta i tag di rete di origine nelle regole firewall in entrata.
Probabile causa
La corrispondenza delle regole firewall in entrata in base ai tag di rete di origine non è supportata per le connessioni Cloud Run tramite l'uscita VPC diretta. Per ulteriori informazioni, vedi Limitazioni.
Consigli
Aggiorna le regole firewall in modo da utilizzare intervalli IP di origine anziché tag di rete di origine per abbinare il traffico dalle connessioni Cloud Run tramite l'uscita VPC diretto.
Il connettore di accesso VPC serverless non è configurato
Il pacchetto è stato eliminato perché la versione dell'ambiente standard di App Engine, la funzione Cloud Run o la revisione di Cloud Run non ha un connettore di accesso VPC serverless configurato.
Probabile causa
L'indirizzo IP di destinazione è un indirizzo IP privato, che non può essere raggiunto tramite internet. Il pacchetto esce dall'origine, ma non è configurato alcun connettore di accesso VPC serverless per la versione dell'ambiente standard App Engine, la funzione Cloud Run o la revisione Cloud Run.
Consigli
Se tenti di 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 App Engine, la funzione Cloud Run o la revisione Cloud Run.
Il connettore di accesso VPC serverless non è in esecuzione
Il pacchetto è stato ignorato perché il connettore di accesso al VPC serverless non è in esecuzione.
Probabile causa
Il pacchetto è stato eliminato perché tutte le istanze del connettore di accesso VPC serverless sono arrestate.
Consigli
Per un elenco di passaggi per la risoluzione dei problemi, consulta la sezione Risoluzione dei problemi.
La connessione Private Service Connect non è accettata
Il pacchetto è stato eliminato perché la connessione Private Service Connect non è stata accettata.
Probabile causa
L'endpoint Private Service Connect si trova in un progetto che non è approvato per la connessione al servizio. Per ulteriori informazioni, vedi Visualizzare i dettagli dell'endpoint.
Consigli
Assicurati che l'endpoint Private Service Connect si trovi in un progetto approvato per la connessione al servizio gestito.
Si accede 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
Google consiglia di eseguire la transizione a un'architettura hub e spoke che utilizza Network Connectivity Center per abilitare la propagazione della connessione Private Service Connect.
In alternativa, valuta uno dei seguenti pattern di connettività:
Se supportato dal producer di servizi, esegui la transizione a un pattern di connettività multi-point access.
Se supportato dal producer di servizi, configura un bilanciatore del carico consumer supportato con un backend Private Service Connect.
Per ulteriore assistenza, contatta l'assistenza producer di servizi o il tuo rappresentante Google Cloud .