GCP HA VPN rexeita FortiGate: o tipo de ID local non coincide
Google compara a identidade que declara un FortiGate, non só a clave precompartida. Un ID local de tipo FQDN falla esa comprobación mentres o rexistro segue dicindo autenticación.
O AUTHENTICATION_FAILED de Google Cloud HA VPN adoita devolver a xente á clave precompartida, e a clave normalmente é correcta. O túnel atasca na fase 1 porque Google compara algo máis: a identidade que o par declara durante o intercambio IKE. Nun FortiGate esa identidade pode cambiar de tipo sen que ninguén edite un enderezo. Lea o rexistro como unha discrepancia de identidade unha vez que a clave se volveu introducir dúas veces.
Un fallo, dúas comprobacións
IKE verifica un par en dous pasos separados. A clave precompartida demostra que ambos os extremos teñen o mesmo segredo, e unha identidade declarada di ao respondedor quen afirma ser o par. Google comproba esa identidade contra o par co que se configurou. Se se deixa só, un FortiGate envía unha identidade baseada en enderezo derivada da súa interface de saída, e a comparación pasa sen que ninguén o note.
Ambos os pasos caen no mesmo caixón do rexistro, o que explica o coñecido bucle de reescribir a clave catro veces antes de que alguén lea a carga de identidade.
Que pon un FortiGate na carga de identidade
O problema empeza cando alguén fixa un ID local para que ambos os lados coincidan. As compilacións recentes de FortiOS marcan esa identidade como un nome de dominio totalmente cualificado mesmo cando o valor escrito é un enderezo con puntos. Google recibe por tanto unha identidade FQDN mentres espera un enderezo, e rexeita a sesión. Nada na mensaxe di que metade fallou, así que o informe se le como un fallo de autenticación.
Repróduo unha vez coa depuración IKE activada e lea a carga de identidade que a devasa emite realmente.
Na mesma pasada, confirme tres feitos baratos: a versión de IKE que usan ambos os extremos, a clave exacta incluídos os caracteres finais invisibles, e o enderezo do par que Google espera. Responden a preguntas distintas, e unha clave coincidente non di nada sobre a identidade.
Opcións, e canto custa cada unha
Cada saída arranxa unha capa distinta, e ningunha está dispoñible para todo despregamento.
| Option | When it works | What it costs |
|---|---|---|
| Set an address identity on the firewall | Your firmware lets you choose the type | Behaviour you must retest per release |
| Put a public address on the negotiating interface | The firewall can hold a routable address | Not possible behind NAT |
| Terminate on a peer that accepts your identity | Another endpoint validates what you produce | A topology change |
Corrixir a identidade na devasa é a resposta máis limpa onde o firmware lle permite escoller o tipo e conservar o valor. O campo existe nalgúns builds e enche mal o tipo noutros, así que probe a súa versión no canto de fiarse das notas da versión.
Un enderezo público encamiñable na interface de negociación é a volta documentada, porque entón a identidade por defecto coincide co que Google espera e non fai falta ningunha anulación. É onde acaban a maioría de despregamentos, se a devasa pode sequera manter tal enderezo.
Terminar nun par que valida o que vostede produce é un cambio de topoloxía. Tráteo como unha decisión de deseño e non como unha volta cunha descrición máis amable.
Cando NAT elimina unha opción
Detrás de NAT a saída por enderezo público desaparece, e o que queda depende dun comportamento do firmware que vostede non controla. Ese é o punto para elixir deliberadamente entre actualizar, reubicar o par ou aceptar outro punto final na nube. Son tres orzamentos distintos, e elixir un por accidente é como unha volta temporal se converte en arquitectura. Escriba a elección e o seu motivo xunto ao túnel.
Antes de interpretar nada disto, confirme o estado do túnel no lado de Google e que IKE non se está simplemente descartando polo camiño. Un paquete descartado caduca; non produce un rexeitamento.
Que anotar mentres funciona
Anote o tipo de identidade, o seu valor, a versión do firmware e o enderezo do par que estaban vixentes cando o túnel subiu por última vez. Unha actualización do firmware pode volver cambiar o valor por defecto, e o seguinte fallo verase exactamente como unha discrepancia de clave. Coa identidade gardada xunto á clave e o enderezo do par, a seguinte persoa comeza polas comprobacións baratas.
Ese rexistro é tamén a única forma de saber se unha volta segue sendo necesaria tras a próxima actualización.