Cloud VPN către Cisco ASA: reconstruire după o nepotrivire de propunere

NEGOTIATION_FAILURE pe un tunel Cloud VPN cu un Cisco ASA la celălalt capăt este aproape întotdeauna o nepotrivire de propunere sau de selectori, iar primul fapt util este că nicio modificare nu o va rezolva. Cloud VPN fixează propunerea IKE în momentul creării obiectului de tunel. Nu există un câmp pentru schimbarea unui algoritm pe loc, așa că reparația este o ștergere și o recreare cu un punct de plecare consemnat. Tratați-o ca pe o reconstruire și munca devine o listă de verificare în loc de o după-amiază de presupuneri.

Citiți eroarea înainte de a șterge ceva

O eroare de negociere este o problemă de fază, iar jurnalul partenerului numește de obicei faza. Faza 1 care eșuează înseamnă că extremitățile nu s-au înțeles asupra unei propuneri sau nu s-au putut autentifica reciproc. Faza 2 care eșuează înseamnă că tunelul a urcat și selectorii protejați nu se potriveau. Sunt reparații diferite, iar linia din jurnal merită extrasă înainte ca cineva să atingă o configurație.

Eroarea exclude și anumite cauze. Nu este o rută VPC, nu este o regulă de firewall pe interfața tunelului și nu este o defecțiune de rezolvare a numelor în rețea. Urmărirea lor produce modificări încrezătoare care nu pot schimba rezultatul și fac corecția finală mai greu de atribuit.

Capturați ambele configurații cât timp încă există

Ștergerea unui tunel durează jumătate de minut și distruge singura dovadă pe care o aveați. Înainte, notați selectorii local și remote, adresa partenerului, cine deține secretul partajat și crypto map-ul sau profilul IKEv2 al ASA. ASA răspunde la două întrebări separate: ce este configurat și ce este ridicat acum:

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

Pe partea Google, citiți obiectul tunelului în locul sumarului din consolă, pentru că adresa partenerului și câmpurile de selector sunt valorile pe care trebuie să le reproduceți exact:

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

Puneți acele valori în tichet înainte de prima ștergere. Reconstruirea de mai jos funcționează doar pentru că puteți recrea același obiect cu o diferență deliberată.

Algoritmii despre care o parte refuză să negocieze

Cloud VPN nu alege dintr-o gamă de algoritmi IKEv1 ca un partener tradițional. Setările de partener pe care le așteaptă sunt fixe: aes-cbc-128 pentru criptare, sha1-96 atât pentru integritate cât și pentru PRF, grupul Diffie-Hellman 2, 36,600 secunde pentru faza 1 și 10,800 secunde pentru faza 2. Politica ASA trebuie să ofere exact acest set. O a doua propunere pe ASA nu dăunează dacă cea potrivită este și ea în listă.

IKEv2 le dă mai mult spațiu ambelor părți, dar regulile păstrează aceeași formă: activați PFS, alegeți un grup DH pe care tunelul îl suportă și țineți lista de propuneri suficient de scurtă încât o nepotrivire să fie evidentă. Un partener ASA pe Cloud VPN înseamnă și rutare statică, așa că prefixele protejate trebuie planificate și listate, nu lăsate pe seama BGP.

O durată de viață copiată din șablonul altui producător este abaterea greșită obișnuită aici. Google publică aceste valori ca setări obligatorii de partener, așa că setați-le; o valoare mai scurtă nu este negociată în sus până la ce vrea ASA.

Ștergeți, recreați și curățați starea veche

Ștergeți tunelul, nu gateway-ul, și notați numele pe care Cloud VPN îl dă înlocuitorului, pentru că numele sunt atribuite și nu refolosite. Recreați-l cu valorile consemnate și aceeași adresă de partener, apoi adăugați propunerea potrivită în lista de politici a ASA.

Curățați asocierile de securitate după modificarea pe ASA și înainte de a citi rezultatul. Un ASA poate continua să ofere o politică învechită până când SA-ul curent expiră, așa că o configurație corectă pare stricată pe toată durata vechii durate de viață, iar observatorul concluzionează că reconstruirea a eșuat când ea nici nu începuse:

clear crypto ikev2 sa
clear crypto ipsec sa

Confirmați că faza 1 urcă înainte de a privi faza 2. Cât timp faza 1 este jos, propunerea sau cheia pre-partajată sunt greșite, iar munca la selectori nu va schimba asta.

Selectorii se oglindesc, apoi decid contoarele

Faza 2 funcționează doar când ambele extremități sunt de acord asupra adreselor protejate, iar acordul este în oglindă, nu partajat. Selectorul local al Google trebuie să corespundă selectorului pe care ASA îl numește remote, iar selectorul remote al Google celui pe care ASA îl numește local. Un tunel cu 0.0.0.0/0 pe o parte și o singură subrețea pe cealaltă trece faza 1 și apoi eșuează faza 2 cu aceeași eroare principală. Nicio parte nu poate lărgi lista celeilalte.

Pentru selectorii bazați pe politici, enumerați fiecare pereche de prefixe și păstrați lista în tichet. O subrețea adăugată mai târziu în sediu necesită o modificare la ambele capete, pentru că o rută nouă pe ASA nu lărgește un selector, iar rezultatul este un tunel care este sus și lasă trafic doar pentru prefixele care existau în prima zi.

Încheiați cu un singur flux de la gazdă la gazdă și citiți contoarele de octeți pe ambele părți. Contoarele care urcă pe ASA în timp ce rămân plate pe Google înseamnă de obicei că răspunsul pleacă prin altă interfață sau că selectorul nu acoperă prefixul de întoarcere. Notați algoritmii, duratele de viață, selectorii și noul nume al tunelului, pentru că următoarea schimbare de propunere repetă această reconstruire, iar acele valori o transformă într-o sarcină scurtă.