Solução de problemas

Este guia de solução de problemas ajuda a monitorar e resolver problemas comuns do Cloud VPN.

Para interpretar mensagens de status e referências de criptografia IKE, consulte a seção Referência.

Como visualizar registros e métricas

Consulte Como visualizar registros e métricas.

Como verificar mensagens de erro

  1. Acesse a página VPN no Console do Google Cloud.
    Acessar a página da VPN
  2. Se aparecer um ícone, passe o cursor do mouse sobre ele para ver a mensagem de erro.

Em muitos casos, a mensagem de erro pode ajudar você a identificar o problema. Caso contrário, verifique seus registros para mais informações. Também há informações detalhadas sobre o status na página Detalhes do túnel no Console do Google Cloud.

Como verificar os registros de VPN

Os registros do Cloud VPN são armazenados no Cloud Logging. A geração de registros é automática e não é necessário ativá-la.

Para seu gateway de peering, consulte a documentação do produto para informações sobre como visualizar registros daquele lado da conexão.

Em muitos casos, os gateways estão configurados corretamente, mas há um problema na rede de peering entre os hosts e o gateway ou há um problema com a rede entre o gateway de peerig e o gateway do Cloud VPN.

Acesse a página "Logging"

Nos registros, busque as seguintes informações:

  1. Verifique se o endereço IP de peering remoto configurado no gateway do Cloud VPN está correto.
  2. Verifique se o tráfego que flui dos hosts no local está chegando ao gateway de peering.
  3. Verifique se o tráfego está fluindo entre os dois gateways da VPN em ambas as direções. Nos registros da VPN, verifique as mensagens recebidas do outro gateway da VPN;
  4. Verifique se as versões do IKE configuradas são as mesmas nos dois lados do túnel.
  5. Verifique se o secret compartilhado é o mesmo nos dois lados do túnel.
  6. Se o gateway de VPN de peering estiver por trás da NAT um para um, certifique-se de que o dispositivo NAT foi configurado corretamente para encaminhar o tráfego UDP para seu gateway de VPN de peering nas portas 500 e 4500. É necessário configurar o gateway de peering para que se identifique usando o endereço IP externo do dispositivo NAT. Consulte gateways locais por trás da NAT para ver mais detalhes.
  7. Se os registros da VPN mostrarem um erro no-proposal-chosen, significa que o Cloud VPN e o gateway de VPN de peering não concordaram com um conjunto de criptografias. Para IKEv1, é necessário que o conjunto de criptografias corresponda exatamente. Para IKEv2, é preciso que haja pelo menos uma criptografia comum proposta por cada gateway. Garanta que o gateway de VPN de peering seja configurado com o uso de criptografias compatíveis.
  8. Verifique se o peering, as rotas do Google Cloud e as regras de firewall estão configuradas para que o tráfego atravesse o túnel. Talvez seja necessário entrar em contato com o administrador da rede para receber ajuda.

Também busque nos registros pelas strings a seguir para encontrar problemas específicos:

  1. Acesse o Visualizador de registros no Console do Google Cloud:
    Acessar o Visualizador de registros
  2. Na caixa de pesquisa filtrar por rótulo ou texto, clique no triângulo de abertura à direita e selecione Converter para filtro avançado.
  3. Use um dos filtros avançados listados abaixo para pesquisar um evento específico e ajuste o prazo conforme necessário.
Para ver Use esta pesquisa de geração de registros
O Cloud VPN inicia a fase 1 (IKE SA)

resource.type="vpn_gateway"
("initiating IKE_SA" OR "generating IKE_SA_INIT request")
O Cloud VPN não consegue entrar em contato com o par remoto

resource.type="vpn_gateway"
"establishing IKE_SA failed, peer not responding"
Eventos de autenticação do IKE (fase 1)

resource.type="vpn_gateway"
("generating IKE_AUTH request" OR "parsed IKE_AUTH response")
Autenticação do IKE

resource.type="vpn_gateway"
("authentication of" AND "with pre-shared key successful")
Fase 1 (IKE SA) estabelecida

