Casos de uso comuns para o Connectivity Tests

Os Testes de conectividade avaliam se o tráfego pode viajar entre os endpoints na sua rede. Eles avaliam a acessibilidade ao analisar a configuração de rede e, em alguns casos de uso, enviando pacotes de sondagem.

Veja nesta página casos de uso comuns dos Testes de conectividade que se enquadram em seis categorias:

  • como testar em redes de Nuvem Privada Virtual (VPC), incluindo redes que usam peering de VPC compartilhada e de rede VPC;
  • Como testar serviços gerenciados pelo Google (visualização)
  • como testar de uma rede VPC para uma rede não VPC, como um data center no local;
  • Como testar de uma rede que não seja do Google Cloud para uma rede VPC
  • Como testar de uma rede que não é do Google Cloud para outra rede que não é do Google Cloud
  • Como testar os balanceadores de carga do Google Cloud

A seção Como detectar configurações inválidas ou inconsistentes descreve como lidar com esses cenários.

No caso de uso de teste de uma instância de máquina virtual (VM) para outra, você verá um cenário completo de teste, incluindo os resultados de teste fornecidos no Console do Google Cloud.

Para instruções sobre como executar testes, consulte Como executar Connectivity Tests.

Legenda para diagramas de trace

Os diagramas de trace nesta página usam os símbolos descritos na legenda a seguir.

Símbolo Nome Significado
Legenda para o diagrama de trace de pacote: diamante cinza.
Diamante cinza
Checkpoint Um ponto de decisão em que o Connectivity Tests verifica uma configuração e decide se um pacote de trace precisa ser encaminhado, entregue ou descartado.
Legenda para o diagrama de trace de pacote: retângulo azul.
Retângulo azul
Salto Uma etapa no caminho de encaminhamento para um pacote de trace, representando um recurso do Google Cloud que encaminha um pacote para o próximo salto em uma rede VPC. Por exemplo, para um proxy do Cloud Load Balancing ou para um túnel de VPN em nuvem.
Legenda para o diagrama de trace de pacote: hexágono laranja.
Hexágono laranja
Endpoint A origem ou destino de um pacote de trace.

Como testar em redes VPC

Um caso de uso comum para os Testes de conectividade é testar duas instâncias de máquina virtual (VM) do Compute Engine na mesma rede VPC ou em redes em peering. Para esse tipo de teste, os Testes de conectividade avaliam a acessibilidade usando a análise de configuração e a verificação dinâmica.

Para analisar a configuração, os Testes de conectividade identificam e avaliam um caminho de trace.

O diagrama a seguir mostra o caminho de trace típico entre duas instâncias de VM. O objeto Match routes pode representar rotas que direcionam o tráfego em uma única rede VPC ou entre duas redes VPC com peering.

VM de origem para o trace da VM de destino.
VM de origem para o trace da VM de destino

As etapas a seguir descrevem os checkpoints que correspondem a cada ponto no diagrama de trace. Em cada checkpoint, a verificação pode falhar. Os resultados da consulta mostram o motivo de cada falha. Para uma lista completa de estados e mensagens de teste, consulte Referência de estados de análise de configuração.

  1. Os Testes de conectividade verificam se a VM de origem pode enviar pacotes de saída com o endereço IP de origem especificado ou usar o endereço IP interno principal por padrão. Caso contrário, essa VM precisa ter o encaminhamento de IP ativado.
  2. 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.

  3. Para determinar se os pacotes de rastreamento podem ser enviados da origem, os testes de conectividade verificam as regras de firewall de saída apropriadas. Como parte desse processo, os testes de conectividade começam avaliando todas as regras de política de firewall hierárquicas que existem. Para saber como as regras de política de firewall hierárquicas e as regras de firewall da VPC afetam a conectividade, consulte Exemplos de política de firewall hierárquico.
  4. O Connectivity Tests localiza (corresponde) uma rota para o endereço IP de destino, de acordo com a ordem de roteamento. Se nenhuma outra rota estiver disponível para a instância da VM de destino, o Connectivity Tests usará a rota estática padrão com o próximo salto como o gateway da Internet. Todas as redes VPC usam essa rota padrão, a menos que você a tenha removido.
  5. O Connectivity Tests verifica se as regras de firewall de entrada de rede permitem que o pacote chegue à VM de destino. Novamente, os testes de conectividade começam avaliando todas as regras de política de firewall hierárquicas que existem.
  6. Se necessário, os testes de conectividade executam uma verificação de spoofing no pacote que chega à segunda VM.
  7. O Connectivity Tests verifica se a VM de destino pode receber um pacote com o endereço IP de destino especificado. Se esse for um endereço IP estrangeiro, a VM de destino precisará ter o encaminhamento de IP ativado. Um endereço IP externo é um endereço que não pertence à VM.

