Connectivity Tests può rilasciare un pacchetto di test per 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 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 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.
Eliminato a causa di una regola 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 della connessione il monitoraggio della regola 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 è in genere il lato che avvia la comunicazione, il traffico di risposta è automaticamente consentito senza bisogno di una regola firewall in entrata.
Consigli
Elimina la regola di negazione o creane una basata sui dettagli specificati nella Risultati di Connectivity Tests. Per ulteriori informazioni, vedi Criteri firewall e Utilizza 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 IP di destinazione) (indirizzo IP) nella rete e nella regione del pacchetto.
Consigli
Verifica l'elenco di route operative in la console Google Cloud. Se hai appena creato un nuovo percorso, tieni presente che l'operazione potrebbe richiedere del tempo per fare in modo che Connectivity Tests riceva un aggiornamento della configurazione e lo incorpora in 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 ulteriori requisiti per l'applicabilità delle route. Alcuni percorsi che vedi nella tabella della visualizzazione dei percorsi potrebbero non essere disponibili per il traffico 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 prevista. Ad esempio, esegui un
il test da un'istanza Compute Engine nella rete network-1
all'istanza di 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
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
supportato). L'indirizzo IP deve essere assegnato a una risorsa nel VPC della route
o in una rete connessa tramite 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'hop successivo L'istanza Compute Engine 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 in rete della route (non una rete VPC in peering).
Consigli
Verifica che l'istanza Compute Engine dell'hop successivo abbia un NIC in rete della route. Per ulteriori informazioni, vedi 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 con l'IP dell'hop successivo
(next-hop-address) non è un indirizzo IP principale del
di Compute Engine.
Probabile causa
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, vedi 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 con l'hop successivo
che la regola di forwarding (next-hop-ilb) non è una regola di forwarding dell'
il bilanciatore del carico di rete passthrough interno.
Probabile causa
La regola di forwarding per l'hop successivo della route deve essere una regola di forwarding del il bilanciatore del carico di rete passthrough interno. Per ulteriori informazioni, vedi 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é quella non valida percorso.
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, non raggiungibili tramite internet. Tuttavia, il pacchetto lascia il di origine Compute Engine e associa una route all'hop successivo un gateway internet standard.
Consigli
Per accedere alla destinazione tramite internet, assicurati che dell'istanza Compute Engine di origine ha una connessione a internet, Ad esempio, ha un indirizzo IP esterno o utilizza 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 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 o utilizza la route predefinita che attraversa internet gateway VPN ad alta disponibilità. Verifica l'elenco di route operative. e l'elenco di route applicabili all'istanza di origine nella console Google Cloud. Per ulteriori informazioni sul percorso creazione e applicabilità, consulta Route e Utilizza route.
Se stai testando la connettività a una rete on-premise da un rete in peering, vedi questo esempio per la pubblicità personalizzata, la modalità di routing di rete e lo scambio di route personalizzate.
Peering di rete VPC transitorio 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 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'IP esterno delle API e dei servizi Google attraverso il tunnel VPN verso un'altra rete, ma deve essere abilitato l'accesso privato Google 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 (come un un'istanza VM di Compute Engine), valuta la possibilità di abilitare Accesso privato Google nella subnet di origine.
Se l'endpoint di origine è un endpoint on-premise, consulta la 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 il pacchetto 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
Per la regola di forwarding non è abilitato l'accesso globale né la relativa regione che corrisponda alla regione del pacchetto.
Probabile causa
A seconda del bilanciatore del carico e del livello, viene regola di inoltro è globale o regionale. Per ulteriori dettagli, vedi la tabella dei tipi di bilanciatore del carico.
Se la regola di forwarding è a livello di regione, il client (ad esempio, la VM o connettore VPC) deve trovarsi nella stessa regione con il bilanciatore del carico di rete passthrough esterno regionale.
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 come regola di forwarding.
Durante la connessione da una rete on-premise, assicurati che il client accede 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 saperne di più, vedi Abilitare l'accesso globale per gli Application Load Balancer interni e Abilita 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.
Probabile causa
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. Altrimenti, sono considerati in stato non integro.
Consigli
Crea regole firewall di autorizzazione in entrata in base agli intervalli IP e alle regole firewall del probe tabella. 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 attraverso 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 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 una 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
Per la regola di forwarding non sono configurati backend.
Probabile causa
La regola di forwarding che stai tentando di raggiungere non ha backend configurato.
Consigli
Controlla la configurazione del bilanciatore del carico e assicurati che servizio di backend del bilanciatore del carico ha backend configurati.
Il tipo di traffico è bloccato
Il tipo di traffico è bloccato e non puoi configurare una regola firewall per abilitarlo. Per ulteriori dettagli, vedi Traffico sempre bloccato.
Probabile causa
Questo tipo di traffico è bloccato per impostazione predefinita e non può essere attivato creando le regole del 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. Per Esempio: invio del traffico sulla porta TCP 3310 a un'istanza MySQL Cloud SQL con la porta 3306 aperta.
- per inviare traffico in uscita da una versione dell'ambiente standard di App Engine. una Cloud Function o Cloud Run revisione che utilizza un protocollo diverso da TCP o UDP.
Consigli
Per SMTP in uscita (traffico in uscita verso una destinazione esterna con la porta TCP 25) vedere il traffico, Invio di email da un'istanza.
Per il protocollo DHCP, inclusi i pacchetti IPv4 UDP sulla porta di destinazione 68 (DHCPv4) ) e pacchetti IPv6 UDP alla porta 546 di destinazione (risposte DHCPv6), DHCP il traffico è consentito solo dal server dei 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 di Cloud Run non ha Connettore di accesso VPC serverless configurato.
Probabile causa
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 Cloud Function o 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 Cloud Function o la revisione di Cloud Run.
Il connettore di accesso VPC serverless non è in esecuzione
Il pacchetto è stato eliminato perché Connettore di accesso VPC serverless non è in esecuzione.
Probabile causa
Il pacchetto è stato ignorato perché l'accesso VPC serverless delle istanze del connettore dati vengono arrestate.
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.
Probabile causa
L'endpoint Private Service Connect si trova in un progetto che non è ha approvato la connessione al servizio. Per maggiori informazioni consulta la sezione Visualizzare i dettagli degli 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
Potresti usare uno dei pattern di connettività descritti in Pattern di deployment di Private Service Connect . Puoi anche accedere alle API di Google e ai servizi pubblicati utilizzando Backend Private Service Connect.