resource.type="vpn_gateway"
("IKE_SA" AND "established between")
Todos os eventos da fase 2 (SA filho), incluindo eventos criação de nova chave

resource.type="vpn_gateway"
"CHILD_SA"
O par solicita a criação de nova chave na fase 2

resource.type="vpn_gateway"
detected rekeying of CHILD_SA
O par solicita o encerramento da fase 2 (SA filho)

resource.type="vpn_gateway"
received DELETE for ESP CHILD_SA
O Cloud VPN solicita o encerramento da fase 2 (SA filho)

resource.type="vpn_gateway"
sending DELETE for ESP CHILD_SA
O Cloud VPN encerra a fase 2 (SA filho), talvez em resposta ao par

resource.type="vpn_gateway" closing CHILD_SA
O Cloud VPN encerrou a fase 2 por conta própria

resource.type="vpn_gateway" CHILD_SA closed
Se os seletores de tráfego remoto não corresponderem

resource.type="vpn_gateway"
Remote traffic selectors narrowed
Se os seletores de tráfego local não corresponderem

resource.type="vpn_gateway"
Local traffic selectors narrowed

Como verificar a conectividade

Considere as seguintes sugestões ao verificar a conectividade entre sistemas no local e VMs do Google Cloud usando ping:

  • Certifique-se de que as regras de firewall na sua rede do Google Cloud permitem tráfego ICMP de entrada. A regra de permissão de saída implícita permite o tráfego ICMP de saída da sua rede, a menos que ela tenha sido modificada. Certifique-se também de que os firewalls no local estejam configurados para permitir tráfego ICMP de entrada e saída.

  • Dê um ping nas VMs do Google Cloud e nos sistemas no local usando os endereços IP internos. O ping de endereços IP externos de gateways da VPN não testa a conectividade pelo túnel.

  • Ao testar a conectividade do local com o Google Cloud, é melhor iniciar um ping de um sistema na sua rede, e não do gateway de VPN. É possível dar um ping de um gateway se você configurar a interface de origem apropriada, mas o ping de uma instância na sua rede tem a vantagem de testar a configuração do seu firewall.

  • Os testes de ping não verificam se as portas TCP ou UDP estão realmente abertas. Faça mais testes após confirmar que os sistemas têm conectividade básica usando o ping.

Como calcular a capacidade de rede

É possível calcular a capacidade da rede no Google Cloud e nos locais de nuvem terceirizados ou no local. O documento acima inclui informações sobre como analisar resultados, explicações sobre variáveis que afetam o desempenho da rede, além de dicas de solução de problemas.

Problemas comuns e soluções

O túnel fica inativo por alguns segundos com frequência

Por padrão, o Cloud VPN negocia uma SA de substituição antes que a existente expire. Isso também é conhecido como rechaveamento. Talvez seu gateway de VPN de peering não esteja rechaveando. Em vez disso, ele talvez negocie uma nova SA somente após excluir a existente, causando interrupções.

Para verificar se o rechaveamento do gateway de peering é possível, visualize os registros do Cloud VPN. Se a conexão cair e for restabelecida logo depois de uma mensagem de registro Received SA_DELETE, significa que não ocorreu o rechaveamento do gateway no local.

Verifique as configurações do túnel no documento Criptografias IKE aceitas. Certifique-se de que a vida útil da Fase 2 está correta e que um grupo Diffie-Hellman (DH) esteja configurado com um dos valores recomendados.

É possível usar um filtro de registro avançado do Logging para pesquisar eventos no túnel do Cloud VPN. Por exemplo, o filtro avançado a seguir pesquisa incompatibilidades em grupos DH:

resource.type="vpn_gateway"
"Peer proposal: DOES NOT HAVE DIFFIE_HELLMAN_GROUP"

Gateways locais por trás da NAT

O Cloud VPN funciona com gateways de VPN de peering ou no ou local que estão por trás da NAT. Isso é possibilitado pelo encapsulamento UDP e pela NAT-T, e apenas a NAT de um para um é aceita.

