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, o Connectivity Tests avalia a acessibilidade usando a análise de configuração e a análise do plano de dados em tempo real. 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.
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.
As etapas a seguir descrevem os checkpoints que correspondem a cada ponto no diagrama de trace. A verificação pode falhar em qualquer ponto. Os resultados da consulta mostram o motivo de cada falha. Para uma lista completa de estados e mensagens de teste, consulte Estados de análise de configuração.
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.
-
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.
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.
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.
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.
Se necessário, os testes de conectividade executam uma verificação de spoofing no pacote que chega à segunda VM.
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.
É 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.
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.
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 que entra em um endpoint de destino é bloqueado por uma regra de política de firewall hierárquica ou uma regra de firewall de VPC. |
|
| Nenhuma rota correspondente | Não foi possível encontrar uma rota para o endpoint de destino. |
|
| 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.
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 Google 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 resultados de teste listados 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 sairia da rede e seria enviado para uma rede a que 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 o estado encaminhado para redes VPC com peering.
A seguir
- Cenários comuns de teste
- Saiba mais sobre os Testes de conectividade
- Resolver problemas de teste de conectividade