Console

A captura de tela a seguir do Console do Google Cloud mostra os resultados de um teste de VM para VM.

A análise da configuração mostra um resultado Pacote pode ser entregue (na resposta da API, esse rótulo corresponde a um estado final de Deliver).

Este resultado mostra que a análise da configuração validou a conectividade de rede para cada recurso do Google Cloud no caminho da VM de origem até a VM de destino. Nesse caso, a rota incluía duas regras de firewall VPC: uma regra de firewall VPC implícita (chamada default) e uma criada para esta rede VPC.

Além disso, os Testes de conectividade verificaram dinamicamente se a VM de destino está acessível usando a sondagem ativa. O campo Último resultado de transmissão do pacote mostra os detalhes desse resultado.

Captura de tela do Console do Cloud para trace de VM para VM.
Captura de tela do Console do Cloud para trace de VM para VM

É possível expandir cada um dos cards no caminho de trace para visualizar mais detalhes.

O exemplo a seguir mostra um card expandido para uma regra de firewall de entrada. Este card inclui informações sobre a rede VPC, a ação configurada para a regra de firewall (permitir) e a prioridade da regra.

Card de regras do firewall de entrada expandido.
Card de regras do firewall de entrada expandido

Quando um trace contém uma rota de rede VPC com o próximo salto como uma rede VPC com peering, o início do trace não é uma instância de VM, mas uma rede VPC. Esse tipo de trace valida regras de firewall e rotas no nível da rede porque o endereço IP que você testa vem de um intervalo de redes em vez de uma instância de VM.

Redes com peering podem existir no mesmo projeto ou em diferentes. O exemplo de trace a seguir mostra redes com peering em diferentes projetos.

Trace de VM para VM por meio de uma rede VPC com peering acessível em um projeto diferente.
Trace de VM para VM por meio de uma rede VPC com peering acessível em um projeto diferente

Falhas de teste para redes VPC

A tabela a seguir lista falhas comuns para testes nas redes VPC.

Tipo de falha Descrição Resultados do trace
Bloqueado por uma regra de firewall O tráfego que sai de um endpoint de origem ou de destino é bloqueado por uma regra hierárquica de política de firewall ou por uma regra de firewall VPC.
  • Se a conectividade for bloqueada por uma regra de política de firewall hierárquica, o trace incluirá o nome da política. Esteja ciente de que a pessoa que está executando o teste pode não ter permissão para ver os detalhes da política. Para mais detalhes sobre essa situação, consulte Solução de problemas.
  • Se a conectividade for bloqueada por uma regra de firewall VPC, o trace listará o nome da regra de firewall de entrada ou saída relevante.
Nenhuma rota correspondente Não foi possível encontrar uma rota para o endpoint de destino.
  • Se as instâncias de VM de origem e de destino estiverem em redes VPC diferentes e essas redes não estiverem em peering, a análise determinará que o Pacote pode ser descartado.
  • Se as VMs estiverem na mesma rede, mas uma rota correspondente não for encontrada, o tráfego será enviado na rota estática padrão, com um próximo salto para o gateway da Internet. Nesse caso, o tráfego nunca chega à VM de destino, e a análise determinará que o Pacote pode ser descartado.
  • Se não houver rota para um gateway de Internet, a análise determinará que o Pacote pode ser descartado.
