Os testes de conetividade são uma ferramenta de diagnóstico que lhe permite verificar a conetividade entre pontos finais de rede. Analisa a sua configuração e, em alguns casos, realiza uma análise do plano de dados em direto entre os pontos finais. Um ponto final é uma origem ou um destino de tráfego de rede, como uma VM, um cluster do Google Kubernetes Engine (GKE), uma regra de encaminhamento do balanceador de carga ou um endereço IP na Internet.
Para analisar as configurações de rede, os testes de conetividade simulam o caminho de encaminhamento esperado de um pacote através da sua rede da nuvem virtual privada (VPC), dos túneis da VPN na nuvem ou das associações de VLAN. Os testes de conetividade também podem simular o caminho de encaminhamento de entrada esperado para recursos na sua rede VPC.
Para alguns cenários de conetividade, os testes de conetividade também realizam uma análise do plano de dados em direto. Esta funcionalidade envia pacotes através do plano de dados para validar a conetividade e fornece diagnósticos de base da latência e da perda de pacotes. Se o trajeto for suportado para a funcionalidade, cada teste que executar inclui um resultado da análise do plano de dados em direto.
Para saber como criar e executar testes para vários cenários, consulte o artigo Crie e execute testes de conetividade.
A API para testes de conetividade é a API Network Management. Para mais informações, consulte a documentação da API.
Porquê usar os testes de conetividade?
Os testes de conetividade podem ajudar a resolver os seguintes problemas de conetividade de rede:
- Configurações inconsistentes não intencionais
- Configurações obsoletas causadas por alterações ou migrações da configuração de rede
- Erros de configuração para uma variedade de serviços e funções de rede
Ao testar serviços geridos pela Google, os testes de conectividade também podem ajudar a determinar se existe um problema na sua rede VPC ou na rede VPC pertencente à Google usada para os recursos de serviço.
Como os testes de conetividade analisam as configurações
Ao analisar as configurações de rede, os testes de conetividade usam uma máquina de estado abstrata para modelar a forma como uma rede VPC deve processar pacotes. Google Cloud processa um pacote em vários passos lógicos.
A análise pode seguir muitos caminhos possíveis
Devido à variedade de serviços e funcionalidades da rede VPC que a análise de configuração suporta, um pacote de teste que atravessa uma configuração de rede VPC pode seguir muitos caminhos possíveis.
O diagrama seguinte mostra um modelo de como a análise de configuração simula o tráfego de rastreio entre duas instâncias de máquinas virtuais (VMs) do Compute Engine: uma à esquerda e outra à direita.
A análise depende da sua infraestrutura de rede
Consoante as configurações de rede e de recursos, este tráfego pode passar por um túnel de VPN do Google Cloud, uma rede VPC, um balanceador de carga ou uma rede VPC com peering antes de chegar à instância de VM de destino. Google Cloud Google Cloud
A análise segue um dos muitos estados finitos
O número limitado de passos entre estados discretos até que um pacote seja entregue ou rejeitado é modelado como uma máquina de estados finitos. Esta máquina de estados finitos pode estar exatamente num de muitos estados finitos em qualquer momento e pode ter vários estados sucessores.
Por exemplo, quando os testes de conetividade correspondem a várias rotas de acordo com a precedência de rotas, Google Cloud pode escolher uma rota entre várias rotas com base numa função de hash não especificada no plano de dados. Se estiver configurada uma rota baseada em políticas, o teste de conectividade encaminha o pacote para o próximo salto, que é um balanceador de carga interno.
No caso anterior, o rastreio dos testes de conetividade devolve todas as rotas possíveis, mas não consegue determinar o método Google Cloud usado para devolver as rotas. Isto deve-se ao facto de esse método ser interno à Google Cloud e estar sujeito a alterações.
Serviços geridos pela Google
Os serviços geridos pela Google, como o Cloud SQL e o Google Kubernetes Engine (GKE), afetam recursos para os clientes em projetos e redes VPC que a Google detém e gere. Os clientes não têm autorização para aceder a estes recursos.
A análise da configuração dos testes de conectividade ainda pode executar um teste e fornecer um resultado geral de acessibilidade para os serviços geridos pela Google, mas não fornece detalhes para os recursos testados no projeto pertencente à Google.
O diagrama seguinte mostra um modelo de como a análise da configuração simula o tráfego de rastreio de uma instância de VM numa rede VPC do cliente para uma instância do Cloud SQL na rede VPC pertencente à Google. Neste exemplo, as redes estão ligadas através do intercâmbio das redes da VPC.
Semelhante a um teste padrão entre duas VMs, os passos lógicos incluem a verificação das regras de firewall de saída relevantes e a correspondência do trajeto. Quando executa um teste, a análise da configuração dos testes de conetividade fornece detalhes sobre estes passos. No entanto, para o passo lógico final de análise da configuração na rede VPC pertencente à Google, a análise fornece apenas um resultado de acessibilidade geral. Os testes de conetividade não fornecem detalhes dos recursos no projeto pertencente à Google porque não tem autorização para os ver.
Para mais informações, consulte os exemplos de testes em Testar a conetividade com e a partir de serviços geridos pela Google.
Configurações suportadas
A análise da configuração dos testes de conetividade suporta os testes das configurações de rede descritas nas secções seguintes.
Fluxos de tráfego
- Instâncias de VM para e a partir da Internet
- Instância de VM para instância de VM
- De Google Cloud para e das redes no local
- Entre duas redes no local que estão ligadas através do Network Connectivity Center
- Entre dois raios da VPC do Network Connectivity Center
Funcionalidades de rede da VPC
Pode testar a conetividade entre recursos que usam as seguintes funcionalidades (o IPv4 e o IPv6 são suportados sempre que aplicável):
- Redes VPC
- Intercâmbio da rede da VPC
- VPC partilhada
- Acesso privado do Google
- Intervalos de IP de alias
- Endereços IP privados fora do intervalo de endereços RFC 1918
- Uma instância de VM do Compute Engine com várias interfaces de rede
- Encaminhamentos personalizados importados de redes VPC com peering
- Encaminhamento transitivo da VPC
- Regras de firewall de VPC
- Políticas de firewall de rede regionais
- Políticas de firewall hierárquicas e políticas de firewall de rede global
- Etiquetas do Resource Manager para firewalls, incluindo quando anexadas a instâncias do Compute Engine com várias interfaces de rede.
- Rotas baseadas em políticas
- Private Service Connect
- Instâncias com endereços IPv6, incluindo instâncias com várias interfaces de rede
Google Cloud soluções de rede híbridas
As seguintes soluções de rede híbrida são suportadas para IPv4 e IPv6:
- Cloud VPN
- Cloud Interconnect
- Cloud Router, incluindo rotas dinâmicas que usam BGP e rotas estáticas
Network Connectivity Center
Os raios da VPC e os raios híbridos para o Network Connectivity Center são suportados.
NAT na nuvem
O NAT público e o NAT privado são suportados.
Cloud Load Balancing
- Os seguintes Google Cloud tipos de balanceadores de carga são suportados: balanceadores de carga de aplicações externos, balanceadores de carga de rede de encaminhamento externo, balanceadores de carga de rede de proxy externo, balanceadores de carga de aplicações internos, balanceadores de carga de rede de encaminhamento interno e balanceadores de carga de rede de proxy interno.
- Os testes de conetividade aos endereços IP do balanceador de carga são suportados.
- A validação da conetividade das verificações de funcionamento do Cloud Load Balancing aos back-ends é suportada.
- Os balanceadores de carga de TCP/UDP internos podem ser usados como saltos seguintes.
Para ver as funcionalidades do Cloud Load Balancing que não são suportadas, consulte a secção Configurações não suportadas.
Para obter informações sobre como os testes de conetividade analisam os back-ends de um balanceador de carga, consulte o artigo Número de rastreios num teste a um balanceador de carga.
Google Kubernetes Engine (GKE)
- A conetividade com e entre os nós do GKE e o plano de controlo do GKE é suportada.
- A conetividade ao serviço GKE através do Cloud Load Balancing é suportada.
- A conetividade a um pod do GKE num cluster nativo de VPC é suportada. No entanto, algumas funcionalidades de rede do GKE, como as GKE NetworkPolicies, não são suportadas.
Para funcionalidades do GKE não suportadas, consulte a secção Configurações não suportadas.
Pontos finais sem servidor
São suportados os seguintes pontos finais sem servidor:
Normalmente, os endereços IP de origem dos pontos finais sem servidor não são determinísticos. Para cada execução de teste, os testes de conectividade selecionam um endereço IP aleatório do conjunto de endereços disponíveis para o ponto final sem servidor. Para obter informações gerais sobre como os endereços IP são atribuídos a pontos finais sem servidor, consulte o seguinte:
- Para a conetividade externa, consulte Endereços IP.
- Para a conetividade através de um conetor do Acesso a VPC sem servidor, consulte o artigo Envie tráfego sem servidor para uma rede de nuvem privada virtual.
- Para a conetividade através da saída da VPC direta, consulte a secção Alocação de endereços IP. Este tipo de conetividade só está disponível para o Cloud Run.
Em alguns casos, a saída da VPC direta e os conetores do Acesso a VPC sem servidor são configurados para encaminhar o tráfego de pontos finais sem servidor através da conetividade externa em vez da rede da nuvem privada virtual, consoante as definições de saída.
Para funcionalidades sem servidor não suportadas, consulte a secção Configurações não suportadas.
Outros Google Cloud produtos e serviços
Os seguintes Google Cloud produtos ou serviços adicionais são suportados:
- As instâncias do Cloud SQL são suportadas, incluindo a ligação do Private Service Connect, a ligação do intercâmbio da rede da VPC e as réplicas externas.
- As instâncias do Memorystore para Redis são suportadas.
- Os clusters do Memorystore for Redis são suportados.
Configurações não suportadas
A análise da configuração dos testes de conetividade não suporta testes das seguintes configurações de rede:
- As regras de políticas de firewall com objetos de geolocalização, dados de informações sobre ameaças ou objetos FQDN não são suportadas. Se essas firewalls puderem afetar potencialmente um fluxo de tráfego específico, os testes de conetividade devolvem um aviso correspondente.
- Os back-ends Internet NEG que segmentam FQDNs não são suportados. No entanto, os back-ends NEG da Internet que segmentam endereços IP são suportados.
- Os equilibradores de carga da Cloud Service Mesh com as
INTERNAL_SELF_MANAGEDregras de encaminhamento não são suportados. - As políticas do Google Cloud Armor não são consideradas nem usadas quando se rastreia a conetividade a um endereço IP do Application Load Balancer externo.
- Os gateways de VPN de alta disponibilidade ligados a VMs do Compute Engine não são suportados.
- As NetworkPolicies do GKE e as configurações de ocultação de IP não são consideradas nem usadas quando se rastreia a conetividade a endereços IP em clusters e nós do GKE.
- As réplicas de servidores externos do Cloud SQL definidas por nomes DNS não são suportadas. No entanto, as réplicas de servidores externos definidas por endereços IP são suportadas.
- As funções do Cloud Run (2.ª geração) não são suportadas. No entanto, pode testar a conetividade a partir de uma função do Cloud Run (2.ª geração) criando um teste de conetividade para a revisão subjacente do Cloud Run. É criada uma revisão do Cloud Run sempre que uma função do Cloud Run é implementada.
- O ambiente flexível do App Engine não é suportado.
- As tarefas do Cloud Run não são suportadas. Para mais informações, consulte o artigo Serviços e tarefas: duas formas de executar o seu código.
Como os testes de conetividade analisam o plano de dados ativo
A funcionalidade de análise do plano de dados em direto testa a conetividade enviando vários pacotes de rastreio do ponto final de origem para o destino. Os resultados da análise do plano de dados em direto mostram o número de sondagens enviadas, o número de sondagens que atingiram com êxito o destino e um estado de acessibilidade. Este estado é determinado com base no número de sondagens que foram entregues com êxito, conforme descrito na tabela seguinte.
| Estado | Número de sondagens que chegaram ao respetivo destino |
|---|---|
| Acessível | Pelo menos 95% |
| Inacessível | Nenhum |
| Parcialmente acessível | Mais de 0 e menos de 95% |
Além de mostrar quantos pacotes foram entregues com êxito, a análise do plano de dados em direto também mostra informações sobre a latência unidirecional mediana e do percentil 95. A análise do plano de dados em direto não depende da análise da configuração. Em vez disso, a análise do plano de dados em direto fornece uma avaliação independente do estado de conetividade.
Se vir discrepâncias aparentes entre a análise da configuração e os resultados da análise do plano de dados em direto, consulte o artigo Resolva problemas dos testes de conetividade.
Configurações suportadas
A análise do plano de dados em direto suporta as seguintes configurações de rede.
Fluxos de tráfego
- Entre duas instâncias de VM
- Entre uma instância de VM e uma instância do Cloud SQL
- Entre uma instância de VM e um ponto final do plano de controlo do GKE
- Entre uma instância de VM e uma localização na periferia da rede Google. A análise do plano de dados em direto é realizada a partir da instância de VM de origem para todos os possíveis routers de limite da rede Google através dos quais o tráfego pode ser encaminhado com base no endereço IP de destino.
- Protocolos IP: TCP, UDP
Funcionalidades de rede da VPC
Pode validar dinamicamente a conetividade entre recursos que usam as seguintes funcionalidades:
- Intercâmbio da rede da VPC
- VPC partilhada
- Intervalos de IP de alias
- Endereços IP externos
- Endereços IP internos, endereços IP privados fora do intervalo de endereços RFC 1918
- Encaminhamentos personalizados
- Balanceadores de carga como destino. Os back-ends suportados dos balanceadores de carga são grupos de instâncias, grupos de pontos finais da rede (NEG) zonais e back-ends do Private Service Connect
- Regras de firewall de entrada, incluindo regras de políticas de firewall hierárquicas de entrada e regras de firewall da VPC de entrada
- Instâncias com endereços IPv6, incluindo instâncias com várias interfaces de rede
- Pontos finais do Private Service Connect para serviços publicados e APIs Google
Configurações não suportadas
Todas as configurações que não estão explicitamente listadas como suportadas não são suportadas. Além disso, as configurações em que a conetividade é bloqueada por regras de firewall de saída não são suportadas.
Para qualquer teste, se a funcionalidade de análise do plano de dados em direto não for executada,
é apresentado um N/A ou um - no campo Resultado da última transmissão de pacotes.
Ponderações e restrições
Avalie as seguintes considerações quando decidir se deve usar os testes de conetividade.
- A análise de configuração que os testes de conetividade realizam baseia-se inteiramente nas informações de configuração dos Google Cloud recursos e pode não representar a condição ou o estado real do plano de dados para uma rede VPC.
- Embora os testes de conectividade adquiram algumas informações de configuração dinâmica, como o estado do túnel da VPN na nuvem e as rotas dinâmicas que estão no Cloud Router, não acedem nem mantêm o estado de funcionamento da infraestrutura de produção interna da Google e dos componentes do plano de dados.
- O estado
Packet could be deliveredpara um teste de conetividade não garante que o tráfego pode passar pelo plano de dados. O objetivo do teste é validar problemas de configuração que podem causar uma diminuição do tráfego.
Para rotas suportadas, os resultados da análise do plano de dados em direto complementam os resultados da análise de configuração testando se os pacotes transmitidos chegam ao destino.
Os testes de conetividade não têm conhecimento de redes fora de Google Cloud
As redes externas são definidas da seguinte forma:
- Redes no local que residem no seu centro de dados ou noutras instalações onde opera os seus dispositivos de hardware e aplicações de software.
- Outros fornecedores de nuvem onde executa recursos.
- Um anfitrião na Internet que envia tráfego para a sua rede de VPC.
Os testes de conetividade não realizam a monitorização da ligação da firewall
A monitorização de ligações para firewalls de VPC armazena informações sobre ligações novas e estabelecidas, e permite autorizar ou restringir o tráfego subsequente com base nessas informações.
A análise da configuração dos testes de conectividade não suporta o acompanhamento da ligação da firewall porque a tabela de ligações da firewall está localizada no plano de dados de uma instância de VM e é inacessível. No entanto, a análise da configuração pode simular o acompanhamento de ligações permitindo uma ligação de retorno que, normalmente, seria recusada por uma regra de firewall de entrada, desde que os testes de conetividade iniciem a ligação de saída.
A análise do plano de dados em direto não suporta testes de monitorização da ligação da firewall.
Os testes de conetividade não podem testar instâncias de VMs configuradas para modificar o comportamento de encaminhamento
Os testes de conetividade não podem testar instâncias de VMs que foram configuradas para atuarem no plano de dados como routers, firewalls, gateways NAT, VPNs, etc. Este tipo de configuração dificulta a avaliação do ambiente em execução na instância de VM. Além disso, a análise do plano de dados em direto não suporta este tipo de cenário de teste.
Os tempos dos resultados dos testes de conetividade podem variar
A obtenção dos resultados dos testes de conetividade pode demorar entre 30 segundos e 10 minutos. O tempo que um teste demora baseia-se no tamanho da configuração da rede da VPC e no número de Google Cloud recursos que usa.
A tabela seguinte mostra os tempos de resposta que pode esperar para todos os utilizadores que executam um teste com uma configuração de exemplo numa consulta. Esta configuração contém instâncias de VM, um túnel do Cloud VPN e balanceadores de carga Google Cloud .
| Tamanho do projeto | Número de recursos Google Cloud | Latência da resposta |
|---|---|---|
| Projeto pequeno | Menos de 50 | 60 segundos para 95% das consultas de todos os utilizadores |
| Projeto médio | Superior a 50, mas inferior a 5000 | 120 segundos para 95% das consultas de todos os utilizadores |
| Projeto grande | Superior a 5000 | 600 segundos para 95% das consultas de todos os utilizadores |
A análise do plano de dados em direto não se destina à monitorização contínua
A análise do plano de dados em direto faz uma validação única da conetividade de rede para fins de diagnóstico. Para a monitorização contínua da conetividade e da perda de pacotes, use o Performance Dashboard.
Suporte dos VPC Service Controls
Os VPC Service Controls podem oferecer segurança adicional para os testes de conectividade, ajudando a mitigar o risco de exfiltração de dados. Com os VPC Service Controls, pode adicionar projetos a perímetros de serviço que protegem recursos e serviços de pedidos originados fora do perímetro.
Para saber mais acerca dos perímetros de serviço, consulte a página Detalhes e configuração do perímetro de serviço da documentação do VPC Service Controls.
O que se segue?
Identifique e corrija problemas de ICMP (tutorial)