Os Testes de conectividade pode descartar um pacote de teste por qualquer um dos motivos a seguir.
Para ver uma lista completa dos possíveis motivos, consulte estados de análise da configuração.
Endereço IP externo não permitido
O pacote é descartado porque uma instância do Compute Engine pode enviar ou receber pacotes com um endereço IP externo somente quando o encaminhamento de IP estiver ativado.
Causa provável
A instância de VM não tem o encaminhamento de IP ativado, mas a origem ou o endereço IP de destino do pacote que está passando não corresponde ao os endereços IP da instância. Isso pode acontecer, por exemplo, quando o pacote é entregues à instância usando uma rota estática com a instância de VM como próximo salto.
Recomendações
Crie uma instância do Compute Engine com encaminhamento de IP ativado ou defina o atributo correspondente para a instância existente. Para mais informações, consulte Ative o encaminhamento de IP para instâncias.
Descarte por causa de uma regra de firewall.
O pacote pode ser descartado devido a uma regra de firewall, exceto quando permitido devido ao rastreamento de conexão.
Causa provável
Os testes de conectividade podem negar um pacote de teste porque ele corresponde a um uma regra de firewall de bloqueio ou uma regra da política de firewall. No entanto, o plano de dados real pode permitir a passagem do pacote devido ao rastreamento de conexão na regra de firewall. O rastreamento de conexão permite pacotes para um que a conexão atual retorne, apesar da regra de firewall.
Toda rede VPC tem duas regras de firewall implícitas. que permitem o tráfego de saída para todos os lugares e bloqueiam o tráfego de entrada em todos os lugares. Talvez você também tenha uma regra de firewall de saída de negação de prioridade mais alta.
Para que a conectividade funcione, é preciso ter uma regra de firewall de saída na origem que permite acesso ao endpoint de destino e uma regra de firewall de entrada o destino para permitir essa conexão.
As regras de firewall da VPC têm estado. Se o endpoint de destino especificado for normalmente o lado que inicia a comunicação, o tráfego de resposta será permitido automaticamente com o rastreamento de conexão, e não será necessário uma regra de firewall de entrada.
Recomendações
Exclua a regra de negação ou crie uma regra de permissão com base nos detalhes nos resultados dos Testes de conectividade. Para mais informações, consulte Políticas de firewall e Use regras de firewall da VPC.
Descartado por não haver rota correspondente
O pacote é descartado porque não há rotas correspondentes.
Causa provável
Não há rota ativa que corresponda aos atributos do pacote (como um IP de destino na rede de pacotes e na região.
Recomendações
Verifique a lista de rotas efetivas em no console do Google Cloud. Se você acabou de criar uma nova rota, pode levar algum tempo para que os Testes de conectividade recebam uma atualização de configuração e a incorporem análise.
Se você tentar acessar o endpoint de destino usando o endereço IP interno, certifique-se de que as redes de origem e destino estejam conectadas (por exemplo, usando o peering de rede VPC, Network Connectivity Center, ou uma solução de conectividade híbrida como o Cloud VPN).
O peering de VPC transitivo não é compatível. Considere conectar as redes de origem e de destino de maneira direta ou usando uma solução de conectividade híbrida.
Se você tentar acessar o endpoint de destino pela Internet, verifique se que você tenha uma rota para o endereço IP de destino com o próximo salto de um gateway de VPN de alta disponibilidade.
Se o pacote estiver passando pelo grupo de endpoints de rede de conectividade híbrida, considere outros requisitos para aplicabilidade das rotas. Algumas rotas que aparecem na tabela de visualização de rota podem não estar disponíveis para o tráfego de NEGs híbridos.
Para mais informações, consulte Rotas e Usar rotas.
O pacote foi enviado para a rede errada
O pacote é enviado para uma rede não intencional. Por exemplo, você executa uma
um teste de uma instância do Compute Engine na rede network-1 para a
instância do Compute Engine na rede network-2, mas o pacote
é enviada para a rede network-3.
Causa provável
A rede network-1 tem uma rota com um intervalo de destino que inclui o
o endereço IP da instância de destino com o próximo salto em uma rede diferente
(network-3 no exemplo acima).
Recomendações
Verifique a lista de rotas efetivas e a lista de rotas aplicáveis à instância de origem; no console do Google Cloud. Para mais informações sobre a criação de rotas e aplicabilidade, consulte Rotas e Usar rotas.
O endereço IP do próximo salto da rota não é resolvido
O pacote é enviado para um destino usando uma rota inválida com o IP do próximo salto. não atribuído a nenhum recurso.
Causa provável
Se for uma rota com next-hop-address, o endereço do próximo salto precisará ser
um endereço IPv4 interno principal ou um endereço IPv6 do Compute Engine
na rede VPC da rota. Os endereços em redes com peering não são
suporte.
Se for uma rota com next-hop-ilb, o endereço do próximo salto precisará ser um
do balanceador de carga de rede de passagem interna, ou seja, regras de encaminhamento usadas por outros
encaminhamento de protocolo ou como endpoints do Private Service Connect
compatíveis). O endereço IP precisa ser atribuído a um recurso na VPC da rota
ou em uma rede conectada a ela com peering de rede VPC.
Recomendações
Verifique se o endereço IP do próximo salto pertence a um recurso compatível. Para mais informações, consulte Considerações para instâncias do próximo salto e Considerações sobre os próximos saltos do balanceador de carga de rede de passagem interna.
A instância do próximo salto da rota tem uma placa de rede (NIC) na rede errada
O pacote é enviado para um destino usando uma rota inválida com o próximo salto. Instância do Compute Engine sem uma placa de rede (NIC) na rede do trajeto.
Causa provável
A instância do Compute Engine usada como próximo salto da rota precisa ter uma placa de rede (NIC) à rede da rota (não uma rede VPC com peering).
Recomendações
Verifique se a instância do Compute Engine do próximo salto tem uma placa de rede (NIC) na rede da rota. Para mais informações, consulte Considerações para instâncias do próximo salto.
O endereço do próximo salto da rota não é um endereço IP primário da VM
O pacote é enviado para um destino usando uma rota inválida com o IP do próximo salto.
(next-hop-address) não é um endereço IP primário de
instância do Compute Engine.
Causa provável
O endereço IP do próximo salto da rota (next-hop-address) precisa ser um endereço IP interno principal
Endereço IPv4 da instância do Compute Engine.
Os intervalos de endereços IP de alias não são compatíveis.
Recomendações
Verifique se o endereço IP do próximo salto é um endereço IPv4 interno principal da instância do Compute Engine. Para mais informações, consulte Considerações para instâncias do próximo salto.
O tipo de regra de encaminhamento do próximo salto da rota é inválido
O pacote é enviado para um destino usando uma rota inválida com o próximo salto.
regra de encaminhamento (next-hop-ilb) não é uma regra de encaminhamento do
e o balanceador de carga de rede de passagem interna.
Causa provável
A regra de encaminhamento do próximo salto da rota precisa ser uma regra de encaminhamento do e o balanceador de carga de rede de passagem interna. Para mais informações, consulte Considerações sobre os próximos saltos do balanceador de carga de rede de passagem interna.
Recomendações
Crie uma rota que segmente uma regra de encaminhamento compatível em vez da trajeto.
Tráfego privado na Internet
Um pacote com um endereço de destino interno foi enviado para um gateway da Internet.
Causa provável
O endereço IP de destino do pacote é um endereço IP particular. que não podem ser acessados pela Internet. No entanto, o pacote deixa a instância de origem do Compute Engine e faz a correspondência de uma rota com o próximo salto de um gateway de VPN de alta disponibilidade.
Recomendações
Se quiser acessar o destino pela Internet, verifique se o instância de origem do Compute Engine tem conectividade com a Internet. Por exemplo, exemplo, se ela tem um endereço IP externo ou usa o Cloud NAT: e use o endereço IP externo do endpoint de destino no teste.
Se quiser acessar o destino pelo endereço IP interno, precisam estabelecer conectividade (criar rotas) entre a origem nas redes de destino. É possível fazer isso de uma das seguintes maneiras:
- Se o endpoint de destino estiver em uma rede no local, use um Network Connectivity Center ou de conectividade híbrida, como o Cloud VPN ou Cloud Interconnect.
- Se o endpoint de destino estiver no Google Cloud:
- Configure o peering de rede VPC entre nas redes VPC.
- Configure o Cloud VPN entre redes VPC.
- Configurar a conectividade de rede usando spokes de VPC do Network Connectivity Center.
Se você já tiver uma conexão com a rede de destino:
- A rede de endpoints de origem não tem uma rota que passe por ela conexão de Internet ou usa a rota padrão que passa pela Internet para outro gateway de VPN de alta disponibilidade. Verifique a lista de rotas efetivas, e a lista de rotas aplicáveis à instância de origem no console do Google Cloud. Para mais informações sobre as rotas criação e aplicabilidade, consulte Rotas e Usar rotas.
Se você estiver testando a conectividade com uma rede local a partir de uma rede com peering, consulte este exemplo para divulgação personalizada, modo de roteamento de rede e troca de rotas personalizadas.
O peering de rede VPC transitivo não é suportado. É possível usar a VPN ou o peering para essas duas redes VPC.
O Acesso privado do Google não é permitido
Uma instância do Compute Engine com apenas um endereço IP interno tenta acessar o IP externo das APIs e serviços do Google, mas o Acesso privado do Google não ativado na sub-rede da instância.
Recomendações
É possível permitir que a instância de VM do Compute Engine alcance o IP externo de APIs e serviços do Google de uma das seguintes maneiras:
- Ative o Acesso privado do Google para a conta do sub-rede da instância.
- Atribuir um endereço IP externo à placa de rede do Compute Engine.
- Ative o Cloud NAT para a sub-rede da instância de VM.
O Acesso privado do Google pelo túnel VPN não é compatível
Um endpoint de origem com um endereço IP interno tenta acessar o IP externo endereço IP de APIs e serviços do Google pelo túnel VPN para outra rede, mas o Acesso privado do Google precisa ser ativado na rede do endpoint de origem.
Causa provável
O pacote do endpoint de origem para o endereço IP externo da rede do APIs e serviços são roteados pelo túnel do Cloud VPN, mas um não tem suporte para essa configuração.
Recomendações
Se o endpoint de origem for um endpoint do Google Cloud (como um instância de VM do Compute Engine), considere ativar Acesso privado do Google na sub-rede de origem.
Se o endpoint de origem for no local, consulte Acesso privado do Google para hosts locais para ver instruções detalhadas.
Incompatibilidade de regra de encaminhamento
O protocolo e as portas da regra de encaminhamento não correspondem ao cabeçalho do pacote.
Causa provável
O pacote é enviado usando um protocolo não aceito pela regra de encaminhamento. ou for enviado para uma porta de destino que não corresponde às portas compatíveis com a regra de encaminhamento.
Recomendações
Confirme o protocolo e as portas da regra de encaminhamento de destino.
Incompatibilidade na região da regra de encaminhamento
O acesso global não está ativado na regra de encaminhamento, e a região dela não correspondem à região do pacote.
Causa provável
Dependendo do balanceador de carga e do respectivo nível, a regra de encaminhamento será global ou regional. Para mais detalhes, consulte a tabela de tipos de balanceador de carga.
Se a regra de encaminhamento for regional, o cliente (por exemplo, a VM ou o conector de VPC) precisará estar na mesma região do balanceador de carga.
Recomendações
Se você se conectar ao balanceador de carga por um endpoint do Google Cloud, como um Verifique se a instância de VM do Compute Engine está localizada na mesma região como regra de encaminhamento.
Ao se conectar de uma rede local, verifique se o cliente acessa o balanceador de carga por túneis do Cloud VPN ou anexos da VLAN que estão na mesma região do balanceador de carga. Para mais detalhes, consulte Balanceadores de carga de aplicativos internos e redes conectadas.
É possível ativar o acesso global nos balanceadores de carga internos do aplicativo e nos balanceadores de carga de rede de proxy internos regionais para acessar clientes em qualquer região. Por padrão, os clientes desses balanceadores de carga precisam estar na mesma região do balanceador de carga. Para mais informações, consulte Ativar o acesso global para balanceadores de carga de aplicativo internos. e Ativar o acesso global para balanceadores de carga de rede de proxy internos regionais.
Firewall que bloqueia a verificação de integridade do back-end do balanceador de carga
Os firewalls bloqueiam as sondagens da verificação de integridade nos back-ends e fazem com que eles sejam para tráfego do balanceador de carga.
Causa provável
Para que as verificações de integridade funcionem, é preciso criar regras de firewall de permissão de entrada que permitir que o tráfego das sondas do Google Cloud alcance seus back-ends. Caso contrário, e os back-ends não são íntegros.
Recomendações
Crie regras de firewall de permissão de entrada de acordo com as regras de firewall e intervalos de IP de sondagem tabela. Para mais informações, consulte Regras de firewall necessárias.
Nenhum endereço externo disponível
Uma instância de VM com apenas um endereço IP interno tentou acessar hosts externos por uma rota que tem o gateway de Internet padrão como próximo salto. Esperado quando o Cloud NAT não está ativado na sub-rede ou quando não há outra rota padrão que use um tipo diferente de próximo salto (como uma VM de proxy).
Causa provável
Uma instância com apenas um endereço IP interno tentou acessar um host externo, mas não tinha um endereço IP externo ou o Cloud NAT não estava ativado na sub-rede.
Recomendações
Para acessar endpoints externos, atribua um endereço IP externo à instância. Como alternativa, ative o Cloud NAT na sub-rede, a menos que o passa por uma instância de proxy que dá acesso à Internet.
Regra de encaminhamento sem instâncias
A regra de encaminhamento não tem back-ends configurados
Causa provável
A regra de encaminhamento que você está tentando acessar não tem back-ends configurados.
Recomendações
Verifique a configuração do balanceador de carga e certifique-se de que o serviço de back-end do balanceador de carga tenha back-ends configurados.
O tipo de tráfego está bloqueado
O tipo de tráfego está bloqueado e não é possível configurar uma regra de firewall para ativá-lo. Para mais informações, consulte Tráfego sempre bloqueado.
Causa provável
Esse tipo de tráfego é bloqueado por padrão e não pode ser ativado com a criação de regras de firewall. Os cenários comuns são os seguintes:
- Enviar tráfego de saída para um destino externo com a porta TCP 25 (SMTP). Para mais informações, consulte Tráfego sempre bloqueado.
- Enviar tráfego para uma porta não suportada em uma instância do Cloud SQL. Por exemplo, enviar tráfego para a porta TCP 3310 para uma instância do Cloud SQL do MySQL com a porta 3306 aberta.
- enviar tráfego de saída de uma versão do ambiente padrão do App Engine; uma função do Cloud ou um revisão que usa um protocolo diferente de TCP ou UDP.
Recomendações
Para tráfego de saída SMTP (tráfego de saída para um destino externo com a porta TCP 25), consulte Como enviar e-mails a partir de uma instância.
Para o protocolo DHCP, incluindo pacotes IPv4 UDP para a porta de destino 68 (respostas DHCPv4) e pacotes IPv6 UDP para a porta de destino 546 (respostas DHCPv6), o tráfego DHCP só é permitido a partir do servidor de metadados (169.254.169.254).
Para a conectividade do Cloud SQL, verifique se a porta usada está correta.
O conector de acesso VPC sem servidor não está configurado
O pacote foi descartado porque a versão do ambiente padrão do App Engine, a função do Cloud ou a revisão do Cloud Run não tem um Conector de acesso VPC sem servidor configurada.
Causa provável
O endereço IP de destino é um IP particular endereço, que não pode ser alcançado pela Internet. O pacote sai da origem, mas não há Conector de acesso VPC sem servidor configurado para A versão do ambiente padrão do App Engine, a função do Cloud ou o Cloud Run revisão.
Recomendações
Se você tentar acessar o endpoint de destino usando o endereço IP particular dele, verifique se você configurou um acesso VPC sem servidor para a versão do ambiente padrão do App Engine, a função do Cloud, ou a revisão do Cloud Run.
O conector de acesso VPC sem servidor não está em execução
O pacote foi eliminado porque o conector de acesso VPC sem servidor não está em execução.
Causa provável
O pacote foi eliminado porque todas as instâncias do conector de acesso VPC sem servidor foram interrompidas.
Recomendações
Veja uma lista de etapas de solução de problemas em Solução de problemas.
A conexão do Private Service Connect não foi aceita
O pacote foi eliminado porque a conexão do Private Service Connect não foi aceita.
Causa provável
O endpoint do Private Service Connect está em um projeto que não está aprovado para se conectar ao serviço. Para mais informações, consulte Ver detalhes do endpoint.
Recomendações
Verifique se o endpoint do Private Service Connect está projeto aprovado para se conectar ao serviço gerenciado.
O endpoint do Private Service Connect é acessado de uma rede com peering
O pacote é enviado para o endpoint do Private Service Connect com peering, mas essa configuração não é compatível.
Recomendações
Use um dos padrões de conectividade descritos no Padrões de implantação do Private Service Connect página. Também é possível acessar as APIs e os serviços publicados do Google usando Back-ends do Private Service Connect.