Visão geral do Connectivity Tests

Os Testes de conectividade são uma ferramenta de diagnóstico que permite verificar a conectividade entre os endpoints da rede. Eles analisam a configuração e, em alguns casos, realizam a verificação de tempo de execução 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.

Em alguns cenários de conectividade, os testes de conectividade também realizam a verificação de tempo de execução. 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 executado incluirá um resultado de verificação dinâmica.

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.

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.

Dependendo da rede do Google Cloud e das configurações de recursos, esse tráfego pode passar por um túnel do Cloud VPN, um balanceador de carga do Google Cloud ou uma rede VPC com peering antes de chegar à instância da VM de destino.

A máquina de estado abstrato da rede.
A máquina de estado abstrato da rede

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.

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 do Google e gerenciadas por ele. 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. O Connectivity Tests não fornece 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.

A máquina de estado abstrato da rede para serviços gerenciados pelo Google.
A máquina de estado abstrato da rede para 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

Recursos de rede VPC

É possível testar a conectividade entre recursos que usam os seguintes recursos:

Soluções de rede híbrida do Google Cloud

As seguintes soluções de rede híbrida são suportadas:

Network Connectivity Center

O Network Connectivity Center é compatível.

Cloud NAT

Cloud NAT é suportado.

Cloud Load Balancing

  • A conectividade com os balanceadores de carga do Google Cloud a seguir é aceita: balanceadores de carga HTTP(S) externos, de rede, HTTP(S) internos, TCP/UDP internos, de proxy TCP e de proxy SSL.
  • A conectividade para endereços IP do balanceador de carga é suportada.
  • A conectividade das verificações de integridade do Cloud Load Balancing para back-end é suportada. Os back-ends podem ser grupos de instâncias ou grupos de endpoints de rede (NEGs).

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.
    • Ao testar o endereço IP particular de um plano de controle do GKE, a análise de configuração dos Testes de conectividade determina se o pacote pode ser entregue ao plano de controle. Isso inclui analisar a configuração na rede VPC do Google.
    • Ao testar o endereço IP público de um plano de controle do GKE, a análise de configuração dos Testes de conectividade determina se o pacote pode ser enviado à rede VPC do Google em que o plano de controle é executado. Isso não inclui a análise da configuração na rede VPC do Google.
  • 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.

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:

  • As instâncias do Cloud SQL são suportadas.
    • Ao testar o endereço IP privado de uma instância do Cloud SQL, a análise de configuração determina se o pacote pode ser entregue à instância. Isso inclui analisar a configuração na rede VPC do Google.
    • Ao testar o endereço IP público de uma instância do Cloud SQL, a análise de configuração determina se o pacote pode ser enviado à rede VPC do Google em que a instância é executada. Isso não inclui a análise da configuração na rede VPC do Google.

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:

  • 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 HTTP(S) externo.
  • Política de rede do GKE. O Connectivity Tests não incorpora políticas de rede ao rastrear a conectividade para endereços IP nos clusters GKE.
  • Um balanceador de carga HTTP(S) externo que usa os buckets do Cloud Storage não é suportado.

Como os Testes de conectividade analisam o plano de dados ativo

O recurso de verificação dinâmica testa a conectividade enviando vários pacotes de trace do endpoint de origem para o destino. Os resultados da verificação dinâmica mostram o número de sondagens enviadas, o número de sondagens que chegaram ao destino e o status de acessibilidade. 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 verificação dinâmica não depende da análise da configuração. Na verdade, a verificação dinâmica fornece uma avaliação independente do estado da conectividade.

Se você perceber discrepâncias aparentes entre a análise de configuração e os resultados da verificação dinâmica, consulte Resolver problemas do Connectivity Tests.

Configurações aceitass

A verificação dinâmica é compatível com as configurações de rede a seguir.

Fluxos de tráfego

  • Instância de VM para instância de VM
  • Protocolos de IP: TCP, UDP

Recursos de rede VPC

É possível verificar dinamicamente a conectividade entre os recursos que usam os recursos a seguir:

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 determinado, se o recurso de verificação dinâmica não for executado, um N/A ou - aparecerá no campo Último resultado de transmissão do pacote.

Consideraçõ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 pode não 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 ou 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 delivered para 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 verificação dinâmica complementam os resultados da análise da 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 verificação dinâmica não é compatível com o teste de rastreamento da conexão do 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 verificação dinâmica 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.

