Um caso de uso comum do recurso Testes de Conectividade é o teste entre duas instâncias de máquina virtual (VM) do Compute Engine em redes de nuvem privada virtual (VPC) com peering ou nas mesmas redes.
Para esse tipo de teste, o recurso Testes de Conectividade 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, a ferramenta identifica e avalia um caminho de trace.
Os diagramas de traces nesta página usam os símbolos descritos na legenda a seguir.
O diagrama a seguir mostra o caminho de trace normal entre duas instâncias de VM. O objeto Match routes pode representar rotas que fazem o rotemento do 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 traces. A verificação pode falhar em qualquer ponto de verificação. 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.
O recurso Testes de Conectividade verifica 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 traces podem ser enviados da origem, os Testes de Conectividade verificam as regras de firewall de saída apropriadas. Como parte desse processo, o recurso começa avaliando todas as regras de políticas de firewall hierárquicas. Para saber como essas regras e as regras de firewall da VPC afetam a conectividade, consulte Exemplos de políticas de firewall hierárquicas.
Os Testes de Conectividade localizam (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, os Testes de Conectividade usarão a rota estática padrão com o próximo salto como o gateway de internet. Todas as redes VPC usam essa rota padrão, a menos que ela tenha sido removida.
Os Testes de Conectividade verificam se as regras de firewall de entrada da 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 atuais.
Se necessário, esse recurso pode executar uma verificação de spoofing no pacote que chega à segunda VM.
Os Testes de Conectividade verificam 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 como resultado Foi possível entregar o pacote.
Na resposta da API, esse rótulo corresponde a um
estado final de Deliver.
Esse resultado mostra que a análise da configuração validou a conectividade
de rede para cada recurso de Google Cloud no caminho da VM
de origem até a VM de destino. Nesse caso, a rota incluía duas
regras de firewall da VPC: uma regra
de firewall da VPC implícita (chamada default) e outra criada para esta rede VPC.
Além disso, os Testes de Conectividade verificaram dinamicamente que 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 do trace para visualizar mais detalhes.
O exemplo a seguir mostra um card expandido para uma regra de firewall de entrada. O 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 da 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 dos 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 o recurso Testes de Conectividade não conseguiu 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 Google Cloud da rede peered
da rede primary pode causar
o resultado de teste listado 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. | Os Testes de Conectividade podem rastrear apenas as configurações no projeto da rede principal. | A análise da configuração mostra o resultado O 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 de teste comuns
- Saiba mais sobre os Testes de Conectividade
- Resolver problemas dos Testes de Conectividade