Como parte do processo de autenticação, o Cloud VPN verifica a identidade do gateway de peering. O Cloud VPN espera que cada gateway de peering se identifique usando o tipo de identidade ID_IPV4_ADDR, conforme especificado no RFC 7815, com o endereço IP público (gateway de peering), configurado para o túnel do Cloud VPN.

As mensagens de registro a seguir indicam que o gateway da VPN de peering está se identificando incorretamente com um endereço IP particular. Neste exemplo, [PEER GATEWAY PRIVATE IP] é um endereço IP particular, e [PEER GATEWAY PUBLIC IP] é o endereço IP público do dispositivo NAT entre o gateway de VPN de peering e a Internet.

authentication of '[PEER GATEWAY PRIVATE IP]' with pre-shared key successful
constraint check failed: identity '[PEER GATEWAY PUBLIC IP]' required
selected peer config 'vpn_[PEER GATEWAY PUBLIC IP]' inacceptable: constraint checking failed

Ao usar NAT de um para um, é necessário que o gateway da VPN no local se identifique usando o mesmo endereço IP externo do dispositivo NAT:

  • É necessário que o tipo de identidade seja ID_IPV4_ADDR (RFC 7815).

  • Nem todos os dispositivos Cisco são compatíveis com a configuração de uma identidade de dispositivo para um endereço IP diferente daquele que o dispositivo está usando, isto é, o endereço interno dele. Por exemplo, os dispositivos Cisco ASA não são compatíveis com a atribuição de diferentes endereços IP (externos) como identidade. Portanto, não é possível que esses dispositivos sejam configurados para usar NAT de um para um com o Cloud VPN.

  • Para dispositivos Juniper, é possível definir a identidade do dispositivo usando set security ike gateway [NAME] local-identity inet [PUBLIC_IP], em que [NAME] é o nome do gateway de VPN e [PUBLIC_IP] é o endereço IP externo. Consulte este artigo da Juniper TechLibrary (em inglês) para saber mais.

A conectividade funciona em algumas VMs, mas não em outras

Se ping, traceroute ou outros métodos de enviar tráfego funcionarem somente de algumas VMs para seus sistemas no local ou apenas de alguns sistemas no local para algumas VMs do Google Cloud, e se você tiver verificado que o Google Cloud e as regras de firewall no local não estão bloqueando o tráfego que você está enviando, é possível que haja seletores de tráfego que excluem determinadas origens ou destinos.

Os seletores de tráfego definem os intervalos de endereços IP para um túnel da VPN. Além das rotas, a maioria das implementações de VPN só transmite pacotes por meio de um túnel se as origens deles couberem nos intervalos de IP especificados no seletor de tráfego local e se os destinos deles couberem nos intervalos de IP especificados no seletor de tráfego remoto. Você especifica os seletores de tráfego quando cria um túnel de VPN clássica usando roteamento baseado em política ou uma VPN baseada em rota. Você também especifica os seletores de tráfego ao criar o túnel de peering correspondente.

Alguns fornecedores usam termos como proxy local, domínio de criptografia local ou rede do lado esquerdo como sinônimos para seletor de tráfego local. Da mesma forma, proxy remoto, domínio de criptografia remota ou rede do lado direito são sinônimos para seletor de tráfego remoto.

Para alterar os seletores de tráfego de um túnel de VPN clássica, é necessário excluir e recriar o túnel. Essas etapas são necessárias porque os seletores de tráfego são parte integrante da criação do túnel, e não é possível editar os túneis posteriormente.

Siga as diretrizes a seguir ao definir seletores de tráfego:

  • É necessário que o seletor de tráfego local do túnel do Cloud VPN cubra todas as sub-redes da rede VPC que você precisa compartilhar sua rede de peering.
  • É necessário que o seletor de tráfego local da sua rede de peering cubra todas as sub-redes no local que você precisa compartilhar com sua rede VPC.
  • Para um determinado túnel de VPN, os seletores de tráfego têm o seguinte relacionamento:
    • É necessário que o seletor de tráfego local do Cloud VPN corresponda ao seletor de tráfego remoto do túnel no gateway de VPN de peering.
    • É necessário que o seletor de tráfego remoto do Cloud VPN corresponda ao seletor de tráfego local do túnel no gateway de VPN de peering.