Tempos de resposta por consulta
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 verificação dinâmica não se destina ao monitoramento contínuo

A verificação dinâmica executa 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 verificação dinâmica não testa vários traces

A verificação dinâmica não é compatível em casos em que a rota não é determinista.

O que é acessibilidade?

Um recurso é acessível em outro endpoint se as configurações de rede, como firewalls e rotas, permitirem que o tráfego entre de um para o outro. Por exemplo, se a configuração de rede permitir que a VM1 envie pacotes para a VM2, a VM2 será considerada acessível na VM1.

Os Testes de conectividade medem a acessibilidade de uma determinada origem para um determinado destino. O fato de a VM1 acessar a VM2 não significa necessariamente que a VM3 conseguirá acessar a VM2.

Os Testes de conectividade medem a acessibilidade unidirecional. O fato de a VM1 conseguir abrir uma conexão com a VM2 não significa que a VM2 consegue abrir uma conexão com a VM1. As regras de firewall podem permitir tráfego em uma direção, mas não em outra.

Os Testes de conectividade medem a acessibilidade de um protocolo e porta de destino específicos. O fato de a VM1 conseguir acessar a VM2 em tcp:443 não significa que ela consegue acessá-la em tcp:80.

Os Testes de conectividade testam apenas as configurações de rede VPC do Google Cloud que podem afetar a entrega de pacotes da origem ao destino. Eles não verificam se um servidor válido está sendo executado no destino, se as regras de firewall do sistema operacional podem bloquear o tráfego ou se o software de segurança bloqueia um pacote que contém um payload de vírus.

O conceito de Acessibilidade foi originado na teoria dos gráficos. Conceitualmente, todo o gráfico de acessibilidade de uma rede contém todos os endpoints como nós e bordas direcionais que indicam a acessibilidade de nós de origem para os nós de destino.

Análise de acessibilidade é um termo mais genérico que descreve um corpo de análise que pode ser conduzido para determinar a acessibilidade da rede. Um dos casos de uso de uma análise de acessibilidade é um teste de conectividade. Conectividade, neste caso, refere-se ao estado das conexões de rede.

Para cada etapa do caminho de encaminhamento da rede, uma análise de acessibilidade testa e fornece resultados para a configuração de rede subjacente. Por exemplo, os Testes de conectividade analisam as regras de firewall e as rotas do Google Cloud aplicadas a um pacote de teste simulado.

Como o Connectivity Tests funciona

Os testes de conectividade incluem dois componentes principais: uma análise de configuração e a verificação dinâmica. Nesta seção, descrevemos como esses dois tipos de análise funcionam.

Como a análise de configuração funciona

Nesta seção, você verá como o Connectivity Tests e seus componentes funcionam.

Os testes de conectividade fazem uma análise de acessibilidade que avalia os recursos do Google Cloud no seu caminho de teste com um modelo de configuração ideal. Ela é expandida pelo recurso de verificação dinâmica, que envia pacotes para verificar o estado do plano de dados e fornecer informações de valor de referência para configurações compatíveis. Para detalhes sobre como funciona a verificação dinâmica, consulte Como funciona a análise do plano de dados ativo.

Como administrador de rede, você tem controle sobre muitas configurações que podem afetar o resultado da análise, embora algumas exceções se apliquem. Por exemplo, você não tem controle sobre redes VPC que hospedam serviços gerenciados pelo Google, como instâncias do Cloud SQL. Além disso, devido a restrições de permissões, talvez você não tenha controle sobre as regras de política de firewall hierárquicas que afetam sua rede.

Ao executar um teste de conectividade, você insere um conjunto específico de parâmetros e recebe resultados formatados na forma de um trace de rede ou consulta. Um teste de conectividade gera mais de um trace se tiver vários caminhos possíveis na rede. Por exemplo, quando o endpoint de destino é um balanceador de carga do Google Cloud com vários back-ends.

  • Uma correspondência significa que o Connectivity Tests encontrou uma configuração do Google Cloud que permite que o pacote simulado continue no caminho do teste.
  • Nenhuma correspondência significa que o Connectivity Tests não conseguiu encontrar nenhuma correspondência. Portanto, a configuração não existe.
  • Uma correspondência negada significa que o Connectivity Tests encontrou uma configuração do Google Cloud na qual o pacote de testes simulado precisa ser descartado.

Componentes do Connectivity Tests

