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 externo quando o encaminhamento de IP está ativado.
Causa provável
A instância de VM não tem o encaminhamento de IP ativado, mas o endereço IP de origem ou de destino do pacote que passa por ele 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 um 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 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 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 que pacotes para uma conexão atual retornem, apesar da regra de firewall.
Toda rede VPC tem duas regras de firewall implícitas que permitem o tráfego de saída 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 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 endereço IP de destino) na rede de pacotes e na região.
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 na 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).
Não há suporte ao peering de VPC transitivo. Considere conectar as redes de origem e destino diretamente ou usar 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 estiver passando pelo grupo de endpoints de rede de conectividade híbrida, considere outros requisitos para aplicabilidade das rotas. Algumas rotas exibidas 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 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 é 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 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 da instância do Compute Engine na rede VPC da rota. Endereços em redes com peering não são compatíveis.
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, encaminhamento de protocolo ou como 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 ele 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 de 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. A instância do próximo salto do Compute Engine não tem um controlador de interface de rede (NIC) na rede da rota.
Causa provável
A instância do Compute Engine usada como próximo salto da rota precisa ter uma placa de rede (NIC) 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 primário da VM
O pacote é enviado para um destino usando uma rota inválida, e o endereço IP do próximo salto (next-hop-address) não é 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.
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. A regra de encaminhamento do próximo salto (next-hop-ilb) 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 para 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 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 da 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, se 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 pelo endereço IP interno, será necessário estabelecer conectividade (criar rotas) entre as redes de origem e destino. É possível fazer isso de uma das seguintes maneiras:
- Se o endpoint de destino estiver dentro de 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.
- 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 do endpoint de origem não tem uma rota que passa 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 e a 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 alcançar 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 alcance o endereço IP externo das APIs e serviços do Google de uma das seguintes maneiras:
- Ative o Acesso privado do Google para a 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 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 é compatível.
Recomendações
Se o endpoint de origem for um endpoint do Google Cloud (como uma instância de VM do Compute Engine), considere ativar o Acesso privado do Google na sub-rede de origem.
Se o endpoint de origem for local, consulte 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 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 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 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 acesso global para balanceadores de carga de aplicativo internos e Ativar 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 sondagens de verificação de integridade e fazem com que os back-ends fiquem indisponíveis 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 permitam que o tráfego das sondas do Google Cloud alcance os back-ends. Caso contrário, os back-ends serã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. Se preferir, ative 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 têm 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, verifique se configurou 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 ao 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.