Como conectar gateways de VPN clássica e de VPN de alta disponibilidade

O Google Cloud não é compatível com a criação de um túnel de um gateway de VPN de alta disponibilidade que se conecta a um gateway de VPN clássica. Se você tentar criar um recurso externalVpnGateway com o endereço IP externo de um gateway de VPN clássica, o Google Cloud retornará a seguinte mensagem de erro:

  You cannot provide an interface with an IP address owned by Google Cloud.
  You can only create tunnels from an HA gateway to an HA gateway
  or create tunnels from an HA gateway to an ExternalVpnGateway.

Este comportamento é esperado. Crie um túnel de VPN que conecte um gateway de VPN de alta disponibilidade a outro gateway de VPN de alta disponibilidade.

Referência de solução de problemas

Esta seção inclui uma lista de ícones e mensagens de status e uma lista de criptografias IKE compatíveis.

Ícones de status

O Cloud VPN usa os seguintes ícones de status no console do Google Cloud:

Imagem do ícone Cor Descrição Aplica-se às mensagens
Ícone de sucesso verde
Verde Sucesso ESTABELECIDO
Ícone de aviso amarelo
Amarelo Aviso ALOCANDO RECURSOS, PRIMEIRO HANDSHAKE, AGUARDANDO A CONFIGURAÇÃO COMPLETA, PROVISIONANDO
Ícone de erro vermelho
Vermelho Erro Qualquer outra mensagem

Mensagens de status

O Cloud VPN usa as seguintes mensagens de status para indicar o gateway de VPN e os estados do túnel. O túnel de VPN é faturado nos estados indicados.

Mensagem Descrição Túnel faturado nesse estado?
ALOCANDO RECURSOS Alocando recursos para configurar o túnel Sim
PROVISIONANDO Aguardando o recebimento de todas as configurações para configurar o túnel Não
AGUARDANDO A CONFIGURAÇÃO COMPLETA A configuração completa foi recebida, mas o túnel ainda não foi estabelecido Sim
PRIMEIRO HANDSHAKE Estabelecendo o túnel Sim
ESTABELECIDO Uma sessão de comunicação segura foi estabelecida com sucesso Sim
ERRO DE REDE
(substituído por NENHUM PACOTE DE ENTRADA)
Autorização de IPsec inválida Sim
ERRO DE AUTORIZAÇÃO Falha no handshake Sim
FALHA NA NEGOCIAÇÃO A configuração do túnel foi rejeitada. talvez por ter sido adicionada a uma denylist Sim
DESPROVISIONANDO O túnel está sendo desativado Não
NENHUM PACOTE DE ENTRADA O gateway não está recebendo nenhum pacote da VPN local Sim
REJEITADO A configuração do túnel foi rejeitada. Entre em contato com o Suporte. Sim
PARADO O túnel está parado e não está ativo. Provavelmente devido à exclusão de uma ou mais regras de encaminhamento necessárias para o túnel VPN. Sim

Visão geral da criptografia IKE

As seguintes criptografias IKE são compatíveis com a VPN clássica e a VPN de alta disponibilidade.

Há duas seções para IKEv2, uma para criptografia autenticada com dados associados (AEAD, na sigla em inglês) e outra para criptografias que não usam AEAD.

Criptografias IKEv2 que usam AEAD

Fase 1

Papel do código Cipher Notas
Criptografia e integridade
  • AES-GCM-16-128
  • AES-GCM-16-192
  • AES-GCM-16-256
Nesta lista, o primeiro número é o tamanho do parâmetro ICV em bytes (octetos) e o segundo é o tamanho da chave em bits.

