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 só pode enviar ou receber pacotes com um endereço IP estrangeiro quando o encaminhamento de IP está ativado.
Causa provável
A instância da VM não tem o encaminhamento de IP ativado, 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 é encaminhado para a 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 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 o pacote é 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 de bloqueio ou a uma regra de 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 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 qualquer lugar e bloqueiam o tráfego de entrada de qualquer lugar. Você também pode ter uma regra de firewall de saída de negação de prioridade mais alta.
Para que a conectividade seja estabelecida, você precisa de uma regra de firewall de saída na origem, permitindo 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 por não ter uma rota correspondente
O pacote é descartado porque não há rotas correspondentes.
Causa provável
Não há uma rota ativa que corresponda 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 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 de 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).
O peering de VPC transitivo não é compatível. Considere conectar as redes de origem e de destino diretamente ou usando uma solução de conectividade híbrida.
Se você tentar acessar o endpoint de destino pela Internet, verifique se tem uma rota para o endereço IP de destino com o gateway de Internet do próximo salto.
Se o pacote passar pelo grupo de endpoints de rede de conectividade híbrida, considere requisitos adicionais para a aplicabilidade de rotas. Algumas rotas mostradas na tabela de visualização de rotas podem não estar disponíveis para tráfego de NEGs híbridas.
Para mais informações, consulte Rotas e Usar rotas.
O pacote é enviado para uma rede errada
O pacote é 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 de rotas e a 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 endereço IP do próximo salto não atribuído a nenhum recurso.
Causa provável
Se esta for uma rota com next-hop-address, o endereço do próximo salto precisa ser
um endereço IPv4 interno principal ou um endereço IPv6 da instância do Compute Engine
na rede VPC da rota. Não há suporte para endereços em redes com peering.
Se esta for uma rota com next-hop-ilb, o endereço do próximo salto precisa ser um
endereço do balanceador de carga de rede de passagem interna (regras de encaminhamento usadas por outros balanceadores de carga,
encaminhamento de protocolo ou como endpoints do Private Service Connect não são
aceitas). 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 compatível. Para mais informações, consulte Considerações sobre instâncias de 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 NIC na rede errada
O pacote é enviado para um destino usando uma rota inválida com a instância do Compute Engine do próximo salto sem um controlador de interface de rede (NIC, na sigla em inglês) na rede da rota.
Causa provável
A instância do Compute Engine usada como um próximo salto de rota precisa ter uma NIC na rede da rota, e não uma rede VPC com peering.
Recomendações
Verifique se a instância do próximo salto do Compute Engine tem uma NIC na rede da rota. Para mais informações, consulte Considerações para instâncias do próximo salto.
O endereço IP 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 um endereço IP primário 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.
Não é possível usar intervalos de endereços IP de alias.
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) não sendo 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 que tenha como destino 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 próximo salto do gateway de Internet.
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, se ela tem um endereço IP externo ou usa o NAT do Cloud) e use o endereço IP externo do endpoint de destino no teste.
Se você quiser acessar o destino pelo endereço IP interno, estabeleça a conectividade (crie 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 o Cloud VPN ou o 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 de VPC do Network Connectivity Center.
Se você já tiver uma conexão com a rede de destino:
- A rede do 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 a criação de rotas e a 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 endereço IP externo das APIs e dos 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 das APIs e dos serviços 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 à NIC 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 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 das APIs e dos 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 um endpoint do Google Cloud (como uma instância de VM do Compute Engine), ative o Acesso particular do Google na sub-rede de origem.
Se o endpoint de origem for local, consulte o artigo Acesso privado do Google para hosts locais para instruções detalhadas.
Regra de encaminhamento incompatível
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 é aceito pela 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.
Divergência na região da regra de encaminhamento
A regra de encaminhamento não tem o acesso global ativado, e a região dela não corresponde à 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 de um endpoint do Google Cloud, como uma instância de VM do Compute Engine, verifique se ele está localizado na mesma região que a 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 bloqueando a verificação de integridade do back-end do balanceador de carga
Os firewalls bloqueiam as sondagens da 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 entrada que permitam que o tráfego das sondas do Google Cloud acesse os 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 Intervalos de IP e regras de firewall da sondagem. Para mais informações, consulte Regras de firewall obrigató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 Run 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 Run 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 Run 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 Run 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 pareada
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 e os serviços publicados do Google usando back-ends do Private Service Connect.