Testar a conectividade nas redes VPC

Um caso de uso comum dos Testes de conectividade é o teste entre duas instâncias de máquina virtual (VM, na sigla em inglês) do Compute Engine nas mesmas redes de nuvem privada virtual (VPC, na sigla em inglês) ou com peering.

Para esse tipo de teste, os Testes de conectividade avaliam a acessibilidade usando a análise de configuração e a verificação dinâmica. Para analisar a configuração, os Testes de conectividade identificam e avaliam um caminho de trace.

Os diagramas de trace nesta página usam os símbolos descritos na legenda a seguir.
Symbol Nome Significado
Diamante cinza
Legenda para o diagrama de trace de pacote: diamante cinza.
Check Point Um ponto de decisão em que o Connectivity Tests verifica uma configuração e decide se um pacote de trace precisa ser encaminhado, entregue ou descartado.
Retângulo azul
Legenda para o diagrama de trace de pacote: retângulo azul.
Salto Uma etapa no caminho de encaminhamento para um pacote de trace, representando um recurso do Google Cloud que encaminha um pacote para o próximo salto em uma rede VPC. Por exemplo, para um proxy do Cloud Load Balancing ou para um túnel de VPN em nuvem.
Hexágono laranja
Legenda para o diagrama de trace de pacote: hexágono laranja.
Endpoint A origem ou destino de um pacote de trace.

O diagrama a seguir mostra o caminho de trace típico entre duas instâncias de VM. O objeto Match routes pode representar rotas que direcionam o tráfego em uma única rede VPC ou entre duas redes VPC com peering.

VM de origem para o trace da VM de destino.
VM de origem para o trace da VM de destino

As etapas a seguir descrevem os checkpoints que correspondem a cada ponto no diagrama de trace. Em cada checkpoint, a verificação pode falhar. Os resultados da consulta mostram o motivo de cada falha. Para uma lista completa de estados e mensagens de teste, consulte Interpretar estados de análise de configuração.

  1. Os Testes de conectividade verificam se a VM de origem pode enviar pacotes de saída com o endereço IP de origem especificado ou usar como padrão o processo de verificação de spoofing.

  2. Os testes de conectividade fazem uma verificação de spoofing quando um pacote simulado de ou para uma instância de VM usa um endereço IP que não pertence a ela. Os endereços IP pertencentes a uma VM incluem todos os endereços IP internos da VM e endereços IP secundários.

    Se o endereço for um endereço que parece originar-se de tráfego externo, também chamado de endereço externo, o endereço IP falhará na verificação de spoofing.

  3. Para determinar se os pacotes de rastreamento podem ser enviados da origem, os testes de conectividade verificam as regras de firewall de saída apropriadas. Como parte desse processo, os testes de conectividade começam avaliando todas as regras de política de firewall hierárquicas que existem. Para saber como as regras de política de firewall hierárquicas e as regras de firewall da VPC afetam a conectividade, consulte Exemplos de política de firewall hierárquico.

  4. O Connectivity Tests localiza (corresponde) uma rota para o endereço IP de destino, de acordo com a ordem de roteamento. Se nenhuma outra rota estiver disponível para a instância da VM de destino, o Connectivity Tests usará a rota estática padrão com o próximo salto como o gateway da Internet. Todas as redes VPC usam essa rota padrão, a menos que você a tenha removido.

  5. O Connectivity Tests verifica se as regras de firewall de entrada de rede permitem que o pacote chegue à VM de destino. Novamente, os testes de conectividade começam avaliando todas as regras de política de firewall hierárquicas que existem.

  6. Se necessário, os testes de conectividade executam uma verificação de spoofing no pacote que chega à segunda VM.

  7. O Connectivity Tests verifica se a VM de destino pode receber um pacote com o endereço IP de destino especificado. Se esse for um endereço IP estrangeiro, a VM de destino precisará ter o encaminhamento de IP ativado. Um endereço IP externo é um endereço que não pertence à VM.

A captura de tela a seguir do Console do Google Cloud mostra os resultados de um teste de VM para VM.

A análise da configuração mostra um resultado Pacote pode ser entregue. Na resposta da API, esse rótulo corresponde a um estado final de Deliver).

Este resultado mostra que a análise da configuração validou a conectividade de rede para cada recurso do Google Cloud no caminho da VM de origem até a VM de destino. Nesse caso, a rota incluía duas regras de firewall VPC: uma regra de firewall VPC implícita (chamada default) e uma criada para esta rede VPC.

Além disso, os Testes de conectividade verificaram dinamicamente se a VM de destino está acessível usando a sondagem ativa. O campo Último resultado de transmissão do pacote mostra os detalhes desse resultado.

Captura de tela do Console do Cloud para trace de VM para VM.
Captura de tela do Console do Cloud para trace de VM para VM

É possível expandir cada um dos cards no caminho de trace para visualizar mais detalhes.

