Um exemplo de utilização comum dos testes de conetividade é o teste entre duas instâncias de máquinas virtuais (VMs) do Compute Engine nas mesmas redes da nuvem virtual privada (VPC) ou em redes da VPC com intercâmbio.
Para este tipo de teste, os testes de conetividade avaliam a acessibilidade através da análise da configuração e da análise do plano de dados em direto. Para analisar a configuração, os testes de conetividade identificam e avaliam um caminho de rastreio.
Os diagramas de rastreio nesta página usam os símbolos descritos na legenda seguinte.O diagrama seguinte mostra o caminho de rastreio típico entre duas instâncias de VM. O objeto Match routes
pode representar rotas que direcionam o tráfego numa única rede da VPC ou entre duas redes da VPC em intercâmbio.
Os passos seguintes descrevem os pontos de verificação que correspondem a cada ponto no diagrama de rastreio. A verificação pode falhar em qualquer ponto de verificação. Os resultados da consulta mostram o motivo de cada falha. Para ver uma lista completa dos estados de teste e das mensagens, consulte os Estados da análise da configuração.
Os testes de conetividade verificam se a VM de origem pode enviar pacotes de saída com o endereço IP de origem especificado ou, caso contrário, podem usar o processo de verificação de spoofing por predefinição.
-
Os testes de conetividade executam uma verificação de spoofing quando um pacote simulado para ou a partir de uma instância de VM usa um endereço IP que não é propriedade dessa instância. Os endereços IP pertencentes a uma VM incluem todos os endereços IP internos da VM e os endereços IP secundários.
Se o endereço for um endereço que parece ter origem no tráfego externo, também denominado endereço estrangeiro, o endereço IP falha na verificação de roubo de identidade.
Para determinar se os pacotes de rastreio podem ser enviados a partir da origem, os Connectivity Tests validam as regras de firewall de saída adequadas. Como parte deste processo, os testes de conetividade começam por avaliar as regras de políticas de firewall hierárquicas existentes. Para ver detalhes sobre como as regras da política de firewall hierárquica e as regras de firewall da VPC afetam a conetividade, consulte os exemplos de políticas de firewall hierárquicas.
Os testes de conetividade encontram (correspondem) uma rota para o endereço IP de destino, de acordo com a ordem de encaminhamento. Se não estiverem disponíveis outros trajetos para a instância de VM de destino, os testes de conectividade usam o trajeto estático predefinido com o próximo salto como gateway de Internet. Todas as redes VPC usam esta rota predefinida, a menos que a tenha removido.
Os testes de conetividade verificam se as regras da firewall de entrada da rede permitem que o pacote chegue à VM de destino. Mais uma vez, os testes de conetividade começam por avaliar as regras de políticas de firewall hierárquicas existentes.
Se necessário, os testes de conetividade executam uma verificação de spoofing no pacote que chega à segunda VM.
Os testes de conetividade verificam se a VM de destino pode receber um pacote com o endereço IP de destino especificado. Se este endereço for um endereço IP estrangeiro, a VM de destino tem de ter o encaminhamento de IP ativado. Um endereço IP externo é um endereço que não pertence à VM.
A captura de ecrã seguinte da Google Cloud consola mostra os resultados de um teste de VM para VM.
A análise da configuração mostra um resultado de O pacote pode ser entregue.
Na resposta da API, esta etiqueta corresponde a um
estado final de Deliver
.
Este resultado mostra que a análise da configuração validou a conetividade
de rede para todos os recursos Google Cloud no caminho da VM de origem
para a VM de destino. Neste caso, o trajeto incluía duas regras de firewall da VPC: uma regra de firewall da VPC implícita (denominada default
) e uma que foi criada para esta rede da VPC.
Além disso, os testes de conetividade verificaram dinamicamente se a VM de destino está acessível através da sondagem ativa. O campo Resultado da última transmissão de pacotes mostra os detalhes deste resultado.

