Connectivity Tests può eliminare un pacchetto di test per uno 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 è abilitato l'IP forwarding.
Causa probabile
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 fornito all'istanza utilizzando una route statica con l'istanza VM come hop successivo.
Consigli
Crea un'istanza Compute Engine con il forwarding IP abilitato o imposta l'attributo corrispondente per l'istanza esistente. Per ulteriori informazioni, consulta Attivare 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 è consentito per il monitoraggio delle connessioni.
Causa probabile
Connectivity Tests potrebbe rifiutare un pacchetto di test perché corrisponde a una regola firewall o a una regola del criterio firewall di blocco. 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 il ritorno dei pacchetti per una connessione esistente nonostante la regola del firewall.
Ogni rete VPC ha due regole firewall implicite che consentono il traffico in uscita verso qualsiasi destinazione e bloccano il traffico in entrata proveniente da qualsiasi destinazione. Potresti anche avere una regola firewall in uscita di rifiuto con priorità più alta.
Affinché la connettività vada a buon fine, è necessaria una regola firewall in uscita all'origine che consenta l'accesso all'endpoint di destinazione e una regola firewall in entrata alla 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 Connectivity Tests. Per saperne di più, consulta Policy firewall e Utilizzare le regole firewall VPC.
Ignorato per assenza di route corrispondenti
Il pacchetto viene ignorato perché non esistono route corrispondenti.
Causa probabile
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 relativo indirizzo IP interno, assicurati che le reti di origine e di destinazione siano connesse (ad esempio, utilizzando il peering di rete VPC, il 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 collegare le reti di origine e di destinazione direttamente o utilizzando 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, 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 l'indirizzo IP dell'istanza di destinazione con l'hop successivo in un'altra rete (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 e sull'applicabilità delle route, consulta 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.
Causa probabile
Se si tratta di una route con next-hop-address, l'indirizzo del successivo 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 con 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 inoltro utilizzate da altri bilanciatori del carico, l'inoltro del protocollo o gli endpoint di 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 ulteriori informazioni, consulta Considerazioni per le istanze dell'hop successivo e Considerazioni per gli hop successivi del bilanciatore del carico di rete passthrough interno.
L'istanza dell'hop successivo della route ha una scheda NIC nella rete sbagliata
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 IPv4 interno principale dell'istanza Compute Engine.
Gli intervalli di indirizzi IP degli 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, 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 forwarding dell'hop successivo (next-hop-ilb) che non è una regola di forwarding 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é la route non valida.
Traffico privato su internet
Un pacchetto con indirizzo di destinazione interno è stato inviato a un gateway internet.
Causa probabile
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.
Se vuoi accedere alla destinazione tramite il relativo 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 in 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 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 delle API e dei servizi Google, ma l'accesso privato Google non è abilitato nella subnet dell'istanza.
Consigli
Puoi consentire all'istanza VM 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 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.
Causa probabile
Il pacchetto dall'endpoint di origine all'indirizzo IP esterno delle API e dei servizi Google viene indirizzato 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 Compute Engine), valuta la possibilità di attivare Accesso privato Google nella 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 inoltro
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 viene inviato a una porta di destinazione che non corrisponde alle porte supportate dalla regola di forwarding.
Consigli
Verifica il protocollo e le porte regola di forwarding di destinazione.
Mancata corrispondenza della regione della regola di inoltro
L'accesso globale non è attivato per la regola di forwarding e la relativa regione non corrisponde alla regione del pacchetto.
Causa probabile
A seconda del bilanciatore del carico e del relativo livello, una regola di inoltro è globale o regionale. Per maggiori dettagli, consulta la tabella dei tipi di bilanciatori 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.
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.
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, consulta Bilanciatori del carico delle applicazioni interni e reti connesse.
Puoi attivare l'accesso globale sui bilanciatori del carico delle applicazioni interni e sui bilanciatori del carico di rete proxy interni a livello di regione 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 a livello di regione.
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.
Causa probabile
Affinché i controlli di integrità funzionino, devi creare regole firewall di autorizzazione in entrata che consentano al traffico proveniente dai controllori 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 ulteriori informazioni, 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. 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).
Causa probabile
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 all'istanza. In alternativa, puoi attivare Cloud NAT nella relativa sottorete, a meno che la connessione non passi attraverso un'istanza proxy che consente l'accesso a internet.
Regola di inoltro senza istanze
La regola di forwarding non presenta backend configurati.
Causa probabile
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 attivarlo. 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 di traffico in uscita a una destinazione esterna con la 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 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 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 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 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 alla rete VPC serverless non è in esecuzione.
Causa probabile
Il pacchetto è stato ignorato perché tutte le istanze del connettore Accesso VPC serverless sono state interrotte.
Consigli
Per un elenco dei passaggi per la risoluzione dei problemi, consulta la sezione Risoluzione dei problemi.
La connessione Private Service Connect non è accettata
Il pacchetto è stato ignorato perché la connessione Private Service Connect non è stata accettata.
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 un progetto approvato per la connessione al servizio gestito.
All'endpoint Private Service Connect si accede 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 i backend di Private Service Connect.