Esta página mostra exemplos de configurações inválidas ou inconsistentes dos recursos do Google Cloud que você pode encontrar ao solucionar problemas de sua rede com os testes de conectividade.
Para instruções sobre como executar testes, consulte Criar e executar testes de conectividade.
Para uma descrição do teste de e para os tipos comuns de origem e destino da rede, consulte Casos de uso comuns.
Detectar uma configuração inválida
Existem muitos tipos diferentes de configurações inválidas, ou seja, as configurações que não estão corretas ou que foram atualizadas e não são mais válidas.
Um exemplo é uma instância de máquina virtual (VM, na sigla em inglês) que foi configurada como um gateway NAT, mas que foi excluída ou migrada. Nesse caso, a rota para a instância da VM ainda existe.
No diagrama a seguir, VM1 em Network 1 precisa acessar dados em VM2, VM3 e VM4 em Network 2 por meio de uma instância de VM chamada nat_vm_1.
No entanto, nat_vm_1 não existe mais porque foi migrado para uma nova VM,
nat_vm_2.
A rota configurada de VM1 para as outras três instâncias da VM ainda aponta para nat_vm_1 como o próximo salto. No entanto, como nat_vm_1 não existe mais e não há rota para nat_vm_2, VM1 não pode se comunicar com as outras instâncias da VM.
Um Connectivity Test executado de VM1 a VM2 revela que o tráfego entre VM1 e as outras instâncias da VM foi descartado devido a um próximo salto inválido para a rota para as outras VMs.
Por outro lado, no caso de uso de uma configuração inconsistente,
VM3 não tem uma tag de rede, tornando a configuração do balanceador de carga inconsistente
nos back-ends do balanceador de carga. No entanto, a configuração do VM3 em si é válida, porque a configuração de uma instância da VM não requer uma tag.
Detectar uma configuração inconsistente
Você também pode usar os testes de conectividade para validar rotineiramente as configurações inconsistentes. Essas configurações podem não estar causando problemas de conectividade atuais, mas podem reduzir a redundância de rede sem querer ou causar problemas de desempenho no futuro.
O balanceador de carga está configurado para enviar tráfego para um endereço IP externo
de 35.184.176.28. O tráfego para esse endereço é distribuído por três
back-ends: VM1, VM2 e VM3. No entanto, devido a uma tag de rede ausente em VM3,
a regra de firewall de nuvem privada virtual (VPC) permite tráfego de intervalos de IP externos
para VM1 e VM2, mas nega esse tráfego para VM3.
O seguinte trace dos intervalos de origem permitidos configurados para o balanceador de carga até o endereço IP externo de destino do balanceador de carga mostra a configuração pretendida e a inconsistência. VM1 e VM2 estão acessíveis, mas VM3 está inacessível. Somente os dois back-end estão acessíveis porque VM3 falhou na verificação de integridade.
