Cloud VPN cara a Cisco ASA: reconstruír tras unha discrepancia de proposta

NEGOTIATION_FAILURE nun túnel de Cloud VPN cun Cisco ASA no outro extremo é case sempre unha discrepancia de proposta ou de selectores, e o primeiro dato útil é que ningunha edición o vai arranxar. Cloud VPN fixa a proposta IKE cando se crea o obxecto do túnel. Non hai campo para cambiar un algoritmo no sitio, así que a reparación consiste en borrar e volver crear cun punto de partida anotado. Trátao como unha reconstrución e o traballo convértese nunha lista de comprobación en vez dunha tarde de conxecturas.

Le o fallo antes de borrar nada

Un fallo de negociación é un problema de fase, e o rexistro do par adoita nomear a fase. Que falle a fase 1 significa que os extremos non se puxeron de acordo nunha proposta ou non puideron autenticarse. Que falle a fase 2 significa que o túnel subiu e os selectores protexidos non coincidían. Son reparacións distintas, e paga a pena extraer a liña do rexistro antes de que alguén toque unha configuración.

O fallo tamén descarta cousas. Non é unha ruta de VPC, nin unha regra de devasas na interface do túnel, nin un fallo de resolución de nomes dentro da rede. Perseguir esas pistas produce cambios seguros de si mesmos que non poden alterar o resultado, e fan máis difícil atribuír o arranxo final.

Captura ambas configuracións mentres aínda existan

Borrar un túnel leva medio minuto e destrúe a única proba que tiñas. Antes, anota os selectores local e remoto, o enderezo do par, quen ten o segredo compartido e o crypto map ou o perfil IKEv2 do ASA. O ASA responde a dúas preguntas separadas: que está configurado e que está levantado agora:

show running-config crypto ikev2
show crypto ikev2 sa
show crypto ipsec sa | include local ident|remote ident|status

No lado de Google, le o obxecto do túnel en vez do resumo da consola, porque o enderezo do par e os campos de selector son os valores que debes reproducir exactamente:

gcloud compute vpn-tunnels describe tunnel-to-asa --region europe-west1 \
  --format="yaml(peerIp,localTrafficSelector,remoteTrafficSelector,ikeVersion,sharedSecret)"

Pon eses valores no tícket antes do primeiro borrado. A reconstrución de abaixo só funciona porque podes volver crear o mesmo obxecto cunha diferenza deliberada.

Os algoritmos que un lado se nega a negociar

Cloud VPN non escolle dun abano de algoritmos IKEv1 como fai un par tradicional. Os axustes de par que espera son fixos: aes-cbc-128 para o cifrado, sha1-96 tanto para a integridade como para o PRF, grupo Diffie-Hellman 2, 36,600 segundos para a fase 1 e 10,800 segundos para a fase 2. A política do ASA ten que ofrecer exactamente ese conxunto. Unha segunda proposta no ASA non fai dano sempre que a coincidente estea tamén na lista.

IKEv2 dá máis marxe a ambos os dous lados, pero as regras manteñen a mesma forma: activa PFS, escolle un grupo DH que o túnel admita e mantén a lista de propostas abondo curta para que unha discrepancia sexa evidente. Un par ASA en Cloud VPN tamén implica encamiñamento estático, así que os prefixos protexidos hai que planificalos e listalos en vez de deixalos a BGP.

Unha vida útil copiada do modelo doutro provedor é o desvío habitual aquí. Google publica estes valores como axustes obrigatorios do par, así que ponos; un valor máis curto non se negocia cara arriba ata o que quere o ASA.

Borra, volve crear e limpa o estado antigo

Borra o túnel, non a pasarela, e apunta o nome que Cloud VPN lle dá ao substituto, porque os nomes asígnanse e non se reutilizan. Vólveo crear cos valores anotados e o mesmo enderezo de par, e despois engade a proposta coincidente á lista de políticas do ASA.

Limpa as asociacións de seguridade despois do cambio no ASA e antes de ler o resultado. Un ASA pode seguir ofrecendo unha política obsoleta ata que caduque a SA actual, así que unha configuración correcta parece rota durante toda a vida útil antiga e o observador conclúe que a reconstrución fallou cando aínda non comezara:

clear crypto ikev2 sa
clear crypto ipsec sa

Confirma que a fase 1 sobe antes de mirar a fase 2. Mentres a fase 1 está caída, a proposta ou a chave precompartida están mal, e o traballo de selectores non o vai cambiar.

Os selectores reflíctense, despois deciden os contadores

A fase 2 só funciona cando ambos os extremos coinciden nos enderezos protexidos, e a coincidencia é especular, non compartida. O selector local de Google ten que coincidir co selector que o ASA chama remoto, e o selector remoto de Google co que o ASA chama local. Un túnel con 0.0.0.0/0 nun lado e unha soa subrede no outro supera a fase 1 e despois falla a fase 2 co mesmo erro de titular. Ningún lado pode ensanchar a lista do outro.

Para selectores baseados en políticas, enumera cada par de prefixos e garda a lista no tícket. Unha subrede engadida máis tarde na sede necesita unha edición en ambos os extremos, porque unha ruta nova no ASA non ensancha un selector, e o resultado é un túnel que está levantado e só pasa tráfico para os prefixos que existían o primeiro día.

Remata cun só fluxo de host a host e le os contadores de bytes en ambos os lados. Contadores que soben no ASA mentres quedan planos en Google adoitan significar que a resposta sae por outra interface, ou que o selector non cobre o prefixo de volta. Anota os algoritmos, as vidas útiles, os selectores e o nome novo do túnel, porque o seguinte cambio de proposta repite esta reconstrución e eses valores convértena nunha tarefa curta.