Connectivity Tests può ignorare un pacchetto di test per uno dei seguenti motivi.
Per un elenco completo dei possibili motivi, consulta 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 se l'IP forwarding è abilitato.
Causa probabile
L'inoltro IP non è abilitato nell'istanza VM, ma l'indirizzo IP di origine o di destinazione del pacchetto che la attraversa non corrisponde agli indirizzi IP dell'istanza. Questo potrebbe accadere, ad esempio, quando il pacchetto viene consegnato all'istanza utilizzando una route statica con l'istanza VM come hop successivo.
Consigli
Crea un'istanza Compute Engine con l'IP forwarding abilitato o imposta l'attributo corrispondente per l'istanza esistente. Per saperne di più, consulta Abilita l'IP forwarding per le istanze.
Ignorato a causa di una regola firewall
Il pacchetto può essere eliminato a causa di una regola firewall, tranne quando è consentito in base al monitoraggio delle connessioni.
Causa probabile
Connectivity Tests potrebbe rifiutare un pacchetto di test perché corrisponde a una regola firewall o a una regola della policy del 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 della connessione consente ai pacchetti di una connessione esistente di tornare indietro nonostante la regola firewall.
Ogni rete VPC prevede due regole firewall implicite che consentono il traffico in uscita verso qualsiasi destinazione e bloccano il traffico in entrata da qualsiasi origine. Potresti anche avere una regola firewall di negazione del traffico in uscita con priorità più elevata.
Affinché la connettività venga stabilita, è necessaria una regola firewall in uscita nell'origine che consenta l'accesso all'endpoint di destinazione e una regola firewall in entrata nella destinazione che consenta 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 di Connectivity Tests. Per saperne di più, consulta Policy dei firewall e Utilizza le regole firewall VPC. Se la regola della policy del firewall che ha negato il traffico ha un contesto 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 esistono route corrispondenti.
Causa probabile
Non esiste una route attiva corrispondente 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 una nuova route, 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 provi ad accedere all'endpoint di destinazione utilizzando il suo 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 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, considera i requisiti aggiuntivi per l'applicabilità delle route. Alcune route visualizzate nella tabella di visualizzazione delle route potrebbero non essere disponibili per il traffico proveniente dai NEG ibridi.
Per saperne di più, consulta Route e Utilizza 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 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 saperne di più sulla creazione e sull'applicabilità delle route, consulta Route e Utilizza 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 a nessuna risorsa.
Causa probabile
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, dal forwarding del protocollo o come endpoint di 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 tramite il peering di rete VPC.
Consigli
Verifica che l'indirizzo IP dell'hop successivo appartenga a una risorsa supportata. Per saperne di più, consulta 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 sbagliata
Il pacchetto viene inviato a una destinazione utilizzando una route non valida con l'istanza Compute Engine dell'hop successivo che non dispone di un controller di interfaccia di rete (NIC) nella rete della route.
Causa probabile
L'istanza Compute Engine utilizzata come hop successivo di una 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 saperne di più, 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 di 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 saperne di più, 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 saperne di più, consulta Considerazioni sugli 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.
Causa probabile
L'indirizzo IP di destinazione del pacchetto è un indirizzo IP privato, che non può essere raggiunto tramite internet. Tuttavia, il pacchetto lascia l'istanza Compute Engine di origine e corrisponde a una route con il gateway internet come 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 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 NCC 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 attraverso 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 saperne di più sulla creazione e sull'applicabilità delle route, consulta Route e Utilizza le route.
Se stai testando la connettività a una rete on-premise da una rete in peering, consulta questo esempio per l'annuncio personalizzato, 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 delle API di Google e dei servizi, 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 di Google 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 instradato attraverso 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 abilitare l'accesso privato Google nella subnet di origine.
Se l'endpoint di origine è un endpoint on-premise, consulta Accesso privato Google per host on-premise per istruzioni dettagliate.
Indirizzo interno sconosciuto
L'indirizzo IP interno di destinazione non può essere risolto in un target noto.
Consigli
- Se stai testando la connettività per una rete VPC condiviso, controlla se l'ID progetto di servizio è fornito come input del test.
- Verifica che l'indirizzo IP sia assegnato a un endpoint di destinazione supportato.
Mancata corrispondenza della regola di forwarding
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
Conferma il protocollo e le porte della regola di forwarding di destinazione.
Mancata corrispondenza della regione della regola di forwarding
La regola di forwarding non ha l'accesso globale abilitato e la sua regione non corrisponde a quella del pacchetto.
Causa probabile
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.
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, consulta 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ù, consulta Abilita l'accesso globale per i bilanciatori del carico delle applicazioni interni e Abilita 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.
Causa probabile
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 tuoi backend. In caso contrario, i backend sono considerati non integri.
Consigli
Crea regole firewall di autorizzazione in entrata in base alla tabella Intervalli IP di probe e regole firewall. Per saperne di più, consulta Regole firewall obbligatorie.
Il firewall blocca il controllo di integrità del proxy Envoy del bilanciatore del carico
Le regole firewall bloccano i probe del controllo di integrità verso i proxy Envoy utilizzati dal bilanciatore del carico.
Causa probabile
Per i bilanciatori del carico delle applicazioni interni e i bilanciatori del carico di rete proxy interni, Google utilizza i probe dei controlli di integrità per monitorare i proxy Envoy gestiti. Se una policy del firewall di rete regionale ha regole che hanno come target la regola di forwarding del bilanciatore del carico (--target-type=INTERNAL_MANAGED_LB), una regola di negazione in entrata può bloccare questi probe.
Questo calo si verifica quando la policy non ha una regola di autorizzazione in entrata con priorità più alta per gli intervalli di indirizzi IP dei probe del controllo di integrità. Di conseguenza, i probe del controllo di integrità vengono bloccati e i proxy Envoy vengono considerati non disponibili.
Consigli
Configura una regola firewall di autorizzazione in entrata con priorità più alta con il flag --target-type=INTERNAL_MANAGED_LB per consentire il traffico in entrata dagli intervalli di indirizzi IP di probe del controllo di integritàGoogle alla regola di forwarding.
Per saperne di più, consulta Crea risorse Cloud NGFW e Intervalli IP di probe per i frontend dei bilanciatori del carico basati su Envoy gestiti selezionati.
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. Questo è il comportamento 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).
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 alla tua istanza. In alternativa, puoi attivare Cloud NAT sulla sua subnet, a meno che la connessione non passi attraverso un'istanza proxy che fornisce l'accesso a internet.
Regola di forwarding senza istanze
La regola di forwarding non è associata ad alcun backend.
Causa probabile
Questo calo si verifica per i seguenti motivi:
- Nessun backend è collegato al servizio di backend del bilanciatore del carico.
- La regola di forwarding fa riferimento a un proxy di destinazione, ma quest'ultimo non ha una configurazione di routing:
- Bilanciatori del carico delle applicazioni: il proxy di destinazione non è associato a una mappa URL.
- Bilanciatori del carico di rete proxy che utilizzano il routing SNI (Server Name Indication): il proxy di destinazione non è associato a una route TLS.
Consigli
Rivedi la configurazione del bilanciatore del carico nel seguente modo:
- Assicurati che al servizio di backend predefinito siano collegati dei backend.
- Per i bilanciatori del carico delle applicazioni, assicurati che il proxy di destinazione faccia riferimento a una mappa URL e che i servizi di backend definiti nella mappa URL abbiano backend collegati.
- Per i bilanciatori del carico di rete proxy che utilizzano il routing SNI, assicurati che il proxy di destinazione sia referenziato in almeno una route TLS e che i servizi di servizio di backend definiti nella route TLS abbiano backend collegati.
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 abilitato creando regole firewall. Gli scenari comuni sono i seguenti:
- Invio di 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 per MySQL con la porta 3306 aperta.
- Invio di traffico in uscita da una versione dell'ambiente standard App Engine, da una funzione Cloud Run, da una revisione Cloud Run o da un job 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 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.
L'accesso al control plane del cluster GKE non è autorizzato
L'accesso al control plane del cluster GKE dall'indirizzo IP di origine non è autorizzato.
Causa probabile
L'IP di origine che stai utilizzando non corrisponde alle regole di accesso autorizzato configurate nel tuo cluster GKE. Per saperne di più, consulta Accesso agli endpoint del cluster.
Consigli
Aggiorna l'accesso al control plane GKE per consentire l'origine selezionata, come descritto in Modifica l'accesso al control plane.
L'accesso all'istanza Cloud SQL non è autorizzato
L'accesso all'istanza Cloud SQL dall'indirizzo IP di origine non è autorizzato.
Causa probabile
L'IP di origine che stai utilizzando non corrisponde alle reti autorizzate configurate nell'istanza Cloud SQL. Affinché la connessione funzioni, l'indirizzo IP o l'intervallo di indirizzi dell'applicazione client deve essere configurato come rete autorizzata nell'istanza Cloud SQL.
Consigli
Aggiorna l'accesso all'istanza Cloud SQL per consentire l'indirizzo IP di origine selezionato, come descritto in Autorizza con reti autorizzate.
I tag di rete non sono supportati dal traffico VPC diretto in uscita nelle regole firewall in entrata
Il pacchetto viene ignorato perché il traffico VPC diretto in uscita non supporta i tag di rete di origine nelle regole firewall in entrata.
Causa probabile
La corrispondenza delle regole firewall in entrata in base ai tag di rete di origine non è supportata per le connessioni Cloud Run tramite VPC diretto in uscita. Per ulteriori informazioni, vedi Limiti.
Consigli
Aggiorna le regole firewall in modo da utilizzare gli intervalli IP di origine anziché i tag di rete di origine per trovare corrispondenze con il traffico proveniente dalle connessioni Cloud Run tramite il traffico VPC diretto in uscita.
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 o il job Cloud Run non hanno 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 lascia l'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 o il job Cloud Run.
Consigli
Se provi ad accedere all'endpoint di destinazione utilizzando il suo 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 o il job 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.
Causa probabile
Il pacchetto è stato ignorato perché tutte le istanze del connettore di accesso VPC serverless sono arrestate.
Consigli
Per un elenco dei passaggi per la risoluzione dei problemi, consulta 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 saperne di più, consulta Visualizza i dettagli degli endpoint.
Consigli
Assicurati che l'endpoint Private Service Connect si trovi in un progetto approvato per la connessione al servizio gestito.
Accesso 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 passare a un'architettura hub and 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, passa a un modello di connettività di accesso multipunto.
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 o il rappresentante del producer di servizi. Google Cloud
Nessuna route valida da una rete gestita da Google alla destinazione
Il pacchetto viene ignorato perché non esiste una route corrispondente valida dalla rete del servizio gestito da Google alla destinazione.
Questa causa di eliminazione si applica a qualsiasi servizio gestito da Google supportato da Connectivity Tests, inclusi Cloud SQL e GKE.
Consigli
Verifica se il servizio gestito da Google è configurato per inviare traffico alla destinazione.
Se la destinazione deve essere raggiungibile tramite route statiche o dinamiche locali configurate nella rete VPC, assicurati che la rete VPC esporti queste route nella rete del servizio gestito da Google. Questo pattern è comune per le connessioni dai servizi gestiti da Google alle destinazioni raggiungibili tramite Cloud VPN o Cloud Interconnect.
Per le connessioni tramite peering di rete VPC, consulta Opzioni per lo scambio di route statiche e Opzioni per lo scambio di route dinamiche.
Per le connessioni tramite gli spoke VPC producer di Network Connectivity Center, consulta Scambio di route con gli spoke VPC e Proprietà condivise con gli spoke VPC.
Se la destinazione si trova in una subnet configurata con intervalli di indirizzi IP pubblici utilizzati privatamente, assicurati che la tua rete esporti le route della subnet corrispondenti alla rete del servizio gestito da Google.
Per le connessioni tramite peering di rete VPC, consulta Opzioni per lo scambio di route di subnet.
Per le connessioni tramite spoke VPC producer di Network Connectivity Center, consulta Indirizzi IPv4 pubblici utilizzati privatamente.
Se la destinazione è un indirizzo IP esterno instradabile su internet, assicurati che il servizio gestito da Google sia configurato per questo percorso di connettività. Ad esempio, alcuni tipi di istanze Cloud SQL non supportano le connessioni esterne in uscita.
Se la destinazione deve essere raggiungibile tramite route dinamiche importate nella rete del servizio gestito da Google tramite il peering di rete VPC, potrebbe essere raggiunto il limite di route dinamiche per regione per gruppo di peering per la rete di servizi. Se ritieni che questo limite sia stato raggiunto, invia una richiesta di assistenza.