Os testes de conectividade podem rejeitar um pacote de teste por qualquer um dos seguintes motivos.
Para ver uma lista completa dos motivos possíveis, consulte o artigo Estados da análise de configuração.
Endereço IP estrangeiro não permitido
O pacote é rejeitado 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 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 ela não corresponde aos endereços IP da instância. Isto pode acontecer, por exemplo, quando o pacote é entregue à instância através de 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 existente. Para mais informações, consulte o artigo Ative o encaminhamento de IP para instâncias.
Ignorado devido a uma regra de firewall
O pacote pode ser rejeitado devido a uma regra de firewall, exceto quando o pacote é permitido devido à monitorização de ligações.
Causa provável
Os testes de conetividade podem recusar um pacote de teste porque o pacote 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 à monitorização de ligações na regra da firewall. O acompanhamento de ligações permite que os pacotes de uma ligação existente sejam devolvidos apesar da regra da firewall.
Todas as redes VPC têm 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. Também pode ter uma regra de firewall de negação de saída de prioridade mais elevada.
Para que a conetividade seja bem-sucedida, precisa de uma regra de firewall de saída na origem que permita o acesso ao ponto final de destino e uma regra de firewall de entrada no destino para permitir esta ligação.
As regras de firewall da VPC são com estado. Se o ponto final de destino especificado for normalmente o lado que inicia a comunicação, o tráfego de resposta é permitido automaticamente com a monitorização de ligações, e não é necessária uma regra de firewall de entrada.
Recomendações
Elimine a regra de recusa ou crie uma regra de permissão com base nos detalhes nos resultados dos testes de conectividade. Para mais informações, consulte os artigos Políticas de firewall e Use regras de firewall da VPC. Se a regra da política de firewall que negou o tráfego tiver um tipo de rede especificado, compreenda as regras da política de firewall para determinar se a regra se aplica ao seu exemplo de utilização.
Ignorado porque não existe um trajeto correspondente
O pacote é ignorado porque não existem rotas correspondentes.
Causa provável
Não existe nenhuma 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 eficazes na consola Google Cloud . Se acabou de criar uma nova rota, tenha em atenção que pode demorar algum tempo até que os testes de conectividade recebam uma atualização da configuração e a incorporem na análise.
Se tentar aceder ao ponto final de destino através do respetivo endereço IP interno, certifique-se de que as redes de origem e de destino estão ligadas (por exemplo, através do intercâmbio da rede da VPC, Network Connectivity Center ou uma solução de conetividade híbrida como o Cloud VPN).
Tenha em atenção que o intercâmbio transitivo de VPCs não é suportado. Considere ligar as redes de origem e de destino diretamente ou através de uma solução de conetividade híbrida.
Se tentar aceder ao ponto final de destino através da Internet, certifique-se de que tem um trajeto para o endereço IP de destino com o gateway de Internet de próximo salto.
Se o pacote estiver a passar pelo grupo de pontos finais da rede de conetividade híbrida, considere os requisitos adicionais para a aplicabilidade das rotas. Alguns trajetos que vê na tabela de visualização de trajetos podem não estar disponíveis para tráfego de NEGs híbridos.
Para mais informações, consulte os artigos Trajetos e Use trajetos.
O pacote é enviado para uma rede errada
O pacote é enviado para uma rede não pretendida. Por exemplo, executa um teste a partir 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 salto seguinte numa rede diferente (network-3 no exemplo acima).
Recomendações
Verifique a lista de rotas eficazes e a lista de rotas aplicáveis à instância de origem na Google Cloud consola. Para mais informações sobre a criação de trajetos e a aplicabilidade, consulte os artigos Trajetos e Use trajetos.
O endereço IP do próximo salto do trajeto não está resolvido
O pacote é enviado para um destino através de 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 tem de ser um endereço IPv4 interno principal ou um endereço IPv6 da instância do Compute Engine na rede VPC da rota. Os endereços em redes com peering não são suportados.
Se esta for uma rota com next-hop-ilb, o endereço do salto seguinte tem de ser um endereço do balanceador de carga de rede de passagem interno (as regras de encaminhamento usadas por outros balanceadores de carga, o encaminhamento de protocolos ou os pontos finais do Private Service Connect não são suportados). O endereço IP tem de ser atribuído a um recurso na rede VPC da rota ou numa rede ligada a esta com o intercâmbio da rede da VPC.
Recomendações
Verifique se o endereço IP do próximo salto pertence a um recurso suportado. Para mais informações, consulte as Considerações para instâncias de salto seguinte e as Considerações para saltos seguintes do balanceador de carga de rede de encaminhamento interno.
A instância do próximo salto do trajeto tem uma NIC na rede errada
O pacote é enviado para um destino através de uma rota inválida com a instância do Compute Engine de próximo salto sem um controlador de interface de rede (NIC) na rede da rota.
Causa provável
A instância do Compute Engine usada como salto seguinte de uma rota tem de ter uma NIC na rede da rota (não numa rede VPC com peering).
Recomendações
Verifique se a instância do Compute Engine do próximo salto tem uma NIC na rede da rota. Para mais informações, consulte o artigo Considerações para instâncias de salto seguinte.
O endereço do próximo salto do trajeto não é um endereço IP principal da VM
O pacote é enviado para um destino através de uma rota inválida com o endereço IP do próximo salto (next-hop-address) que não é um endereço IP principal da instância do Compute Engine.
Causa provável
O endereço IP do salto seguinte da rota (next-hop-address) tem de 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 suportados.
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 o artigo Considerações para instâncias de salto seguinte.
O tipo de regra de encaminhamento do próximo salto da rota é inválido
O pacote é enviado para um destino através de uma rota inválida com a regra de encaminhamento do próximo salto (next-hop-ilb) que não é uma regra de encaminhamento do Network Load Balancer de passagem interno.
Causa provável
A regra de encaminhamento do salto seguinte da rota tem de ser uma regra de encaminhamento do balanceador de carga de rede de passagem interna. Para mais informações, consulte o artigo Considerações para os próximos saltos do balanceador de carga de rede de encaminhamento interno.
Recomendações
Crie uma rota que segmente uma regra de encaminhamento suportada em vez da rota inválida.
Tráfego privado para a Internet
Foi enviado um pacote com um endereço de destino interno para um gateway de Internet.
Causa provável
O endereço IP de destino do pacote é um endereço IP privado, que não pode ser alcançado através da Internet. No entanto, o pacote sai da instância do Compute Engine de origem e corresponde a uma rota com o gateway de Internet de próximo salto.
Recomendações
Se quiser aceder ao destino através da Internet, certifique-se de que a instância do Compute Engine de origem tem conetividade com a Internet, por exemplo, tem um endereço IP externo ou usa o Cloud NAT, e use o endereço IP externo do ponto final de destino no teste.
Se quiser aceder ao destino através do respetivo endereço IP interno, tem de estabelecer conetividade (criar caminhos) entre as redes de origem e de destino. Pode fazê-lo de qualquer uma das seguintes formas:
- Se o seu ponto final de destino estiver numa rede no local, use uma solução do Network Connectivity Center ou uma solução de conetividade híbrida, como o Cloud VPN ou o Cloud Interconnect.
- Se o ponto final de destino estiver dentro de Google Cloud:
- Configure o intercâmbio da rede da VPC entre redes da VPC.
- Configure o Cloud VPN entre redes VPC.
- Configure a conetividade de rede através dos raios da VPC do Network Connectivity Center.
Se já tiver uma ligação à rede de destino:
- A rede do ponto final de origem não tem uma rota através desta ligação ou usa a rota predefinida que passa pelo gateway da Internet. Verifique a lista de rotas eficazes e a lista de rotas aplicáveis à instância de origem na Google Cloud consola. Para mais informações sobre a criação e a aplicabilidade de trajetos, consulte os artigos Trajetos e Use trajetos.
Se estiver a testar a conetividade a uma rede no local a partir de uma rede com peering, consulte este exemplo para publicidade personalizada, modo de encaminhamento de rede e troca de rotas personalizadas.
O intercâmbio transitivo de redes VPC não é suportado. Pode usar a VPN ou a interligação para estas duas redes VPC.
O acesso privado à Google não é permitido
A instância do Compute Engine com apenas um endereço IP interno tenta alcançar o endereço IP externo das APIs e dos serviços Google, mas o acesso privado à Google não está ativado na sub-rede da instância.
Recomendações
Pode permitir que a instância de VM do Compute Engine alcance o endereço IP externo das APIs e dos serviços Google de qualquer uma das seguintes formas:
- Ative o acesso privado à 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 à Google através do túnel VPN não é suportado
Um ponto final de origem com um endereço IP interno tenta alcançar o endereço IP externo das APIs e dos serviços Google através do túnel VPN para outra rede, mas o acesso privado à Google tem de estar ativado na rede do ponto final de origem.
Causa provável
O pacote do ponto final de origem para o endereço IP externo das APIs e dos serviços Google é encaminhado através do túnel da Cloud VPN, mas essa configuração não é suportada.
Recomendações
Se o ponto final de origem for um Google Cloud ponto final (como uma instância de VM do Compute Engine), considere ativar o Acesso privado do Google na respetiva sub-rede de origem.
Se o ponto final de origem for um ponto final no local, consulte o artigo Acesso privado do Google para anfitriões no local para obter instruções detalhadas.
Regra de encaminhamento sem correspondência
O protocolo e as portas da regra de encaminhamento não correspondem ao cabeçalho do pacote.
Causa provável
O pacote é enviado através de um protocolo não suportado pela regra de encaminhamento ou é enviado para uma porta de destino que não corresponde às portas suportadas pela regra de encaminhamento.
Recomendações
Confirme o protocolo e as portas da regra de encaminhamento de destino.
Falta de correspondência da região da regra de encaminhamento
A regra de encaminhamento não tem o acesso global ativado e a respetiva região não corresponde à região do pacote.
Causa provável
Consoante o balanceador de carga e o respetivo nível, uma regra de encaminhamento é global ou regional. Para mais detalhes, consulte a tabela de tipos de equilibradores de carga.
Se a regra de encaminhamento for regional, o cliente (por exemplo, a VM ou o conector da VPC) deve estar na mesma região que o balanceador de carga.
Recomendações
Se se ligar ao balanceador de carga a partir de um Google Cloud ponto final, como uma instância de VM do Compute Engine, certifique-se de que está localizado na mesma região que a regra de encaminhamento.
Ao estabelecer ligação a partir de uma rede no local, certifique-se de que o cliente acede ao balanceador de carga através de túneis da Cloud VPN ou anexos de VLAN que se encontram na mesma região que o balanceador de carga. Para mais detalhes, consulte o artigo Equilibradores de carga de aplicações internos e redes ligadas.
Pode ativar o acesso global em balanceadores de carga de aplicações internos e balanceadores de carga de rede de proxy internos regionais para aceder a clientes em qualquer região. Por predefinição, os clientes destes balanceadores de carga têm de estar na mesma região que o balanceador de carga. Para mais informações, consulte os artigos Ative o acesso global para balanceadores de carga de aplicações internos e Ative o acesso global para balanceadores de carga de rede de proxy interno regionais.
Firewall a bloquear a verificação de funcionamento do back-end do balanceador de carga
As firewalls bloqueiam as sondas de verificação de funcionamento para os back-ends 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 funcionamento funcionem, tem de criar regras de firewall de permissão de entrada que permitam que o tráfego dos Google Cloud sondadores alcance os seus back-ends. Caso contrário, os back-ends são considerados em mau estado de funcionamento.
Recomendações
Crie regras de firewall de permissão de entrada de acordo com a tabela Regras de firewall e intervalos de IP de sondas. Para mais informações, consulte o artigo Regras de firewall necessárias.
Nenhum endereço externo disponível
Uma instância de VM com apenas um endereço IP interno tentou aceder a anfitriões externos através de uma rota cujo próximo salto é a gateway de Internet predefinida. Esperado quando o Cloud NAT não está ativado na sub-rede ou quando não existe outra rota predefinida que use um tipo diferente de próximo salto (como uma VM proxy).
Causa provável
Uma instância com apenas um endereço IP interno tentou aceder a um anfitrião externo, mas não tinha um endereço IP externo ou o Cloud NAT não estava ativado na sub-rede.
Recomendações
Se quiser aceder a pontos finais externos, pode atribuir um endereço IP externo à sua instância. Em alternativa, pode ativar o Cloud NAT na respetiva sub-rede, a menos que a ligação passe 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 à qual está a tentar aceder 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 tem back-ends configurados.
O tipo de tráfego está bloqueado
O tipo de tráfego está bloqueado e não pode configurar uma regra de firewall para o ativar. Para mais detalhes, consulte o artigo Tráfego sempre bloqueado.
Causa provável
Este tipo de tráfego está bloqueado por predefinição e não pode ser ativado através da criação de regras de firewall. Seguem-se alguns cenários comuns:
- Enviar tráfego de saída para um destino externo com a porta TCP 25 (SMTP). Para mais detalhes, consulte o artigo Tráfego sempre bloqueado.
- Enviar tráfego para uma porta não suportada numa instância do Cloud SQL. Por exemplo, enviar tráfego para a porta TCP 3310 para uma instância do Cloud SQL MySQL com a porta 3306 aberta.
- Enviar tráfego de saída a partir 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 use um protocolo diferente de TCP ou UDP.
Recomendações
Para tráfego SMTP de saída (tráfego de saída para um destino externo com a porta TCP 25), consulte o artigo Enviar email a partir de uma instância.
Para o protocolo DHCP, incluindo pacotes UDP IPv4 para a porta de destino 68 (respostas DHCPv4) e pacotes UDP IPv6 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 conetividade do Cloud SQL, certifique-se de que a porta usada está correta.
As etiquetas de rede não são suportadas pela saída da VPC direta nas regras de firewall de entrada
O pacote é rejeitado porque a saída da VPC direta não suporta etiquetas de rede de origem nas regras de firewall de entrada.
Causa provável
A correspondência de regras de firewall de entrada por etiquetas de rede de origem não é suportada para ligações do Cloud Run através da saída da VPC direta. Para mais informações, consulte a secção Limitações.
Recomendações
Atualize as regras da firewall para usar intervalos de IP de origem em vez de etiquetas de rede de origem para fazer corresponder o tráfego de ligações do Cloud Run através da saída do VPC direto.
O conetor do Acesso a VPC sem servidor não está configurado
Causa provável
O endereço IP de destino é um endereço IP privado, que não é acessível através da Internet. O pacote sai da origem, mas não existe nenhum conetor 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 tentar aceder ao ponto final de destino através do respetivo endereço IP privado, certifique-se de que configurou 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 conetor do Acesso a VPC sem servidor não está em execução
O pacote foi rejeitado porque o conetor do Acesso a VPC sem servidor não está em execução.
Causa provável
O pacote foi rejeitado porque todas as instâncias do conetor do Acesso a VPC sem servidor estão paradas.
Recomendações
Para ver uma lista de passos de resolução de problemas, consulte o artigo Resolução de problemas.
A ligação do Private Service Connect não é aceite
O pacote foi rejeitado porque a ligação do Private Service Connect não foi aceite.
Causa provável
O ponto final do Private Service Connect está num projeto que não foi aprovado para estabelecer ligação ao serviço. Para mais informações, consulte Ver detalhes do ponto final.
Recomendações
Certifique-se de que o ponto final do Private Service Connect está num projeto aprovado para estabelecer ligação ao serviço gerido.
O ponto final do Private Service Connect é acedido a partir de uma rede com peering
O pacote é enviado para o ponto final do Private Service Connect na rede com peering, mas essa configuração não é suportada.
Recomendações
A Google recomenda que faça a transição para uma arquitetura de hub e raios que use o Network Connectivity Center para ativar a propagação da ligação do Private Service Connect.
Em alternativa, considere um dos seguintes padrões de conetividade:
Se for suportado pelo produtor do serviço, faça a transição para um padrão de conetividade de acesso multiponto.
Se for suportado pelo produtor do serviço, configure um balanceador de carga do consumidor suportado com um back-end do Private Service Connect.
Para receber assistência adicional, contacte o apoio técnico do produtor do serviço ou o seu Google Cloud representante.