Pode expandir cada um dos cartões no caminho do rastreio para ver mais detalhes.
O exemplo seguinte mostra um cartão expandido para uma regra de firewall de entrada. Este cartão inclui informações sobre a rede VPC, a ação configurada para a regra de firewall (permitir) e a prioridade da regra.

Quando um rastreio contém uma rota de rede da VPC com o próximo salto como uma rede da VPC em intercâmbio, o início do rastreio não é uma instância de VM, mas sim uma rede da VPC. Este tipo de rastreio valida as regras de firewall e os encaminhamentos ao nível da rede, porque o endereço IP que testa provém de um intervalo de rede em vez de uma instância de VM.
As redes com peering podem existir no mesmo projeto ou em projetos diferentes. O exemplo de rastreio seguinte mostra redes com peering em projetos diferentes.
Falhas de teste para redes de VPC
A tabela seguinte apresenta falhas comuns para testes em redes de VPC.
Tipo de falha | Descrição | Resultados do rastreio |
---|---|---|
Bloqueado por uma regra de firewall | O tráfego que sai de um ponto final de origem ou entra num ponto final de destino é bloqueado por uma regra de política de firewall hierárquica ou uma regra de firewall da VPC. |
|
Nenhum trajeto correspondente | Não foi possível encontrar um trajeto para o ponto final de destino. |
|
A instância não está em execução | A instância de VM de destino existe, mas não está em execução. | A análise determina que o pacote pode ter sido rejeitado. |
Salto seguinte inválido | O próximo salto configurado para uma instância de VM já não existe e a rota para essa instância é inválida. | A análise determina que o pacote pode ter sido rejeitado. |
A captura de ecrã seguinte ilustra um rastreio que falhou porque a conetividade foi bloqueada por uma regra de política de firewall hierárquica de entrada.

Falhas de teste para redes de VPC partilhada
Nas redes de VPC partilhada, não ter autorizações para o projeto anfitrião ou o projeto de serviço pode causar as falhas de teste indicadas na tabela seguinte.
Tipo de falha | Comportamento | Resultados do rastreio |
---|---|---|
Autorizações apenas para o projeto anfitrião | Não pode executar o rastreio porque não tem autorizações para o projeto de serviço onde se encontra o endereço IP de destino. | A análise da configuração mostra um resultado de Análise da configuração
anulada. Na resposta da API, esta etiqueta corresponde a um
estado final de
Abort . |
Autorizações apenas para o projeto de serviço |
Não pode executar o rastreio nem selecionar a rede do projeto anfitrião na Google Cloud consola porque não tem autorização. Uma vez que o projeto anfitrião é proprietário das configurações de rede, não é possível avançar com um rastreio em relação aos recursos no projeto de serviço sem acesso às regras de firewall da VPC, às rotas de rede ou aos endereços IP no projeto anfitrião. |
O resultado geral da acessibilidade é
Undetermined
porque os testes de conetividade não conseguem determinar se o pacote pode ser
entregue ao destino. |
Falhas de teste para redes de intercâmbio da rede da VPC
Com o peering de redes VPC, não ter autorização para o projeto da rede peered
Google Cloud da rede primary
pode causar
o resultado do teste apresentado na tabela seguinte.
Tipo de falha | Comportamento | Resultados do rastreio |
---|---|---|
Não tem autorizações para a configuração do projeto na rede de VPC com peering. | Os testes de conetividade só podem rastrear as configurações no projeto da rede principal. | A análise da configuração mostra um resultado de O pacote pode ser encaminhado.
Este resultado indica que um pacote sairia da rede e seria enviado
para uma rede à qual não tem acesso. Neste caso, o pacote foi encaminhado para um gateway de rede com peering. Na resposta da API,
este estado corresponde a um
estado final de
Forward . |
O caminho de rastreio seguinte mostra o estado de encaminhamento para redes de VPC com peering.
O que se segue?
- Cenários de teste comuns
- Saiba mais sobre os testes de conetividade
- Resolva problemas com os testes de conetividade