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 estrangeiro não permitido
O pacote é descartado porque uma instância do Compute Engine só pode enviar ou receber pacotes com um endereço IP externo quando o encaminhamento de IP está ativado.
Causa provável
O encaminhamento de IP não está ativado na instância de VM, mas o endereço IP de origem ou destino do pacote que passa por ela não corresponde aos endereços IP da instância. Isso pode acontecer, por exemplo, quando o pacote é entregue à 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 o encaminhamento de IP ativado ou defina o atributo correspondente para a instância atual. Para mais informações, consulte Ativar 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 for permitido devido ao rastreamento de conexão.
Causa provável
Os Testes de conectividade podem negar um pacote de teste porque ele corresponde a uma regra de firewall ou regra da política de firewall de bloqueio. 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 que os pacotes de uma conexão atual retornem, independentemente 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 de 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 seja bem-sucedida, você precisa de uma regra de firewall de saída na origem que permita acesso ao endpoint de destino e uma regra de firewall de entrada no 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 Usar regras de firewall da VPC.
Descartado porque não há rota correspondente
O pacote é descartado porque não há rotas correspondentes.
Causa provável
Não há rota ativa correspondente aos atributos do pacote (como um endereço IP de destino) na rede e na região do pacote.
Recomendações
Verifique a lista de rotas efetivas 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, verifique se as redes de origem e destino estão conectadas (por exemplo, usando o peering de rede VPC, o Network Connectivity Center ou uma solução de conectividade híbrida, como o Cloud VPN).
Não há suporte para o peering de VPC transitivo. Tente conectar as redes de origem e destino diretamente ou usando uma solução de conectividade híbrida.
Se você tentar acessar o endpoint de destino pela Internet, verifique se há uma rota para o endereço IP de destino com o gateway de Internet do próximo salto.
Se o pacote estiver passando pelo grupo de endpoints de rede de conectividade híbrida, considere os outros requisitos de aplicabilidade das rotas. Algumas rotas exibidas na tabela de visualização de rotas 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 uma rede errada
O pacote foi enviado para uma rede não intencional. Por exemplo, você executa 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 é enviado para a rede network-3.
Causa provável
A rede network-1 tem uma rota com um intervalo de destino que inclui 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 e a applicability de rotas, consulte Rotas e Usar rotas.
O endereço IP do próximo salto da rota não foi resolvido
O pacote é enviado para um destino usando uma rota inválida com o endereço IP do próximo salto não atribuído a nenhum recurso.
Causa provável
Se essa for uma rota com next-hop-address, o endereço do próximo salto precisará ser
um endereço IPv4 interno principal da instância do Compute Engine na rede VPC da rota. Endereços em redes com peering não são suportados.
Se for uma rota com next-hop-ilb, o endereço do próximo salto precisará ser um
endereço do balanceador de carga de rede de passagem interna. As regras de encaminhamento usadas por outros balanceadores de carga,
o encaminhamento de protocolo ou os endpoints do Private Service Connect não são
compatíveis. O endereço IP precisa ser atribuído a um recurso na rede VPC da rota ou em uma rede conectada a ela com o peering de rede VPC.
Recomendações
Verifique se o endereço IP do próximo salto pertence a um recurso com suporte. Para mais informações, consulte Considerações para instâncias do próximo salto e Considerações para 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, e a instância do Compute Engine do próximo salto não tem uma placa de rede (NIC, na sigla em inglês) na rede da rota.
Causa provável
A instância do Compute Engine usada como próximo salto de rota precisa ter uma placa de rede (NIC, na sigla em inglês) na 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 principal da VM
O pacote é enviado para um destino usando uma rota inválida, com o endereço IP do próximo salto (next-hop-address) não sendo o endereço IP principal da 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 IPv4 interno
principal da instância do Compute Engine.
Os intervalos de endereços IP do 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 a regra de encaminhamento
do próximo salto (next-hop-ilb) que não é uma regra de encaminhamento do
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 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 para uma regra de encaminhamento compatível em vez da rota inválida.
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 pode ser acessado pela Internet. No entanto, o pacote sai da instância de origem do Compute Engine e corresponde a uma rota com o gateway de Internet do próximo salto.
Recomendações
Se você quiser acessar o destino pela Internet, verifique se a instância de origem do Compute Engine tem conectividade com a Internet. Por exemplo, 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 você quiser acessar o destino por meio do endereço IP interno dele, é necessário estabelecer conectividade (criar rotas) entre as redes de origem e de destino. É possível fazer isso das seguintes maneiras:
- Se o endpoint de destino estiver em uma rede local, use uma solução do Network Connectivity Center ou uma solução de conectividade híbrida, como Cloud VPN ou Cloud Interconnect.
- Se o endpoint de destino estiver no Google Cloud:
- Configure o Peering de rede VPC entre redes VPC.
- Configure o Cloud VPN entre redes VPC.
- Configure a conectividade de rede usando os spokes VPC do Network Connectivity Center.
Se você já tiver uma conexão com a rede de destino:
- A rede de endpoint de origem não tem uma rota por essa conexão ou usa a rota padrão que passa pelo gateway da Internet. 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 criação e applicability de rotas, 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 endereço IP externo das APIs e serviços do Google, mas o Acesso privado do Google não está ativado na sub-rede da instância.
Recomendações
É possível permitir que a instância de VM do Compute Engine acesse o endereço IP externo de serviços e APIs do Google de uma das seguintes maneiras:
- Ative o Acesso privado do Google para a sub-rede da instância.
- Atribua 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 por túnel VPN não é compatível
Um endpoint de origem com um endereço IP interno tenta alcançar o endereço IP externo de APIs e serviços do Google por meio do túnel VPN para outra rede, mas o Acesso privado do Google precisa estar ativado na rede do endpoint de origem.
Causa provável
O pacote do endpoint de origem para o endereço IP externo das APIs e serviços do Google é roteado pelo túnel do Cloud VPN, mas essa configuração não é aceita.
Recomendações
Se o endpoint de origem for do Google Cloud (como uma instância de VM do Compute Engine), ative o Acesso privado do Google na sub-rede de origem.
Se o endpoint de origem for local, consulte o Acesso privado do Google para hosts locais para 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 que não é compatível com a regra de encaminhamento ou é enviado para uma porta de destino que não corresponde às portas aceitas pela regra de encaminhamento.
Recomendações
Confirme o protocolo e as portas da regra de encaminhamento de destino.
Incompatibilidade de região da regra de encaminhamento
O acesso global não está ativado na regra de encaminhamento, e a região não corresponde à 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 a partir de um endpoint do Google Cloud, como uma instância de VM do Compute Engine, verifique se ele está localizado na mesma região da 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 acesso global para balanceadores de carga de rede de proxy interno regionais.
Firewall bloqueando a verificação de integridade do back-end do balanceador de carga
Os firewalls bloqueiam as sondagens de verificação de integridade e fazem com que os back-ends fiquem indisponíveis para o 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 permitam que o tráfego das sondas do Google Cloud alcance seus back-ends. Caso contrário, os back-ends são considerados não íntegros.
Recomendações
Crie regras de firewall de permissão de entrada de acordo com a tabela de intervalos de IP de sondagem e regras de firewall. 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. Outra opção é ativar o Cloud NAT na sub-rede, a menos que a conexão passe por uma instância de proxy que conceda 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, de uma função do Cloud ou de uma revisão do Cloud Run 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 configurado
Causa provável
O endereço IP de destino é um endereço IP particular, que não pode ser acessado pela Internet. O pacote sai da origem, mas não há um conector de acesso VPC sem servidor configurado para a versão do ambiente padrão do App Engine, a função do Cloud ou a revisão do Cloud Run.
Recomendações
Se você tentar acessar o endpoint de destino usando o endereço IP particular dele, configure um conector de 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á em um 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 na rede com peering, mas essa configuração não é compatível.
Recomendações
Considere usar um dos padrões de conectividade descritos na página Padrões de implantação do Private Service Connect. Também é possível acessar as APIs do Google e os serviços publicados usando back-ends do Private Service Connect.