GCP HA VPN rejeita o FortiGate: o tipo do ID local não coincide

O AUTHENTICATION_FAILED do Google Cloud HA VPN costuma mandar as pessoas de volta à chave pré-compartilhada, e a chave normalmente está correta. O túnel para na fase 1 porque o Google compara também outra coisa: a identidade que o par declara durante a troca IKE. Num FortiGate essa identidade pode mudar de tipo sem que ninguém edite um endereço. Leia o log como uma divergência de identidade depois que a chave foi reinserida duas vezes.

Uma falha, duas verificações

O IKE verifica um par em duas etapas separadas. A chave pré-compartilhada prova que as duas pontas têm o mesmo segredo, e uma identidade declarada diz ao respondedor quem o par afirma ser. O Google compara essa identidade com o par para o qual foi configurado. Deixado sozinho, um FortiGate envia uma identidade baseada em endereço derivada da sua interface de saída, e a comparação passa sem que ninguém perceba.

As duas etapas caem no mesmo balde do log, o que explica o ciclo familiar de reescrever a chave quatro vezes antes que alguém leia a carga de identidade.

O que um FortiGate coloca na carga de identidade

O problema começa quando alguém define um ID local para os dois lados concordarem. As compilações recentes do FortiOS marcam essa identidade como nome de domínio totalmente qualificado mesmo quando o valor digitado é um endereço com pontos. O Google recebe então uma identidade FQDN enquanto espera um endereço, e recusa a sessão. Nada na mensagem diz qual metade falhou, por isso o relatório se lê como uma falha de autenticação.

Reproduza isso uma vez com a depuração IKE ativada e leia a carga de identidade que o firewall realmente emite.

Na mesma passagem, confirme três fatos baratos: a versão de IKE que as duas pontas usam, a chave exata incluindo caracteres finais invisíveis, e o endereço do par que o Google espera. Eles respondem a perguntas diferentes, e uma chave coincidente não diz nada sobre a identidade.

Opções, e quanto custa cada uma

Cada saída corrige uma camada diferente, e nenhuma está disponível para todas as implantações.

Corrigir a identidade no firewall é a resposta mais limpa onde o firmware permite escolher o tipo e manter o valor. O campo existe em algumas compilações e preenche o tipo errado em outras, então teste a sua versão em vez de confiar nas notas de lançamento.

Um endereço público roteável na interface de negociação é o contorno documentado, porque então a identidade padrão coincide com o que o Google espera e nenhuma substituição é necessária. É onde a maioria das implantações acaba, se o firewall conseguir manter tal endereço.

Terminar num par que valida o que você produz é uma mudança de topologia. Trate isso como uma decisão de projeto e não como um contorno com uma descrição mais amigável.

Quando o NAT elimina uma opção

Atrás do NAT a saída por endereço público desaparece, e o que resta depende de um comportamento de firmware que você não controla. Esse é o ponto para escolher deliberadamente entre atualizar, realocar o par ou aceitar outro ponto final na nuvem. São três orçamentos diferentes, e escolher um por acidente é como um contorno temporário vira arquitetura. Escreva a escolha e o motivo dela ao lado do túnel.

Antes de interpretar qualquer coisa, confirme o estado do túnel do lado do Google e que o IKE não está apenas sendo descartado no caminho. Um pacote descartado expira; ele não produz uma rejeição.

O que registrar enquanto funciona

Anote o tipo de identidade, o valor, a versão do firmware e o endereço do par que estavam em vigor quando o túnel subiu pela última vez. Uma atualização de firmware pode mudar o padrão de novo, e a próxima falha vai parecer exatamente uma divergência de chave. Com a identidade guardada ao lado da chave e do endereço do par, a próxima pessoa começa pelas verificações baratas.

Esse registro também é a única forma de saber se um contorno ainda é necessário depois da próxima atualização.