Instância não em execução A instância da VM de destino existe, mas não está em um estado de execução. A análise determina que o Pacote pode ser descartado.
Próximo salto inválido O próximo salto configurado para uma instância de VM não existe mais e a rota para essa instância é inválida. A análise determina que o Pacote pode ser descartado.

Console

A captura de tela a seguir ilustra um trace que falhou porque a conectividade foi bloqueada por uma regra de política de firewall hierárquica de entrada.

Captura de tela do Console do Cloud para um trace bloqueado por uma regra de política de firewall hierárquica.
Captura de tela do Console do Cloud de um trace bloqueado por uma regra de política de firewall hierárquica

Falhas de teste para redes VPC compartilhadas

Nas redes VPC compartilhadas, não ter permissões para o projeto host ou o projeto de serviço pode causar as falhas de teste listadas na tabela a seguir.

Tipo de falha Comportamento Resultados do trace
Permissões apenas para o projeto host Não é possível executar o trace porque você não tem permissões para o projeto de serviço em que o endereço IP de destino está localizado. A análise de configuração mostra um resultado de Análise de configuração cancelada (na resposta da API, esse rótulo corresponde a um estado final de Abort).
Permissões apenas para o projeto de serviço

Não é possível executar o trace ou selecionar a rede do projeto host no Console do Cloud porque você não tem permissão.

Como o projeto host tem configurações de rede, um trace em relação aos recursos no projeto de serviço não pode prosseguir sem acesso a regras de firewall de VPC, rotas de rede ou endereços IP no projeto host.

O resultado geral de acessibilidade é Undetermined porque os Testes de conectividade não conseguiram determinar se o pacote pode ser entregue ao destino.

Falhas de teste em redes de peering de rede VPC

Com o peering de rede VPC, não ter permissão para o projeto do Google Cloud da rede peered da rede primary pode causar as falhas de teste listadas na tabela a seguir.

Tipo de falha Comportamento Resultados do trace
Você não tem permissões para a configuração do projeto na rede VPC com peering. O Connectivity Tests pode rastrear apenas as configurações no projeto da rede principal. A análise da configuração mostra um resultado Pacote pode ser encaminhado. Esse resultado indica que um pacote deixaria a rede e seria enviado para uma rede à qual você não tem acesso. Nesse caso, o pacote foi encaminhado para um gateway de rede com peering. Na resposta da API, esse estado corresponde a uma Forward.

O caminho de trace a seguir mostra essa falha nas redes VPC com peering.

Trace de VM para VM por meio de uma rede VPC com peering inacessível em um projeto diferente.
Trace de VM para VM por meio de uma rede VPC com peering inacessível em um projeto diferente

Como testar serviços gerenciados pelo Google

É possível receber uma análise da configuração dos Testes de conectividade em rotas de e para serviços gerenciados pelo Google, como mestres de cluster do Google Kubernetes Engine (GKE) ou instâncias do Cloud SQL. Mesmo que você não tenha permissão para acessar o projeto do Google em que esses recursos estão localizados, os Testes de conectividade ainda poderão analisar a configuração da rede VPC do projeto e fornecer um resultado geral de acessibilidade. Eles não fornecem detalhes de configuração para análise no projeto do Google.

Por padrão, o Connectivity Tests tenta executar um teste usando o endereço IP particular do endpoint do serviço gerenciado pelo Google e a conexão de peering de rede VPC entre sua rede e a rede do Google. Se o endpoint não tiver um endereço IP particular, o Connectivity Tests usará o endereço IP público. O Connectivity Tests analisa se o pacote pode acessar o endpoint, o que inclui analisar a configuração da rede VPC do Google para o endpoint. Se os Testes de conectividade detectarem problemas de configuração no seu projeto, a análise dele será interrompida antes de chegar à rede do Google.

O diagrama a seguir mostra o caminho do trace ao testar a conectividade com os serviços gerenciados pelo Google usando um teste de nó a mestre do GKE como exemplo:

Nó do GKE de origem para o trace do mestre do GKE.
Nó do GKE de origem para o trace do mestre do GKE

