Medir a acessibilidade

Nesta página, descrevemos como os Testes de conectividade medem a acessibilidade. Ele também explica como funcionam as análises de configuração e do plano de dados em tempo real.

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.

Observe os seguintes aspectos sobre como os Testes de conectividade medem a acessibilidade:

  • Os Testes de conectividade mede a acessibilidade de uma origem específica 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 mede a acessibilidade de um determinado protocolo e porta de destino. O fato de que a VM1 pode alcançar a VM2 em tcp:443 não significa que ela pode alcançá-la em tcp:80.
  • Os Testes de conectividade testa apenas as configurações de rede VPC do Google Cloud que podem afetar a entrega de pacotes da origem para o 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

O Connectivity Tests inclui dois componentes principais: uma análise de configuração e uma análise do plano de dados em tempo real. 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 executa uma análise de acessibilidade que avalia os recursos do Google Cloud no seu caminho de teste em relação a um modelo de configuração ideal. Ele é aumentado pelo recurso de análise do plano de dados ativo, que envia pacotes para verificar o estado do plano de dados e fornecer informações 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 as 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 seguintes itens:
    • um nome de instância de VM;
    • um endereço IP de origem;
    • Um serviço de origem do App Engine
    • Um ambiente de função do Cloud (1a geração)
    • Um serviço do Cloud Run
    • Um nome de instância do Cloud SQL
    • Um nome de cluster para um plano de controle do GKE
  • Um endpoint de destino que consiste em um dos itens a seguir e um número de porta:
    • um nome de instância de VM;
    • um endereço IP de destino;
    • Um nome de instância do Cloud SQL
    • Um nome de cluster para um plano de controle do GKE
    • Um endpoint do Private Service Connect

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 rede são compatíveis com VMs, endereços IP e serviços gerenciados pelo Google:

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

Os seguintes protocolos de rede são compatíveis com conectores de acesso VPC sem servidor:

  • TCP
  • UDP

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 state 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 análise da configuração.

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 análise em tempo real do plano de dados não envolve o SO convidado e é totalmente transparente ao 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.

A seguir