Medir a acessibilidade

Esta página descreve como os testes de conetividade medem a acessibilidade. Também explica como funcionam a análise da configuração e a análise do plano de dados em direto.

O que é a acessibilidade?

Um recurso é acessível a partir de outro ponto final se as configurações de rede, como firewalls e rotas, permitirem que o tráfego passe de um para o outro. Por exemplo, se a configuração de rede deve permitir que a VM1 envie pacotes para a VM2, diz-se que a VM2 é acessível a partir da VM1.

Tenha em atenção os seguintes aspetos sobre a forma como os testes de conetividade medem a acessibilidade:

  • Os testes de conetividade medem a acessibilidade de uma origem específica a um destino específico. O facto de a VM1 poder alcançar a VM2 não significa necessariamente que a VM3 possa alcançar a VM2.
  • Os testes de conetividade medem a acessibilidade unidirecional. O facto de a VM1 poder abrir uma ligação à VM2 não significa que a VM2 possa abrir uma ligação à VM1. As regras de firewall podem permitir o tráfego numa direção, mas não na outra.
  • Os testes de conetividade medem a acessibilidade de um protocolo específico e uma porta de destino. O facto de a VM1 poder alcançar a VM2 em tcp:443 não significa que a possa alcançar em tcp:80.
  • Os testes de conetividade apenas testam as configurações de rede da VPC que podem afetar a entrega de pacotes da origem para o destino. Google Cloud Não verifica se um servidor válido está em execução no destino, se as regras da firewall do sistema operativo podem bloquear o tráfego ou se o software de segurança bloqueia um pacote que transporta uma carga útil de vírus.

O conceito de Acessibilidade tem origem na teoria dos grafos. Em termos conceptuais, o gráfico de acessibilidade completo de uma rede contém todos os pontos finais como nós e arestas direcionais que indicam a acessibilidade dos nós de origem aos nós de destino.

A análise de acessibilidade é um termo mais genérico que descreve um conjunto de análises que podem ser realizadas para determinar a acessibilidade da rede. Um dos exemplos de utilização de uma análise de acessibilidade é um teste de conetividade. Neste caso, a conetividade refere-se ao estado das ligações de rede.

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

Como funcionam os testes de conetividade

Os testes de conetividade incluem dois componentes principais: uma análise de configuração e uma análise do plano de dados em direto. Esta secção descreve como funcionam estes dois tipos de análises.

Como funciona a análise de configuração

Esta secção descreve o funcionamento dos testes de conetividade e dos respetivos componentes.

Os testes de conetividade executam uma análise de acessibilidade que avalia os recursos no seu caminho de teste em comparação com um modelo de configuração ideal. Google Cloud É melhorado pela funcionalidade de análise do plano de dados em direto, que envia pacotes para validar o estado do plano de dados e fornece informações de base para configurações suportadas. Para ver detalhes sobre como funciona a análise do plano de dados em direto, consulte o artigo Como funciona a análise do plano de dados em direto.

Como administrador de rede, tem controlo sobre muitas configurações que podem afetar o resultado da análise, embora se apliquem algumas exceções. Por exemplo, não tem controlo sobre as redes VPC que alojam serviços geridos pela Google, como instâncias do Cloud SQL. Além disso, devido a restrições de autorizações, pode não ter controlo sobre as regras de políticas de firewall hierárquicas que afetam a sua rede.

Quando executa um teste de conetividade, introduz um conjunto específico de parâmetros e recebe resultados formatados sob a forma de um rastreio de rede ou uma consulta. Um teste de conetividade gera mais do que um rastreio se um teste tiver vários caminhos possíveis na rede (por exemplo, quando o ponto final de destino é um Google Cloud equilibrador de carga com vários back-ends).

  • Uma correspondência significa que os testes de conetividade encontram uma configuração que permite que o pacote simulado continue no caminho de teste. Google Cloud
  • Sem correspondência significa que os testes de conetividade não conseguem encontrar uma correspondência. Assim, a configuração não existe.
  • Uma correspondência recusada significa que os testes de conetividade encontram uma configuração em que o pacote de teste simulado tem de ser ignorado.Google Cloud

Componentes dos testes de conetividade