Cloud SQL para uma VM

Nesta seção, você verá um exemplo de teste de uma instância do Cloud SQL para uma VM.

Entradas de amostra

A tabela a seguir mostra exemplos de valores de entrada para um teste de uma instância do Cloud SQL. Para visualizar a saída para um teste bem-sucedido, continue na próxima seção.

Parâmetro de entrada Valor de entrada
Protocolo TCP
Instância do Cloud SQL de origem instance-1
Projeto de origem my-project
VM de destino vm-1
Porta de destino 80

Um teste bem-sucedido

Nesta seção, você verá um exemplo de resultado de um teste bem-sucedido de uma instância do Cloud SQL.

Console

A captura de tela a seguir do Console do Cloud mostra um trace de uma instância do Cloud SQL que indica um resultado geral de Reachable.

Este resultado mostra que o Connectivity Tests validou a conectividade de rede da instância do Cloud SQL de origem para a VM de destino. Isso inclui analisar a configuração do projeto do Google em que a instância do Cloud SQL é executada. O trace não fornece detalhes para os recursos do projeto do Google porque você não tem permissão para visualizá-los.

Captura de tela do Console do Cloud para Cloud SQL para trace da VM.
Captura de tela do Console do Cloud para Cloud SQL para trace da VM

Nó do GKE para o mestre do cluster do GKE

Nesta seção, você verá um exemplo de teste de um nó do Google Kubernetes Engine (GKE) para um mestre do cluster do GKE.

Entradas de teste de amostra

A tabela a seguir mostra exemplos de valores de entrada para um teste de um mestre do GKE. Para visualizar a saída para um teste bem-sucedido, continue na próxima seção.

Parâmetro de entrada Valor de entrada
Protocolo TCP
Nó do GKE de origem gke-cluster-1-node-1
Projeto de origem my-project
Mestre do cluster do GKE de destino projects/myproject/locations/us-central1/clusters/cluster-1
Porta de destino 443

Um teste bem-sucedido

Nesta seção, você verá um exemplo de resultado de um teste bem-sucedido para um mestre do GKE.

Console

A captura de tela a seguir do Console do Cloud mostra um trace para um mestre do GKE de destino que indica um resultado geral de Reachable.

Este resultado mostra que o Connectivity Tests validou a conectividade de rede do nó do GKE de origem para o mestre do GKE de destino. Isso inclui a análise da configuração dos recursos do projeto do Google em que o mestre é executado. O trace não fornece detalhes para os recursos do projeto do Google porque você não tem permissão para visualizá-los.

Captura de tela do Console do Cloud para o nó do GKE para trace do mestre.
Captura de tela do Console do Cloud para o trace de nó a mestre do GKE

Nó do GKE para o mestre do GKE por meio de endereço IP público

A tabela a seguir mostra exemplos de valores de entrada para um teste de um mestre do GKE por meio de um endereço IP público. Para visualizar a saída para um teste bem-sucedido, continue na próxima seção.

Entradas de teste de amostra

Parâmetro de entrada Valor de entrada
Protocolo TCP
Nó do GKE de origem gke-cluster-1-node-1
Projeto de origem my-project
Endereço IP de destino 104.1.1.1
Porta de destino 443

Um teste bem-sucedido

Nesta seção, você verá um exemplo de teste bem-sucedido para um mestre do GKE por meio de um endereço IP público.

Console

A captura de tela a seguir do Console do Cloud mostra um trace para o endereço IP público de um mestre do GKE que indica um resultado geral de Reachable.

Este resultado mostra que o Connectivity Tests validou a conectividade da rede do nó do GKE de origem para a rede em que o mestre do GKE é executado, mas não para o mestre do GKE. Ao testar por meio de um endereço IP público, o Connectivity Tests não analisa a configuração dos recursos do projeto do Google em que o mestre é executado.

Captura de tela do Console do Cloud para o trace de nó a mestre do GKE por meio de um endereço IP público.
Captura de tela do Console do Cloud para o trace de nó a mestre do GKE por meio de um endereço IP público

