Cloud VPN para Cisco ASA: reconstruir após uma divergência de proposta

NEGOTIATION_FAILURE num túnel Cloud VPN com um Cisco ASA na outra ponta é quase sempre uma divergência de proposta ou de seletores, e o primeiro fato útil é que nenhuma edição vai corrigir isso. O Cloud VPN fixa a proposta IKE quando o objeto de túnel é criado. Não existe campo para trocar um algoritmo no lugar, então o reparo é apagar e recriar com um ponto de partida registrado. Trate como uma reconstrução e o trabalho vira uma lista de verificação em vez de uma tarde de suposições.

Leia a falha antes de apagar qualquer coisa

Uma falha de negociação é um problema de fase, e o log do par normalmente nomeia a fase. A fase 1 falhar significa que as pontas não chegaram a acordo sobre uma proposta ou não conseguiram se autenticar. A fase 2 falhar significa que o túnel subiu e os seletores protegidos não coincidiam. São reparos diferentes, e vale a pena extrair a linha do log antes de alguém tocar numa configuração.

A falha também descarta coisas. Não é uma rota de VPC, nem uma regra de firewall na interface do túnel, nem uma falha de resolução de nomes dentro da rede. Persegui-las produz mudanças convictas que não podem alterar o resultado, e tornam a correção final mais difícil de atribuir.

Capture as duas configurações enquanto elas existem

Apagar um túnel leva meio minuto e destrói a única prova que você tinha. Antes disso, anote os seletores local e remoto, o endereço do par, quem detém o segredo compartilhado e o crypto map ou o perfil IKEv2 do ASA. O ASA responde a duas perguntas separadas: o que está configurado e o que está no ar agora:

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

No lado do Google, leia o objeto de túnel em vez do resumo do console, porque o endereço do par e os campos de seletor são os valores que você precisa reproduzir exatamente:

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

Coloque esses valores no ticket antes da primeira remoção. A reconstrução abaixo só funciona porque você consegue recriar o mesmo objeto com uma diferença deliberada.

Os algoritmos em que um lado se recusa a negociar

O Cloud VPN não escolhe de uma faixa de algoritmos IKEv1 como um par tradicional. As definições de par que ele espera são fixas: aes-cbc-128 para criptografia, sha1-96 tanto para integridade quanto para 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 tem de oferecer exatamente esse conjunto. Uma segunda proposta no ASA não faz mal desde que a correspondente também esteja na lista.

O IKEv2 dá mais margem aos dois lados, mas as regras mantêm a mesma forma: ative o PFS, escolha um grupo DH que o túnel suporte e mantenha a lista de propostas curta o suficiente para que uma divergência seja óbvia. Um par ASA no Cloud VPN também significa encaminhamento estático, então os prefixos protegidos precisam ser planejados e listados em vez de deixados ao BGP.

Uma duração copiada do modelo de outro fornecedor é o desvio errado habitual aqui. O Google publica esses valores como definições obrigatórias do par, então defina-os; um valor mais curto não é negociado para cima até o que o ASA quer.

Apague, recrie e limpe o estado antigo

Apague o túnel, não o gateway, e anote o nome que o Cloud VPN dá ao substituto, porque os nomes são atribuídos e não reutilizados. Recrie-o com os valores anotados e o mesmo endereço de par, e depois acrescente a proposta correspondente à lista de políticas do ASA.

Limpe as associações de segurança depois da mudança no ASA e antes de ler o resultado. Um ASA pode continuar a oferecer uma política desatualizada até a SA atual expirar, então uma configuração correta parece quebrada durante toda a vida útil antiga e o observador conclui que a reconstrução falhou quando ela ainda não tinha começado:

clear crypto ikev2 sa
clear crypto ipsec sa

Confirme que a fase 1 sobe antes de olhar para a fase 2. Enquanto a fase 1 estiver em baixo, a proposta ou a chave pré-compartilhada estão erradas, e o trabalho nos seletores não mudará isso.

Os seletores espelham-se, depois decidem os contadores

A fase 2 só funciona quando as duas pontas concordam nos endereços protegidos, e a concordância é espelhada, não partilhada. O seletor local do Google tem de coincidir com o seletor que o ASA chama remoto, e o seletor remoto do Google com o que o ASA chama local. Um túnel com 0.0.0.0/0 de um lado e uma única sub-rede do outro passa a fase 1 e depois falha a fase 2 com o mesmo erro principal. Nenhum lado pode alargar a lista do outro.

Para seletores baseados em políticas, liste cada par de prefixos e guarde a lista no ticket. Uma sub-rede acrescentada mais tarde no local exige edição nas duas pontas, porque uma rota nova no ASA não alarga um seletor, e o resultado é um túnel que está no ar e só deixa passar tráfego para os prefixos que existiam no primeiro dia.

Termine com um único fluxo de host para host e leia os contadores de bytes nos dois lados. Contadores a subir no ASA enquanto ficam planos no Google costumam significar que a resposta sai por outra interface, ou que o seletor não cobre o prefixo de retorno. Anote os algoritmos, as durações, os seletores e o novo nome do túnel, porque a próxima mudança de proposta repete esta reconstrução e esses valores tornam-na um trabalho curto.