Um Teste de conectividade é o componente de nível superior que contém todos os outros subcomponentes de teste necessários para a análise da configuração. Os componentes são estes:

  • Endpoints de origem e destino
  • Detalhes de acessibilidade do teste e dos traces, incluindo um resultado geral de acessibilidade determinado pela análise da configuração
  • um ou mais traces que contêm cada um ou mais etapas;
  • um estado para cada etapa.

Cada teste possui um nome exclusivo e cada etapa possui um estado e Info metadados associados a ele. Por exemplo, se uma etapa verificar uma rota, RouteInfo metadados serão incluídos nessa etapa.

O diagrama a seguir mostra um teste de uma instância da VM do Compute Engine para outra. Para ver as descrições dos componentes de teste, consulte as seções a seguir.

Máquina de estado para um trace de VM para VM.
Máquina de estado para um rastreio de VM para VM

Endpoints de origem e destino

A análise de configuração dos Testes de conectividade é compatível com um cabeçalho de pacote de cinco tuplas sem a porta de origem. Isso ocorre porque a porta de origem não é usada para validar recursos nas configurações de rede do Google Cloud. Portanto, você não precisa fornecê-la ao executar testes.

O cabeçalho do pacote contém os seguintes componentes:

  • um protocolo de rede;
  • um endpoint de origem que consiste em um dos itens a seguir:
    • um endereço IP de origem;
    • um nome de instância de VM;
    • Um nome de cluster para um plano de controle do GKE
    • Um nome de instância do Cloud SQL
  • um endpoint de destino que consiste em um dos itens a seguir e um número de porta:
    • um endereço IP de destino;
    • um nome de instância de VM;
    • Um nome de cluster para um plano de controle do GKE
    • Um nome de instância do Cloud SQL

Também é possível especificar um tipo de rede do Google Cloud ou uma que não seja do Google Cloud ou uma combinação de tipo de rede e endereço IP ou nome de instância de VM para identificar exclusivamente um local de rede.

Os seguintes protocolos de destino são suportados para qualquer recurso suportado do Google Cloud:

  • TCP
  • UDP
  • ICMP
  • ESP
  • AH
  • SCTP
  • IPIP

As portas de destino para os protocolos TCP ou UDP são compatíveis. Se você não especificar uma porta, a configuração padrão será a porta 80.

Traces, etapas e estados

A análise de configuração contém um ou mais traces. Cada trace representa um caminho de encaminhamento de pacote simulado exclusivo em um teste.

  • Cada trace contém várias etapas ordenadas.
  • Cada etapa contém um estado relacionado à configuração do Google Cloud que o Connectivity Tests verifica para essa etapa.
  • Os estados são categorizados em estados não finais e finais.
Estados não finais

Estados não finais representam uma verificação de configuração para cada recurso do Google Cloud no caminho de teste, como uma instância da VM, endpoint, regra de firewall, rota ou balanceador de carga do Google Cloud.

Existem quatro estados não finais:

  • inicial;
  • verificação da configuração;
  • encaminhamento;
  • Transição

Para mais informações, consulte Estados de teste.

Estado final

Cada trace deve terminar com um estado final, que é a última etapa do rastreio.

Há quatro estados finais possíveis:

  • Drop
  • Abort
  • Forward
  • Deliver

Cada estado tem um motivo associado a ele. Para mais informações, consulte os detalhes de cada estado final.

Resultado geral de acessibilidade

A análise de configuração também fornece um resultado geral de acessibilidade que pode assumir um dos quatro valores: Reachable, Unreachable, Ambiguous ou Undetermined.

Conhecer o resultado geral de acessibilidade pode ser útil para configurar o monitoramento ou a automação.

Para mais informações, consulte Resultado geral de acessibilidade.

Verificação falsa

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.

Metadados

Cada estado pode ter metadados associados a ele na forma de um campo Info. Por exemplo, InstanceInfo contém detalhes para uma instância da VM, incluindo o nome e o endereço IP.

A análise de configuração fornece metadados para o próprio teste e metadados para cada etapa em um teste.

Como funciona a análise do plano de dados ativo

O mecanismo de sondagem para verificação dinâmica não envolve o SO convidado e é totalmente transparente para o usuário. As sondagens são injetadas em nome do endpoint de origem na rede e são descartadas pouco antes de serem entregues ao endpoint de destino. As sondagens são excluídas do faturamento de rede comum, das métricas de telemetria e dos registros de fluxo.

Compatibilidade com VPC Service Controls (visualização)

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