Uma documentação pode expressar o parâmetro ICV (o primeiro número) em bits (8 se torna 64, 12 se torna 96 e 16 se torna 128).
Função pseudo-aleatória (PRF)
  • PRF-AES128-XCBC
  • PRF-AES128-CMAC
  • PRF-HMAC-SHA1
  • PRF-HMAC-MD5
  • PRF-HMAC-SHA2-256
  • PRF-HMAC-SHA2-384
  • PRF-HMAC-SHA2-512
Muitos dispositivos não exigem uma configuração de PRF explícita.
Diffie-Hellman (DH)
  • modp_2048 (grupo 14)
  • modp_2048_224 (modp_2048s224)
  • modp_2048_256 (modp_2048s256)
  • modp_1536 (grupo 5)
  • modp_3072 (grupo 15)
  • modp_4096 (grupo 16)
  • modp_8192 (grupo 18)
  • modp_1024 (grupo 2)
  • modp_1024_160 (modp_1024s160)
A proposta do Cloud VPN apresenta esses algoritmos de troca de chaves na ordem mostrada. O Cloud VPN aceita qualquer proposta que inclua um ou mais desses algoritmos, em qualquer ordem.
Ciclo de vida da Fase 1 36.000 segundos (10 horas)

Fase 2

Papel do código Cipher Notas
Criptografia e integridade
  • AES-GCM-16-128
  • AES-GCM-16-256
  • AES-GCM-16-192
A proposta do Cloud VPN apresenta esses algoritmos na ordem mostrada. O Cloud VPN aceita qualquer proposta que inclua um ou mais desses algoritmos, em qualquer ordem.

O primeiro número em cada algoritmo é o tamanho do parâmetro ICV em bytes (octetos) e o segundo é o tamanho da chave em bits. Alguns documentos podem expressar o parâmetro ICV (o primeiro número) em bits (8 se torna 64, 12 se torna 96, 16 se torna 128).
Algoritmo PFS (obrigatório)
  • modp_2048 (grupo 14)
  • modp_2048_224 (modp_2048s224)
  • modp_2048_256 (modp_2048s256)
  • modp_1536 (grupo 5)
  • modp_3072 (grupo 15)
  • modp_4096 (grupo 16)
  • modp_8192 (grupo 18)
  • modp_1024 (grupo 2)
  • modp_1024_160 (modp_1024s160)
A proposta do Cloud VPN apresenta esses algoritmos de troca de chaves na ordem mostrada. O Cloud VPN aceita qualquer proposta que tenha um ou mais desses algoritmos, em qualquer ordem.
Diffie-Hellman (DH) Consulte a Fase 1 Se o gateway da VPN exigir configurações de DH para a Fase 2, use as mesmas configurações usadas para a Fase 1.
Ciclo de vida da Fase 2 10.800 segundos (3 horas)

Criptografias IKEv2 que não usam AEAD

Fase 1

Papel do código Cipher Notas
Criptografia
  • AES-CBC-128
  • AES-CBC-192
  • AES-CBC-256
  • 3DES-CBC
  • AES-XCBC-96
  • AES-CMAC-96
A proposta do Cloud VPN apresenta esses algoritmos simétricos de criptografia na ordem mostrada. O Cloud VPN aceita qualquer proposta que use um ou mais desses algoritmos, em qualquer ordem.
Integridade
  • HMAC-SHA1-96
  • HMAC-MD5-96
  • HMAC-SHA2-256-128
  • HMAC-SHA2-384-192
  • HMAC-SHA2-512-256
A proposta do Cloud VPN apresenta esses algoritmos HMAC na ordem mostrada. O Cloud VPN aceita qualquer proposta que tenha um ou mais desses algoritmos, em qualquer ordem.

A documentação do seu gateway VPN local pode usar um nome um pouco diferente para o algoritmo. Por exemplo, HMAC-SHA2-512-256 pode ser chamado de apenas SHA2-512 ou SHA-512, eliminando o número de comprimento de truncamento e outras informações irrelevantes.
Função pseudo-aleatória (PRF)
  • PRF-AES-128-XCBC
  • PRF-AES-128-CMAC
  • PRF-SHA1
  • PRF-MD5
  • PRF-SHA2-256
  • PRF-SHA2-384
  • PRF-SHA2-512
