Cloud VPN na Cisco ASA: herbou nadat die voorstelle nie pas nie

NEGOTIATION_FAILURE op 'n Cloud VPN-tonnel met 'n Cisco ASA aan die ander kant is byna altyd 'n meningsverskil oor die voorstel of die selectors, en die eerste nuttige feit is dat geen wysiging dit sal regstel nie. Cloud VPN stel die IKE-voorstel vas wanneer die tonnel-objek geskep word. Daar is geen veld om 'n algoritme in plek te verander nie, so die regstelling is 'n verwydering en 'n herskep met 'n aangetekende beginpunt. Behandel dit as 'n herbou, dan word die werk 'n kontrolelys eerder as 'n middag van raaiwerk.

Lees die fout voordat jy enigiets verwyder

'n Onderhandelingsfout is 'n fase-probleem, en die peer-log noem gewoonlik die fase. Fase 1 wat misluk beteken die twee kante kon nie oor 'n voorstel saamstem nie of kon mekaar nie verifieer nie. Fase 2 wat misluk beteken die tonnel het opgekom en die beskermde selectors het nie ooreengestem nie. Dit is verskillende herstellings, en die log-reel is die moeite werd om te onttrek voordat iemand aan 'n konfigurasie raak.

Die fout sluit ook dinge uit. Dit is nie 'n VPC-roete nie, nie 'n firewall-reel op die tonnel-koppelvlak nie, en nie 'n naamresolusie-fout binne die netwerk nie. Om dit na te jaag lewer selfversekerde veranderinge wat die uitkoms nie kan verander nie, en dit maak die uiteindelike regstelling moeiliker om toe te skryf.

Teken albei konfigurasies aan terwyl hulle nog bestaan

Om 'n tonnel te verwyder neem 'n halwe minuut en vernietig die enigste bewyse wat jy gehad het. Skryf voor dit die plaaslike en afgeleë selectors neer, die peer-adres, wie die shared secret besit, en die ASA se crypto map of IKEv2-profiel. Die ASA beantwoord twee afsonderlike vrae: wat gekonfigureer is en wat tans op is:

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

Aan die Google-kant, lees die tonnel-objek eerder as die konsol-opsomming, want die peer-adres en die selector-velde is die waardes wat jy presies moet weergee:

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

Plaas daardie waardes in die kaartjie voor die eerste verwydering. Die herbou hieronder werk net omdat jy dieselfde objek met een doelbewuste verskil kan herskep.

Die algoritmes wat een kant weier om te onderhandel

Cloud VPN kies nie uit 'n reeks IKEv1-algoritmes soos 'n tradisionele peer nie. Die peer-instellings wat dit verwag, is vas: aes-cbc-128 vir enkripsie, sha1-96 vir beide integriteit en PRF, Diffie-Hellman-groep 2, 36,600 sekondes vir fase 1 en 10,800 sekondes vir fase 2. Die ASA-beleid moet daardie presiese stel bied. 'n Tweede voorstel op die ASA doen geen kwaad nie solank die ooreenstemmende een ook in die lys is.

IKEv2 gee albei kante meer ruimte, maar die reëls behou dieselfde vorm: aktiveer PFS, kies 'n DH-groep wat die tonnel ondersteun, en hou die voorstel-lys kort genoeg dat 'n onversoenbaarheid duidelik is. 'n ASA-peer op Cloud VPN beteken ook statiese roetering, so die beskermde prefikse moet beplan en gelys word eerder as aan BGP oorgelaat word.

'n Leeftyd wat van 'n ander verskaffer se sjabloon gekopieer is, is die gewone verkeerde draai hier. Google publiseer hierdie waardes as vereiste peer-instellings, so stel hulle; 'n korter waarde word nie opgeonderhandel tot wat die ASA wil hê nie.

Verwyder, herskep en maak die ou toestand skoon

Verwyder die tonnel, nie die gateway nie, en let op die naam wat Cloud VPN aan die vervanging gee, want name word toegewys eerder as hergebruik. Herskep dit met die aangetekende waardes en dieselfde peer-adres, en voeg dan die ooreenstemmende voorstel by die ASA-beleidslys.

Maak die security associations skoon ná die ASA-verandering en voordat jy die resultaat lees. 'n ASA kan aanhou om 'n verouderde beleid te bied totdat die huidige SA verstryk, so 'n korrekte konfigurasie lyk stukkend vir die duur van die ou leeftyd en die waarnemer besluit die herbou het misluk toe dit nog nie begin het nie:

clear crypto ikev2 sa
clear crypto ipsec sa

Bevestig dat fase 1 opkom voordat jy na fase 2 kyk. Terwyl fase 1 af is, is die voorstel of die pre-shared key verkeerd, en selector-werk sal dit nie verander nie.

Selectors spieël, dan besluit tellers

Fase 2 werk net wanneer albei kante saamstem oor die adresse wat beskerm word, en die ooreenkoms word gespieël eerder as gedeel. Die Google plaaslike selector moet pas by die selector wat die ASA afgeleë noem, en die Google afgeleë selector moet pas by wat die ASA plaaslik noem. 'n Tonnel met 0.0.0.0/0 aan een kant en 'n enkele subnet aan die ander kant slaag fase 1 en misluk dan fase 2 met dieselfde hoofopskrif-fout. Geen kant kan die ander se lys verbreed nie.

Vir beleid-gebaseerde selectors, lys elke prefiks-paar en hou die lys in die kaartjie. 'n Subnet wat later on-premises bygevoeg word, benodig 'n wysiging aan albei kante, want 'n nuwe roete op die ASA verbreed nie 'n selector nie, en die resultaat is 'n tonnel wat op is en net verkeer deurlaat vir die prefikse wat op dag een bestaan het.

Eindig met een host-tot-host-vloei en lees grepe-tellers aan albei kante. Tellers wat op die ASA klim terwyl hulle op Google plat bly, beteken gewoonlik die antwoord verlaat via 'n ander koppelvlak, of die selector dek nie die terugkeer-prefiks nie. Teken die algoritmes, leeftye, selectors en die nuwe tonnel-naam aan, want die volgende voorstel-verandering herhaal hierdie herbou en daardie waardes maak dit 'n kort taak.