Cloud VPN cap a Cisco ASA: reconstruir després d'una discrepància de proposta

NEGOTIATION_FAILURE en un túnel Cloud VPN amb un Cisco ASA a l'altre extrem és gairebé sempre una discrepància de proposta o de selectors, i el primer fet útil és que cap edició ho arreglarà. Cloud VPN fixa la proposta IKE quan es crea l'objecte del túnel. No hi ha cap camp per canviar un algorisme in situ, així que la reparació és esborrar i tornar a crear amb un punt de partida anotat. Tracteu-ho com una reconstrucció i la feina es converteix en una llista de comprovació en lloc d'una tarda d'endevinar.

Llegiu la fallada abans d'esborrar res

Una fallada de negociació és un problema de fase, i el registre del parell sovint nomena la fase. Que falli la fase 1 vol dir que els extrems no es van posar d'acord en una proposta o no es van poder autenticar. Que falli la fase 2 vol dir que el túnel es va aixecar i els selectors protegits no coincidien. Són reparacions diferents, i val la pena extreure la línia del registre abans que ningú toqui una configuració.

La fallada també descarta coses. No és una ruta VPC, ni una regla de tallafocs a la interfície del túnel, ni una fallada de resolució de noms dins de la xarxa. Perseguir-ho produeix canvis confiats que no poden alterar el resultat, i fan que la solució final sigui més difícil d'atribuir.

Captureu les dues configuracions mentre encara existeixin

Esborrar un túnel porta mig minut i destrueix l'única evidència que teníeu. Abans, anoteu els selectors locals i remots, l'adreça del parell, qui té el secret compartit i el crypto map o el perfil IKEv2 de l'ASA. L'ASA respon dues preguntes separades: què està configurat i què està aixecat ara:

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

Al costat de Google, llegiu l'objecte del túnel en lloc del resum de la consola, perquè l'adreça del parell i els camps de selector són els valors que heu de reproduir exactament:

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

Poseu aquests valors al tiquet abans del primer esborrat. La reconstrucció de sota només funciona perquè podeu tornar a crear el mateix objecte amb una diferència deliberada.

Els algorismes que un costat es nega a negociar

Cloud VPN no tria d'un ventall d'algorismes IKEv1 com fa un parell tradicional. Els paràmetres del parell que espera són fixos: aes-cbc-128 per al xifratge, sha1-96 tant per a la integritat com per al PRF, grup Diffie-Hellman 2, 36,600 segons per a la fase 1 i 10,800 segons per a la fase 2. La política de l'ASA ha d'oferir exactament aquest conjunt. Una segona proposta a l'ASA no fa mal mentre la coincident també sigui a la llista.

IKEv2 dona més marge a les dues bandes, però les regles mantenen la mateixa forma: activeu PFS, trieu un grup DH que el túnel admeti i manteniu la llista de propostes prou curta perquè una discrepància sigui òbvia. Un parell ASA a Cloud VPN també vol dir encaminament estàtic, així que els prefixos protegits s'han de planificar i llistar en lloc de deixar-los a BGP.

Una vida útil copiada d'una plantilla d'un altre proveïdor és el gir equivocat habitual aquí. Google publica aquests valors com a paràmetres obligatoris del parell, així que poseu-los; un valor més curt no es negocia cap amunt fins al que vol l'ASA.

Esborreu, torneu a crear i netegeu l'estat antic

Esborreu el túnel, no la passarel·la, i anoteu el nom que Cloud VPN dona al substitut, perquè els noms s'assignen i no es reutilitzen. Torneu-lo a crear amb els valors anotats i la mateixa adreça de parell, i després afegiu la proposta coincident a la llista de polítiques de l'ASA.

Netegeu les associacions de seguretat després del canvi a l'ASA i abans de llegir el resultat. Una ASA pot continuar oferint una política antiga fins que caduqui la SA actual, així que una configuració correcta sembla trencada durant tota la vida útil antiga i l'observador conclou que la reconstrucció ha fallat quan encara no havia començat:

clear crypto ikev2 sa
clear crypto ipsec sa

Confirmeu que la fase 1 puja abans de mirar la fase 2. Mentre la fase 1 està caiguda, la proposta o la clau prèviament compartida són incorrectes, i la feina de selectors no ho canviarà.

Els selectors s'emmirallen, després decideixen els comptadors

La fase 2 només funciona quan els dos extrems estan d'acord sobre les adreces protegides, i l'acord és mirall, no compartit. El selector local de Google ha de coincidir amb el selector que l'ASA anomena remot, i el selector remot de Google amb el que l'ASA anomena local. Un túnel amb 0.0.0.0/0 en un costat i una sola subxarxa a l'altre supera la fase 1 i després falla la fase 2 amb el mateix error principal. Cap costat no pot eixamplar la llista de l'altre.

Per als selectors basats en política, llisteu cada parell de prefixos i guardeu la llista al tiquet. Una subxarxa afegida més tard a la seu necessita una edició als dos extrems, perquè una ruta nova a l'ASA no eixampla un selector, i el resultat és un túnel que està aixecat i només passa trànsit pels prefixos que existien el primer dia.

Acabeu amb un sol flux d'amfitrió a amfitrió i llegiu els comptadors de bytes als dos costats. Comptadors que pugen a l'ASA mentre es queden plans a Google solen significar que la resposta surt per una altra interfície, o que el selector no cobreix el prefix de tornada. Anoteu els algorismes, les vides útils, els selectors i el nom nou del túnel, perquè el proper canvi de proposta repeteix aquesta reconstrucció i aquests valors la converteixen en una feina curta.