Falhas no teste de serviços gerenciados pelo Google

Ao testar os serviços gerenciados pelo Google, o teste pode falhar com uma mensagem de erro informando que o pacote foi inserido dentro do serviço (por exemplo, DROPPED_INSIDE_GKE_SERVICE ou DROPPED_INSIDE_CLOUD_SQL_SERVICE). Essa mensagem pode indicar um problema de configuração no projeto do Google que hospeda o serviço nos seguintes casos:

  • você testou a conectividade entre um mestre do GKE e um nó do GKE no mesmo cluster (em qualquer direção);
  • você testou a conectividade da rede VPC com uma instância do Cloud SQL conectada à sua rede, em que a origem e o destino estão na mesma região.

Se você receber a mensagem de erro mencionada anteriormente para um dos casos listados anteriormente, entre em contato com o suporte. Caso contrário, a mensagem de erro pode indicar uma entrada inválida. Confirme se você está testando para ou de um endpoint existente e se espera alcançar o recurso gerenciado no projeto do Google. Por exemplo, se você estiver testando um nó do GKE para um mestre do GKE, confirme se o nó existe e se espera que tenha conectividade com o mestre.

Exemplos de entradas de teste: VM para uma instância do Cloud SQL em uma região diferente

A tabela a seguir mostra exemplos de valores de entrada para um teste de uma VM para uma instância do Cloud SQL, em que a VM está em uma região diferente da instância do Cloud SQL. Para visualizar a saída do teste com falha, continue na próxima seção.

Parâmetro de entrada Valor de entrada
Protocolo TCP
VM de origem instance-1
Essa VM está em uma região diferente da instância do Cloud SQL.
Projeto de origem my-project
Instância do Cloud SQL de destino vm-1
Porta de destino 5432

Um teste com falha

Nesta seção, você verá um exemplo de teste com falha para uma instância do Cloud SQL.

Console

A captura de tela a seguir do Console do Cloud mostra um trace para uma instância do Cloud SQL de destino que indica um resultado geral de Unreachable.

Captura de tela do Console do Cloud para VMs com falha no trace do Cloud SQL
Captura de tela do Console do Cloud para VMs com falha no trace do Cloud SQL

Como testar de uma rede VPC para uma rede que não seja do Google Cloud

É possível usar a análise de configuração dos Testes de conectividade para testar a conectividade da rede VPC a uma rede que não seja do Google Cloud com o Cloud VPN ou o Cloud Interconnect. Normalmente, uma rede que não é do Google Cloud é a rede local ou a rede de outro provedor de nuvem.

A análise da configuração avalia o caminho da rede até o endereço IP externo do roteador ou gateway da VPN em uma rede com peering.

O exemplo a seguir mostra um trace de VM1 em uma rede VPC, em um túnel de VPN clássica usando roteamento estático, para VM2 em uma rede local.

Trace de pacote por meio de um túnel de VPN em nuvem usando rotas estáticas.
Trace de pacote por meio de um túnel de VPN em nuvem usando rotas estáticas

Se houver uma rota estática ou dinâmica correspondente para o endereço IP de destino em uma rede em peering, a análise de configuração fará a correspondência e verificará a rota de acordo com a precedência de rota.

Existe uma rota estática padrão para todos os destinos com o próximo salto como o gateway da Internet. O Connectivity Tests corresponde a essa rota padrão, a menos que você a tenha removido ou modificado.

Se a rota estática padrão não existir e não houver outras rotas válidas para o destino, o trace retornará um estado final de Drop.

Caminho de trace para uma rede que não seja do Google Cloud usando roteamento estático.
Caminho de trace para uma rede que não seja do Google Cloud usando roteamento estático


Caminho de trace para uma rede que não seja do Google Cloud usando roteamento dinâmico.
Caminho de trace para uma rede que não seja do Google Cloud usando roteamento dinâmico

Como testar de uma rede que não seja do Google Cloud para uma rede VPC