Um teste de conetividade é o componente de nível superior que contém todos os outros subcomponentes de teste necessários para a análise da configuração. Estes componentes incluem o seguinte:

  • Pontos finais de origem e destino
  • Detalhes da acessibilidade para o teste e os respetivos rastreios, incluindo um resultado de acessibilidade geral determinado pela análise da configuração
  • Um ou mais rastreios que contêm cada um um ou mais passos
  • Um estado para cada passo

Cada teste tem um nome exclusivo e cada passo tem um estado e Infometadados associados. Por exemplo, se um passo verificar um trajeto, os metadados RouteInfo são incluídos nesse passo.

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

Máquina de estados para um rastreio de VM para VM.
Máquina de estados para um rastreio de VM para VM

Pontos finais de origem e destino

A análise da configuração dos testes de conetividade suporta um cabeçalho de pacote de 5 tuplos sem a porta de origem. Isto deve-se ao facto de a porta de origem não ser usada para validar recursos nas configurações de rede Google Cloud . Assim, não precisa de o fornecer quando executar testes.

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

  • Um protocolo de rede
  • Um ponto final de origem, que consiste num dos seguintes:
    • Um nome de instância de VM
    • Um endereço IP de origem
    • Um serviço do App Engine de origem
    • Um ambiente de função do Cloud Run (1.ª geração)
    • Um serviço do Cloud Run
    • Um nome de instância do Cloud SQL
    • Um nome de cluster para um plano de controlo do GKE
  • Um ponto final de destino, composto por um dos seguintes 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 controlo do GKE
    • Um ponto final do Private Service Connect

Também pode especificar um tipo de rede Google Cloud ou nãoGoogle Cloud , ou uma combinação de um tipo de rede e um endereço IP ou um nome de instância de VM para identificar exclusivamente uma localização de rede.

Os seguintes protocolos de rede são suportados para VMs, endereços IP e serviços geridos pela Google:

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

Os seguintes protocolos de rede são suportados pelos conetores do Acesso a VPC sem servidor:

  • TCP
  • UDP

As portas de destino para os protocolos TCP ou UDP são suportadas. Se não especificar uma porta, a predefinição é a porta 80.

Rastreios, passos e estados

A análise da configuração contém um ou mais rastreios. Cada rastreio representa um caminho de encaminhamento de pacotes simulado exclusivo num teste.

  • Cada rastreio contém vários passos ordenados.
  • Cada passo contém um estado relacionado com a Google Cloud configuração que os testes de conetividade verificam para esse passo.
  • Os estados são categorizados em estados não finais e finais.
Estados não finais

Os estados não finais representam uma verificação da configuração para cada Google Cloud recurso no caminho de teste, como uma instância de VM, um ponto final, uma regra de firewall, uma rota ou um Google Cloud equilibrador de carga.

Existem quatro estados não finais:

  • Rubricar
  • Verificação da configuração
  • Encaminhamento
  • Transição

Para mais informações, consulte o artigo Estados da análise de configuração.

Estado final

Cada rastreio tem de terminar com um estado final, que é o último passo no rastreio.

Existem quatro estados finais possíveis:

  • Drop
  • Abort
  • Forward
  • Deliver

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

Resultado geral da acessibilidade

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

Conhecer o resultado geral da acessibilidade pode ser útil para configurar a monitorização ou a automatização.

Para mais informações, consulte o artigo Resultado geral da acessibilidade.

Verificação de spoofing

Os testes de conetividade executam uma verificação de spoofing quando um pacote simulado para ou a partir de uma instância de VM usa um endereço IP que não é propriedade dessa instância. Os endereços IP pertencentes a uma VM incluem todos os endereços IP internos da VM e os endereços IP secundários.

Se o endereço for um endereço que parece ter origem no tráfego externo, também denominado endereço estrangeiro, o endereço IP falha na verificação de roubo de identidade.

Metadados

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

A análise da configuração fornece metadados para o próprio teste e metadados para cada passo num teste.

Como funciona a análise do plano de dados em direto

O mecanismo de sondagem para a análise do plano de dados em direto não envolve o SO convidado e é totalmente transparente para o utilizador. As sondas são injetadas em nome do ponto final de origem na rede e são ignoradas imediatamente antes de serem entregues ao ponto final de destino. As sondas são excluídas da faturação normal da rede, das métricas de telemetria e dos registos de fluxo.

O que se segue?