Os Testes de conectividade são uma ferramenta de diagnóstico que permite verificar a conectividade entre os endpoints da rede. Ele analisa a configuração e, em alguns casos, realiza uma análise de plano de dados em tempo real entre os endpoints. Um endpoint é 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 conectividade simulam o caminho esperado do encaminhamento de um pacote por meio da rede de nuvem privada virtual (VPC), de túneis do Cloud VPN ou de anexos da VLAN. O Connectivity Tests também simula o caminho de encaminhamento de entrada esperado para os recursos na sua rede VPC.
Para alguns cenários de conectividade, o Connectivity Tests também realiza análise de plano de dados em tempo real. Esse recurso envia pacotes pelo plano de dados para validar a conectividade e fornece diagnósticos de referência de latência e perda de pacotes. Se a rota for compatível com o recurso, cada teste que você executar incluirá um resultado de análise do plano de dados em tempo real.
Para saber como criar e executar testes para vários cenários, consulte Criar e executar testes de conectividade.
A API para o Connectivity Tests é a API Network Management. Para saber mais informações, consulte a documentação da API.
Por que usar o Connectivity Tests?
Os testes de conectividade podem ajudar a resolver os seguintes problemas de conectividade de rede:
- Configurações inconsistentes não intencionais
- Configurações obsoletas causadas por migrações ou alterações de configuração de rede
- erros de configuração para uma variedade de serviços e funções de rede.
Ao testar os serviços gerenciados pelo Google, os Testes de conectividade também ajudam a determinar se há algum problema na sua rede VPC ou na rede VPC do Google usadas para os recursos de serviço.
Como o Connectivity Tests analisa as configurações
Ao analisar as configurações de rede, os testes de conectividade usam uma máquina de estado abstrato para modelar como uma rede VPC precisa processar pacotes. O Google Cloud processa um pacote em várias etapas lógicas.
A análise pode seguir vários caminhos possíveis
Devido à variedade de serviços e recursos de rede VPC compatíveis com a análise de configuração, os pacotes de teste que atravessam várias configurações de rede VPC podem ter muitos caminhos possíveis.
O diagrama a seguir mostra um modelo de como a análise de configuração simula o tráfego de traces entre duas instâncias de máquina virtual (VM) do Compute Engine: uma à esquerda e outra à direita.
A análise depende da sua infraestrutura de rede
Dependendo da rede do Google Cloud e das configurações de recursos, esse tráfego pode passar por um túnel do Cloud VPN, uma rede VPC, um balanceador de carga do Google Cloud ou uma rede VPC com peering antes de chegar à instância da VM de destino.
A análise segue um dos muitos estados finitos
O número limitado de etapas entre estados distintos até que um pacote tenha sido entregue ou descartado é modelado como uma máquina de estado finito. Essa máquina de estado finito pode estar exatamente em um dos muitos estados finitos por vez e pode ter vários estados sucessores.
Por exemplo, quando o Connectivity Tests corresponde a várias rotas de acordo com a precedência da rota, o Google Cloud pode escolher uma rota entre várias rotas com base em uma função de hash não especificada no plano de dados. Se uma rota com base em políticas estiver configurada, o Teste de conectividade encaminhará o pacote para o próximo salto, que é um balanceador de carga interno.
No caso anterior, o trace do Connectivity Tests retorna todas as rotas possíveis, mas não determina o método que o Google Cloud usou para retornar as rotas. Isso ocorre porque esse método é interno ao Google Cloud e está sujeito a alterações.
Serviços gerenciados pelo Google
Os serviços gerenciados pelo Google, como o Cloud SQL e o Google Kubernetes Engine (GKE), alocam recursos para clientes em projetos e redes VPC de propriedade e gerenciamento do Google. Os clientes não têm permissão para acessar esses recursos.
Os Testes de conectividade ainda podem executar um teste e fornecer um resultado geral de acessibilidade para os serviços gerenciados pelo Google, mas não fornecem detalhes sobre os recursos testados no projeto do Google.
O diagrama a seguir mostra um modelo de como a análise de configuração simula o tráfego de rastreamento de uma instância de VM em uma rede VPC de cliente para uma instância do Cloud SQL na rede VPC de propriedade do Google. Neste exemplo, as redes são conectadas por meio do peering de rede VPC.
Semelhante a um teste padrão entre duas VMs, as etapas lógicas incluem a verificação das regras de firewall de saída e a rota correspondente. Quando você executa um teste, a análise da configuração dos testes de conectividade fornece detalhes sobre essas etapas. No entanto, para a última etapa lógica de analisar a configuração na rede VPC do Google, as análises de conectividade fornecem apenas um resultado geral de acessibilidade. Os Testes de conectividade não fornecem detalhes sobre os recursos no projeto do Google porque você não tem permissão para visualizá-los.
Para mais informações, consulte os exemplos de teste em Testar a conectividade de e para os serviços gerenciados pelo Google.
Configurações aceitas
A análise de configuração dos testes de conectividade é compatível com o teste das configurações de rede descritas nas seções a seguir.
Fluxos de tráfego
- Instâncias de VM para e da Internet
- Instância de VM para instância de VM
- Do Google Cloud para e de redes locais
- Entre duas redes locais conectadas pelo Network Connectivity Center
- Entre dois spokes VPC do Network Connectivity Center
Recursos de rede VPC
É possível testar a conectividade entre recursos que usam os seguintes atributos (IPv4 e IPv6 são aceitos sempre que aplicável):
- Redes VPC
- Peering de rede VPC
- VPC compartilhada
- Acesso privado do Google
- Intervalos de IP de alias
- Endereços IP particulares fora do intervalo de endereços do RFC 1918
- Uma instância da VM do Compute Engine com várias interfaces de rede
- Rotas personalizadas importadas de redes VPC com peering
- Roteamento transitivo VPC
- Regras de firewall da VPC
- Políticas de firewall da rede regional
- Políticas hierárquicas de firewall e Políticas de firewall da rede global
- Tags do Resource Manager para firewalls, se anexadas à instância do Compute Engine com uma única interface de rede.
- Rotas com base em políticas
- Private Service Connect
- Instâncias com endereços IPv6, incluindo instâncias com várias interfaces de rede
Soluções de rede híbrida do Google Cloud
As seguintes soluções de rede híbrida têm suporte 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 spokes VPC e híbridos do Network Connectivity Center são compatíveis.
Cloud NAT
NAT pública e NAT privada são compatíveis.
Cloud Load Balancing
- Os seguintes tipos de balanceadores de carga do Google Cloud são compatíveis: balanceadores de carga de aplicativo externos, balanceadores de carga de rede de passagem externos, balanceadores de carga de rede de proxy externos, balanceadores de carga de aplicativo internos, balanceadores de carga de rede de passagem internos e balanceadores de carga de rede de proxy internos.
- É possível testar a conectividade com os endereços IP do balanceador de carga.
- A verificação da conectividade das verificações de integridade do Cloud Load Balancing para back-ends é aceita.
- Os balanceadores de carga TCP/UDP internos podem ser usados como próximos saltos.
Para recursos do Cloud Load Balancing não suportados, consulte a seção Configurações não suportadas.
Google Kubernetes Engine (GKE)
- A conectividade com e entre os nós do GKE e o plano de controle do GKE é compatível.
- A conectividade com o serviço do GKE por meio do Cloud Load Balancing é suportada.
- A conectividade com um pod do GKE em um cluster nativo de VPC é suportada. No entanto, alguns recursos de rede do GKE, como GKE NetworkPolicies, não são compatíveis.
Para recursos do GKE que não são suportados, consulte a seção Configurações não suportadas.
Outros produtos e serviços do Google Cloud
Os seguintes produtos ou serviços adicionais do Google Cloud são suportados:
- Há suporte para as instâncias do Cloud SQL, incluindo a conexão do Private Service Connect, a conexão de peering da rede VPC e as réplicas externas.
- Instâncias do Memorystore para Redis são compatíveis.
- O Memorystore para clusters do Redis é compatível.
- Compatível com o Cloud Run functions (1ª geração).
- As revisões do Cloud Run são compatíveis.
- O ambiente padrão do App Engine é compatível.
Configurações não suportadas
A análise de configuração dos Testes de conectividade não é compatível com o teste das seguintes configurações de rede:
- Não é possível usar regras de política de firewall com objetos de geolocalização, dados de inteligência contra ameaças ou objetos FQDN. Se esses firewalls puderem afetar um fluxo de tráfego específico, os Testes de conectividade vai retornar um aviso correspondente.
- As tags do Resource Manager para firewalls não são compatíveis se anexadas a instâncias do Compute Engine com várias interfaces de rede.
- Os back-ends de NEG da Internet que segmentam FQDNs não são compatíveis. No entanto, back-ends de NEG da Internet que segmentam endereços IP são compatíveis.
- Não é possível usar balanceadores de carga do Cloud Service Mesh (com as
regras de encaminhamento
INTERNAL_SELF_MANAGED). - As políticas do Google Cloud Armor não são consideradas ou usadas ao rastrear a conectividade com um endereço IP do balanceador de carga de aplicativo externo.
- O mapeamento de portas do Private Service Connect não é compatível.
- Gateways de VPN de alta disponibilidade conectados a VMs do Compute Engine não são compatíveis.
- As configurações de políticas de rede do GKE e de mascaramento de IP não são consideradas ou usadas ao rastrear a conectividade com endereços IP nos clusters e nós do GKE.
- Não é possível usar réplicas de servidor externo do Cloud SQL definidas por nomes DNS. No entanto, as réplicas de servidores externos definidas por endereços IP são compatíveis.
- Não há suporte para funções do Cloud Run (2ª geração). No entanto, é possível testar a conectividade de uma função do Cloud Run (2ª geração) criando um teste de conectividade para a revisão subjacente do Cloud Run. Uma revisão do Cloud Run é criada sempre que uma função do Cloud Run é implantada.
- O ambiente flexível do App Engine não é compatível.
- Os jobs do Cloud Run não são compatíveis. Para mais informações, consulte Serviços e jobs: duas maneiras de executar seu código.
- Não há suporte para a saída de VPC direta do Cloud Run.
Como os Testes de conectividade analisam o plano de dados ativo
O recurso de análise do plano de dados em tempo real testa a conectividade enviando vários pacotes de trace do endpoint de origem para o destino. Os resultados da análise do plano de dados ativos mostram o número de sondagens enviadas, o número de sondagens que chegaram ao destino e um status de alcance. Esse status é determinado com base em quantas sondagens foram entregues com êxito, conforme descrito na tabela a seguir.
| Status | Número de sondagens que chegaram ao 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 sucesso, a verificação dinâmica também mostra informações de latência unidirecional e mediana do 95º percentil.
A análise do plano de dados em tempo real não depende da análise de configuração. Em vez disso, a análise do plano de dados em tempo real fornece uma avaliação independente do estado de conectividade.
Se você identificar discrepâncias aparentes entre a análise de configuração e os resultados da análise do plano de dados ativos, consulte Resolver problemas de teste de conectividade.
Configurações aceitas
A análise do plano de dados em tempo real é compatível com as configurações de rede a seguir.
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 endpoint do plano de controle do GKE
- Entre uma instância de VM e um local de borda da rede do Google
- Protocolos de IP: TCP, UDP
Recursos de rede VPC
É possível verificar dinamicamente a conectividade entre os recursos que usam os recursos a seguir:
- Peering de rede VPC
- VPC compartilhada
- Intervalos de IP de alias
- Endereços IP externos
- Endereços IP internos, particulares fora do intervalo do RFC 1918
- Rotas personalizadas
- Balanceadores de carga como destino. Os back-ends compatíveis com os balanceadores de carga são grupos de instâncias, grupos de endpoints de rede (NEGs) zonais e serviços particulares Conectar back-ends
- Regras de firewall de entrada, incluindo regras de política de firewall hierárquicas de entrada e regras de firewall VPC de entrada
- Instâncias com endereços IPv6, incluindo instâncias com várias interfaces de rede
- Endpoints do Private Service Connect para serviços publicados e APIs do Google
Configurações não suportadas
As configurações não listadas explicitamente como compatíveis não são aceitas. Além disso, as configurações em que a conectividade é bloqueada por regras de firewall de saída não são compatíveis.
Para qualquer teste, se o recurso de análise do plano de dados em tempo real não for executado,
um N/A ou - aparecerá no campo Resultado da transmissão do último pacote.
Considerações e restrições
Avalie as seguintes considerações ao decidir se deve usar o Connectivity Tests.
- A análise de configuração que os Testes de conectividade realizam é inteiramente com base nas informações de configuração dos recursos do Google Cloud e não pode representar a condição ou o status real do plano de dados de uma rede VPC.
- Embora o Connectivity Tests adquira algumas informações dinâmicas de configuração, como o estado do túnel da Cloud VPN e as rotas dinâmicas no Cloud Router, ele não acessa nem mantém o estado de integridade da infraestrutura de produção interna do Google e dos componentes do plano de dados.
- Um status de
Packet could be deliveredpara um teste de conectividade não garante que o tráfego possa passar pelo plano de dados. O objetivo do teste é validar problemas de configuração que podem causar queda de tráfego.
Para rotas compatíveis, os resultados da análise do plano de dados em tempo real complementam os resultados da análise de configuração testando se os pacotes transmitidos chegam ao destino.
O Connectivity Tests não tem conhecimento de redes fora do Google Cloud
Redes externas são definidas da seguinte maneira:
- redes locais que residem em seu data center ou em outras instalações em que você opera seus dispositivos de hardware e aplicativos de software;
- outros provedores de nuvem em que você executa recursos;
- um host na Internet que envia tráfego para sua rede VPC.
O Connectivity Tests não executa rastreamento de conexão de firewall
O rastreamento de conexão para firewalls da VPC armazena informações sobre conexões novas e estabelecidas e permite permitir ou restringir o tráfego subsequente com base nessas informações.
A análise de configuração dos Testes de conectividade não oferece suporte de rastreamento de conexões de firewall porque a tabela de conexões de firewall está localizada no plano de dados de uma instância de VM e é inacessível. No entanto, a análise de configuração pode simular o rastreamento de conexões, permitindo uma conexão de retorno que normalmente seria negada por uma regra de firewall de entrada, desde que os Testes de conectividade iniciem a conexão de saída.
A análise de plano de dados em tempo real não suporta o teste de rastreamento de conexão de firewall.
O Connectivity Tests não testa instâncias de VM configuradas para modificar o comportamento de encaminhamento
O Connectivity Tests não testa instâncias de VM configuradas para atuar no plano de dados como roteadores, firewalls, gateways NAT, VPNs etc. Esse tipo de configuração dificulta a avaliação do ambiente em execução na instância da VM. Além disso, a análise do plano de dados em tempo real não é compatível com esse cenário de teste.
Os tempos de resultado do Connectivity Tests podem variar
Os resultados do Connectivity Tests podem levar de 30 segundos a 10 minutos. O tempo que um teste leva é baseado no tamanho da configuração da rede VPC e no número de recursos do Google Cloud que você usa.
A tabela a seguir mostra os tempos de resposta que você pode esperar para todos os usuários executando um teste em uma configuração de amostra em uma consulta. Essa configuração contém instâncias de VM, um túnel de VPN na nuvem e balanceadores de carga do Google Cloud.
| Tamanho do projeto | Número de recursos do Google Cloud | Latência de resposta |
|---|---|---|
| Projeto pequeno | Menos de 50 | 60 segundos para 95% das consultas de todos os usuários |
| Projeto médio | Maior que 50, mas menor que 5.000 | 120 segundos para 95% das consultas de todos os usuários |
| Projeto grande | Maior que 5.000 | 600 segundos para 95% das consultas de todos os usuários |
A análise do plano de dados em tempo real não se destina ao monitoramento contínuo
A análise do plano de dados em tempo real realiza uma verificação única da conectividade de rede para fins de diagnóstico. Para monitorar continuamente a conectividade e a perda de pacotes, use o Painel de desempenho.
A análise do plano de dados em tempo real não testa vários traces
A análise do plano de dados em tempo real não é compatível quando a rota não é determinista.
Suporte do VPC Service Controls
O VPC Service Controls pode fornecer segurança adicional para testes de conectividade a fim de ajudar a reduzir o risco de exfiltração de dados. Ao usá-lo, é possível adicionar projetos a perímetros de serviço. Isso protege recursos e serviços contra solicitações que vêm de fora desses perímetros.
Para saber mais sobre perímetros de serviço, consulte a página Detalhes e configuração do perímetro de serviço na documentação do VPC Service Controls.
A seguir
Como usar o Connectivity Tests para diferentes casos de uso de conectividade
Identificar e corrigir problemas de ICMP (tutorial)