A análise de configuração verifica se a rede VPC pode receber um pacote de entrada da rede local depois que esse pacote chegar à rede VPC. A análise também verifica se a configuração da rede VPC provavelmente permitirá a entrega desse pacote no destino. A análise de configuração mostra que o Pacote pode ser encaminhado (na resposta da API, o estado final é Forward). O destino é considerado acessível.

Quando a rede VPC faz o peering com sua rede local por meio do Cloud Router, a rede VPC recebe uma ou mais rotas dinâmicas da sua rede local com peering. Ao mesmo tempo, sua rede VPC anuncia as próprias rotas para sua rede local com peering.

Como o Connectivity Tests não tem acesso à sua configuração de rede local, ele não pode verificar a configuração das rotas e regras de firewall corretas no roteador local. Assim, o tráfego da rede local para a rede VPC sempre é considerado válido pela análise da configuração dos Testes de conectividade.

No entanto, os Testes de conectividade podem avaliar se a configuração da VPC permite a entrega de um pacote para um destino no Google Cloud. Para avaliar a acessibilidade, os seguintes recursos do Google Cloud são avaliados:

  • Regras de firewall de entrada da rede VPC.
  • A rota anunciada para endereços IP na sua rede VPC que o Cloud Router anuncia na sua rede local (em peering).

Entradas de teste de amostra

A tabela a seguir mostra exemplos de valores de entrada para um balanceador de carga de teste do Google Cloud descrito na seção anterior. Continue na próxima seção para visualizar a saída para um teste bem-sucedido.

Parâmetro de entrada Valor de entrada
Protocolo TCP
Exemplo de endereço IP local 10.0.29.2
Este é um endereço IP usado na caixa de seleção do Google Cloud Desmarque esta caixa de seleção ao especificar um endereço de origem IP local.

Um teste bem-sucedido de uma rede local

Nesta seção, descrevemos um exemplo de teste bem-sucedido de uma rede local para uma rede VPC.

Console

O resultado do teste a seguir avalia a conectividade pelo Cloud VPN do endereço IP local para uma instância da VM. Também avalia a sessão do BGP (Border Gateway Protocol), rotas e regras de firewall de VPC.

Exemplo de saída para um teste bem-sucedido do local para o Google Cloud.
Exemplo de saída para um teste bem-sucedido do local para o Google Cloud

Como testar entre duas redes que não são do Google Cloud

É possível usar a análise de configuração dos Testes de conectividade para avaliar a acessibilidade entre duas redes que não são do Google Cloud e estão conectadas pelo Network Connectivity Center. Nesse contexto, uma rede que não é do Google Cloud normalmente é o data center local ou uma filial.

Como os Testes de conectividade não têm acesso à configuração de rede local, eles não podem verificar a configuração de rotas e regras de firewall no roteador local. Assim, o tráfego da rede local para a rede VPC é sempre considerado válido pela análise de configuração dos Testes de conectividade, e somente as configurações no Google Cloud são verificadas.

A análise de configuração aprende os intervalos de rede no local dos Cloud Routers associados aos spokes do Network Connectivity Center. É possível identificar problemas de configuração na rede VPC que podem afetar a conectividade entre as redes locais.

Todos os tipos de spoke do Network Connectivity Center usam Cloud Routers para trocar rotas nas sessões do BGP. Exemplo:

  • Spokes do dispositivo Router: quando o Cloud Router e as instâncias do dispositivo de roteador estão na mesma região, eles trocam rotas entre si.
  • Cloud VPN e spokes de anexo da VLAN: o Cloud Router troca rotas do BGP com roteadores na rede local.

Para mais informações sobre a central de conectividade de rede, consulte a Visão geral da central de conectividade de rede.

Como testar entre duas redes que não são do Google Cloud com o dispositivo Router

No exemplo a seguir, os Testes de conectividade rastreiam um pacote simulado de uma rede local para outra. O pacote entra na rede VPC do spoke do dispositivo Router para a primeira rede local. A partir daí, ele segue uma rota dinâmica anunciada pelo Cloud Router associado ao spoke do dispositivo do Router conectado à segunda rede local. O pacote chega à rede local pela segunda instância do dispositivo Router.