Muitos dispositivos não exigem uma configuração de PRF explícita.
Diffie-Hellman (DH)
  • modp_2048 (grupo 14)
  • modp_2048_224 (modp_2048s224)
  • modp_2048_256 (modp_2048s256)
  • modp_1536 (grupo 5)
  • modp_3072 (grupo 15)
  • modp_4096 (grupo 16)
  • modp_8192 (grupo 18)
  • modp_1024 (grupo 2)
  • modp_1024_160 (modp_1024s160)
A proposta do Cloud VPN apresenta esses algoritmos de troca de chaves na ordem mostrada. O Cloud VPN aceita qualquer proposta que contenha um ou mais desses algoritmos, em qualquer ordem.
Ciclo de vida da Fase 1 36.000 segundos (10 horas)

Fase 2

Papel do código Cipher Notas
Criptografia
  • AES-CBC-128
  • AES-CBC-256
  • AES-CBC-192
A proposta do Cloud VPN apresenta esses algoritmos simétricos de criptografia na ordem mostrada. O Cloud VPN aceita qualquer proposta que contenha um ou mais desses algoritmos, em qualquer ordem.
Integridade
  • HMAC-SHA2-256-128
  • HMAC-SHA2-512-256
  • HMAC-SHA1-96
A proposta do Cloud VPN apresenta esses algoritmos HMAC na ordem mostrada. O Cloud VPN aceita qualquer proposta que contenha um ou mais desses algoritmos, em qualquer ordem.

A documentação do seu gateway VPN local pode usar um nome um pouco diferente para o algoritmo. Por exemplo, HMAC-SHA2-512-256 pode ser chamado de apenas SHA2-512 ou SHA-512, eliminando o número de comprimento de truncamento e outras informações irrelevantes.
Algoritmo PFS (obrigatório)
  • modp_2048 (grupo 14)
  • modp_2048_224 (modp_2048s224)
  • modp_2048_256 (modp_2048s256)
  • modp_1536 (grupo 5)
  • modp_3072 (grupo 15)
  • modp_4096 (grupo 16)
  • modp_8192 (grupo 18)
  • modp_1024 (grupo 2)
  • modp_1024_160 (modp_1024s160)
A proposta do Cloud VPN apresenta esses algoritmos de troca de chaves na ordem mostrada. O Cloud VPN aceita qualquer proposta que contenha um ou mais desses algoritmos, em qualquer ordem.
Diffie-Hellman (DH) Consulte a Fase 1. Se seu gateway VPN exigir as configurações de DH para a Fase 2, use as mesmas configurações usadas para a Fase 1.
Ciclo de vida da Fase 2 10.800 segundos (3 horas)

Criptografias IKEv1

Fase 1

Papel do código Cipher
Criptografia AES-CBC-128
Integridade HMAC-SHA1-96
Função pseudo-aleatória (PRF)* PRF-SHA1-96
Diffie-Hellman (DH) modp_1024 (grupo 2)
Ciclo de vida da Fase 1 36.600 segundos (10 horas, 10 minutos)

* Para mais informações sobre o PRF no IKEv1, consulte RFC 2409.

Fase 2

Papel do código Cipher
Criptografia AES-CBC-128
Integridade HMAC-SHA1-96
Algoritmo PFS (obrigatório) modp_1024 (grupo 2)
Diffie-Hellman (DH) Se você precisar especificar DH para o gateway da VPN, use a mesma configuração usada para a Fase 1.
Ciclo de vida da Fase 2 10.800 segundos (3 horas)

A seguir

Solução de problemas relacionados

  • Consulte a documentação do Cloud Logging para ver mais informações, inclusive como exportar registros e como usar métricas com base em registros para monitoramento e recebimento de alertas.

Relacionado à VPN