O exemplo a seguir mostra um card expandido para uma regra de firewall de entrada. Este card inclui informações sobre a rede VPC, a ação configurada para a regra de firewall (permitir) e a prioridade da regra.

Card de regras do firewall de entrada expandido.
Card de regras do firewall de entrada expandido

Quando um trace contém uma rota de rede VPC com o próximo salto como uma rede VPC com peering, o início do trace não é uma instância de VM, mas uma rede VPC. Esse tipo de trace valida regras de firewall e rotas no nível da rede porque o endereço IP que você testa vem de um intervalo de redes em vez de uma instância de VM.

Redes com peering podem existir no mesmo projeto ou em diferentes. O exemplo de trace a seguir mostra redes com peering em diferentes projetos.

Trace de VM para VM por meio de uma rede VPC com peering acessível em um projeto diferente.
Trace de VM para VM por uma rede VPC com peering acessível em um projeto diferente

Falhas de teste para redes VPC

A tabela a seguir lista falhas comuns para testes nas redes VPC.

Tipo de falha Descrição Resultados do trace
Bloqueado por uma regra de firewall O tráfego que sai de um endpoint de origem ou de destino é bloqueado por uma regra hierárquica de política de firewall ou por uma regra de firewall VPC.
  • Se a conectividade for bloqueada por uma regra de política de firewall hierárquica, o trace incluirá o nome da política. A pessoa que executa o teste talvez não tenha permissão para visualizar os detalhes da política. Para mais detalhes sobre essa situação, consulte Resolver problemas na política hierárquica de firewall.
  • Se a conectividade for bloqueada por uma regra de firewall VPC, o trace listará o nome da regra de firewall de entrada ou saída relevante.
Nenhuma rota correspondente Não foi possível encontrar uma rota para o endpoint de destino.
  • Se as instâncias de VM de origem e de destino estiverem em redes VPC diferentes e essas redes não estiverem em peering, a análise determinará que o Pacote pode ser descartado.
  • Se as VMs estiverem na mesma rede, mas uma rota correspondente não for encontrada, o tráfego será enviado na rota estática padrão, com um próximo salto para o gateway da Internet. Nesse caso, o tráfego nunca chega à VM de destino, e a análise determinará que o Pacote pode ser descartado.
  • Se não houver rota para um gateway de Internet, a análise determinará que o Pacote pode ser descartado.
Instância não em execução A instância da VM de destino existe, mas não está em um estado de execução. A análise determina que o Pacote pode ser descartado.
Próximo salto inválido O próximo salto configurado para uma instância de VM não existe mais e a rota para essa instância é inválida. A análise determina que o Pacote pode ser descartado.

A captura de tela a seguir ilustra um trace que falhou porque a conectividade foi bloqueada por uma regra de política de firewall hierárquica de entrada.

Captura de tela do Console do Cloud para um trace bloqueado por uma regra de política de firewall hierárquica.
Captura de tela do Console do Cloud de um trace bloqueado por uma regra de política de firewall hierárquica

Falhas de teste para redes VPC compartilhadas

Nas redes VPC compartilhadas, não ter permissões para o projeto host ou o projeto de serviço pode causar as falhas de teste listadas na tabela a seguir.

Tipo de falha Comportamento Resultados do trace
Permissões apenas para o projeto host Não é possível executar o trace porque você não tem permissões para o projeto de serviço em que o endereço IP de destino está localizado. A análise de configuração mostra um resultado de Análise de configuração cancelada. Na resposta da API, esse rótulo corresponde a um estado final de Abort.
Permissões apenas para o projeto de serviço

Não é possível executar o trace ou selecionar a rede do projeto host no Console do Cloud porque você não tem permissão.

Como o projeto host tem configurações de rede, um trace em relação aos recursos no projeto de serviço não pode prosseguir sem acesso a regras de firewall de VPC, rotas de rede ou endereços IP no projeto host.

O resultado geral de acessibilidade é Undetermined porque os Testes de conectividade não conseguiram determinar se o pacote pode ser entregue ao destino.

Falhas de teste em redes de peering de rede VPC

Com o peering de rede VPC, não ter permissão para o projeto do Google Cloud da rede peered da rede primary pode causar as falhas de teste listadas na tabela a seguir.

Tipo de falha Comportamento Resultados do trace
Você não tem permissões para a configuração do projeto na rede VPC com peering. O Connectivity Tests pode rastrear apenas as configurações no projeto da rede principal. A análise da configuração mostra um resultado Pacote pode ser encaminhado. Esse resultado indica que um pacote deixaria a rede e seria enviado para uma rede à qual você não tem acesso. Nesse caso, o pacote foi encaminhado para um gateway de rede com peering. Na resposta da API, esse estado corresponde a um estado final de Forward.

O caminho de trace a seguir mostra essa falha nas redes VPC com peering.

Trace de VM para VM por meio de uma rede VPC com peering inacessível em um projeto diferente.
Trace de VM para VM por uma rede VPC com peering inacessível em um projeto diferente

A seguir