Entradas de amostra

A tabela a seguir mostra exemplos de valores de entrada para um teste de um endereço IP na rede local. Para visualizar a saída de um teste bem-sucedido, continue na próxima seção.

Parâmetro de entrada Valor de entrada
Protocolo TCP
Endereço IP do endpoint de origem 192.168.1.1
Este é um endereço IP usado na caixa de seleção do Google Cloud Desmarque esta caixa de seleção ao especificar um endereço de origem IP local.
Endereço IP do endpoint de destino 172.16.1.1
Este é um endereço IP usado na caixa de seleção do Google Cloud Desmarque esta caixa de seleção ao especificar um endereço de destino IP local.

Um teste bem-sucedido de uma rede local para outra rede local

Nesta seção, você verá um exemplo de teste bem-sucedido de uma rede local para outra com spokes do dispositivo Router.

Console

O resultado do teste a seguir avalia a conectividade de uma rede local por duas instâncias do dispositivo Router para outra rede local. Ele também avalia a sessão do BGP, rotas e regras de firewall da VPC.

Exemplo de saída para um teste bem-sucedido do local para o local.
Exemplo de saída para um teste bem-sucedido do local para o local

Como testar entre duas redes que não são do Google Cloud com o Cloud VPN e o Cloud Interconnect

No exemplo a seguir, os Testes de conectividade rastreiam um pacote simulado de uma rede local para outra. O pacote entra na rede VPC pelo gateway da VPN. O pacote chega à outra rede local por uma conexão do Interconnect.

Entradas de amostra

A tabela a seguir mostra exemplos de valores de entrada para um teste de um endereço IP na rede local. Para visualizar a saída de um teste bem-sucedido, continue na próxima seção.

Parâmetro de entrada Valor de entrada
Protocolo TCP
Endereço IP do endpoint de origem 10.0.0.1
Este é um endereço IP usado na caixa de seleção do Google Cloud Desmarque esta caixa de seleção ao especificar um endereço de origem IP local.
Endereço IP do endpoint de destino 10.240.0.1
Este é um endereço IP usado na caixa de seleção do Google Cloud Desmarque esta caixa de seleção ao especificar um endereço de destino IP local.
Porta de destino 80

Um exemplo de teste de uma rede local para outra rede local

Nesta seção, você verá um exemplo de teste de uma rede local para outra rede local com spokes do VPN e do anexo da VLAN.

Console

O resultado do teste a seguir avalia a conectividade de uma rede local com spokes do VPN e do anexo da VLAN para outra rede local.

Exemplo de saída para um teste bem-sucedido do local para o local.
Exemplo de saída para um teste bem-sucedido do local para o local com spokes do VPN e do anexo da VLAN

Como testar os balanceadores de carga do Google Cloud

A análise de configuração dos Testes de conectividade é compatível com o rastreamento de pacotes simulados para todos os tipos de balanceadores de carga do Google Cloud.

O caminho de trace para um balanceador de carga HTTP(S) externo também se aplica a um balanceador de carga de proxy TCP e a um balanceador de carga de proxy SSL. Para mais informações, consulte Visão geral do Cloud Load Balancing.

No exemplo a seguir, o Connectivity Tests rastreia um pacote simulado de um host externo para um VIP para um balanceador de carga HTTP(S) externo. A conexão TCP do host externo termina no proxy para o balanceador de carga HTTP(S) externo. Em seguida, o balanceador de carga HTTP(S) externo inicia uma nova conexão TCP com uma VM que atua como um back-end do balanceador de carga.

Um caminho de trace típico para um balanceador de carga HTTP(S) externo com legenda do diagrama.
Um caminho de trace típico para um balanceador de carga HTTP(S) externo

No caminho de trace a seguir, a análise de configuração dos Testes de conectividade fornece três traces, um para cada caminho possível para os três back-ends do balanceador de carga. Os Testes de conectividade fazem isso porque validam apenas as configurações, e não o plano de dados em tempo real.

Trace de pacote para um balanceador de carga HTTP(S) externo.
Trace de pacote para um balanceador de carga HTTP(S) externo(consulte a legenda do diagrama)

Entradas de teste de amostra

A tabela a seguir mostra exemplos de valores de entrada para um teste para o balanceador de carga HTTP(S) externo descrito na seção anterior. Para visualizar a saída para um teste bem-sucedido, continue na próxima seção.

Parâmetro de entrada Valor de entrada
Protocolo de destino TCP
Porta de destino 80
Exemplo de endereço IP de origem externa (não mostrado) 62.35.1.1
Endereço IP externo do balanceador de carga 203.0.113.99
Projeto de destino myproject

Um teste bem-sucedido para um balanceador de carga

Nesta seção, você verá um exemplo de teste bem-sucedido para o balanceador de carga HTTP(S) externo descrito anteriormente.

No plano de dados real, o algoritmo de balanceamento de carga escolhe uma instância de VM para cada conexão de back-end. Como existem três back-ends do balanceador de carga neste exemplo, o menu Seleção de trace na tela Resultados permite selecionar o trace que você quer visualizar.

Console

O seguinte resultado de teste bem-sucedido valida se todos os seguintes recursos do Google Cloud para o balanceador de carga HTTP(S) externo estão configurados corretamente.

  • a regra de encaminhamento;
  • o back-end do balanceador de carga, incluindo a capacidade do balanceador de carga enviar com êxito verificações de integridade para esses back-ends;
  • a conexão proxy;
  • Regras de firewall da VPC

Esse resultado mostra que um pacote simulado de um endereço IP externo pode alcançar as instâncias de VM de back-end.

Para um exemplo detalhado de um trace para todos os três back-ends, consulte Como detectar configurações inválidas ou inconsistentes.

Exemplo de saída para um teste bem-sucedido em um balanceador de carga HTTP(S) externo.
Exemplo de saída para um teste bem-sucedido em um balanceador de carga HTTP(S) externo

Se você não tiver permissões para revisar os recursos do Google Cloud no caminho da rede para o balanceador de carga HTTP(S) externo, ainda verá resultados no Console do Cloud, incluindo resultados bem-sucedidos. No entanto, o card para cada recurso testado lê "Nenhuma permissão para visualizar o recurso em PROJECT_NAME."

Um teste mostrando uma regra de firewall ausente para uma verificação de integridade

Um trace do balanceador de carga verifica muitas das mesmas configurações de recursos do Google Cloud descritas anteriormente. No entanto, se os recursos do balanceador de carga a seguir estiverem configurados incorretamente, a análise mostrará que O pacote pode ser descartado (o estado final do trace é Drop).

Console

O resultado do teste a seguir mostra que as regras de firewall de entrada de rede VPC não permitem uma verificação de integridade dos back-ends do balanceador de carga, o que os torna indisponíveis para uso nos balanceadores de carga.

Exemplo de saída para uma regra de firewall ausente.
Exemplo de saída para uma regra de firewall ausente

Além das regras de firewall de VPC inválidas, os itens a seguir são problemas de configuração comuns que os Testes de conectividade detectam para os balanceadores de carga do Google Cloud.

Para corrigir esses problemas, use as soluções descritas na tabela a seguir.

Problema de configuração Solução
Os parâmetros de entrada não correspondem ao protocolo ou porta que você definiu na regra de encaminhamento para o balanceador de carga. Antes de executar um teste, altere o parâmetro de entrada para corresponder ao protocolo ou à porta que você definiu na regra de encaminhamento.
A regra de encaminhamento para o balanceador de carga não tem back-ends configurados. Antes de executar um teste, configure os back-ends para o balanceador de carga.
O balanceador de carga tem configurações inválidas ou inconsistentes. Antes de executar um teste, corrija as configurações inválidas ou inconsistentes.
O tráfego não pode alcançar um balanceador de carga TCP/UDP interno que tenha uma região incompatível porque o balanceador de carga TCP/UDP interno é um serviço regional. Antes de executar um teste, configure os componentes do balanceador de carga para que eles estejam localizados na mesma região.

A seguir