Cloud VPN til Cisco ASA: genopbygning efter uenighed om forslaget

NEGOTIATION_FAILURE på en Cloud VPN-tunnel med en Cisco ASA i den anden ende er næsten altid en uenighed om forslaget eller om selectors, og det første nyttige faktum er, at ingen redigering retter det. Cloud VPN fastlåser IKE-forslaget, når tunnelobjektet oprettes. Der findes ikke et felt til at ændre en algoritme på stedet, så reparationen er en sletning og en genskabelse med et noteret udgangspunkt. Behandl det som en genopbygning, og arbejdet bliver en tjekliste i stedet for en eftermiddag med gætterier.

Læs fejlen, før du sletter noget

En forhandlingsfejl er et faseproblem, og peer-loggen nævner som regel fasen. Fase 1, der fejler, betyder, at enderne ikke kunne blive enige om et forslag eller ikke kunne godkende hinanden. Fase 2, der fejler, betyder, at tunnelen kom op, og at de beskyttede selectors ikke passede. Det er forskellige reparationer, og loglinjen er værd at trække ud, før nogen rører en konfiguration.

Fejlen udelukker også ting. Det er ikke en VPC-rute, ikke en firewallregel på tunnelinterfacet og ikke en navneopløsningsfejl inde i netværket. At jagte dem giver selvsikre ændringer, som ikke kan ændre resultatet, og de gør den endelige rettelse sværere at tilskrive.

Fang begge konfigurationer, mens de stadig findes

At slette en tunnel tager et halvt minut og ødelægger det eneste bevis, du havde. Skriv før det de lokale og fjernede selectors ned, peer-adressen, hvem der ejer den delte hemmelighed, og ASA'ens crypto map eller IKEv2-profil. ASA'en svarer på to separate spørgsmål: hvad er konfigureret, og hvad er oppe lige nu:

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

På Google-siden skal du læse tunnelobjektet i stedet for konsolsammendraget, fordi peer-adressen og selector-felterne er de værdier, du skal gengive præcist:

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

Sæt de værdier i sagen før den første sletning. Genopbygningen nedenfor virker kun, fordi du kan genskabe det samme objekt med én bevidst forskel.

De algoritmer, den ene side nægter at forhandle om

Cloud VPN vælger ikke fra en vifte af IKEv1-algoritmer, som en traditionel peer gør. De peer-indstillinger, den forventer, er faste: aes-cbc-128 til kryptering, sha1-96 til både integritet og PRF, Diffie-Hellman-gruppe 2, 36,600 sekunder til fase 1 og 10,800 sekunder til fase 2. ASA-politikken skal tilbyde præcis det sæt. Et ekstra forslag på ASA'en skader ikke, så længe det matchende også står på listen.

IKEv2 giver begge sider mere plads, men reglerne beholder samme form: slå PFS til, vælg en DH-gruppe, som tunnelen understøtter, og hold forslagslisten kort nok til, at en uoverensstemmelse er indlysende. En ASA-peer på Cloud VPN betyder også statisk routing, så de beskyttede præfikser skal planlægges og listes i stedet for at overlade dem til BGP.

En levetid kopieret fra en anden leverandørs skabelon er den sædvanlige forkerte drejning her. Google offentliggør disse værdier som krævede peer-indstillinger, så sæt dem; en kortere værdi forhandles ikke op til det, ASA'en vil have.

Slet, genskab og ryd den gamle tilstand

Slet tunnelen, ikke gatewayen, og notér det navn, Cloud VPN giver erstatningen, fordi navne tildeles og ikke genbruges. Genskab den med de noterede værdier og samme peer-adresse, og føj derefter det matchende forslag til ASA'ens politikliste.

Ryd sikkerhedsassociationerne efter ASA-ændringen og før du læser resultatet. En ASA kan blive ved med at tilbyde en forældet politik, indtil den nuværende SA udløber, så en korrekt konfiguration ser brudt ud i hele den gamle levetid, og den vagthavende konkluderer, at genopbygningen mislykkedes, når den ikke var begyndt:

clear crypto ikev2 sa
clear crypto ipsec sa

Bekræft, at fase 1 kommer op, før du ser på fase 2. Mens fase 1 er nede, er forslaget eller den foruddelte nøgle forkert, og selector-arbejde ændrer ikke det.

Selectors spejler, derefter afgør tællerne

Fase 2 virker kun, når begge ender er enige om de adresser, der beskyttes, og enigheden er spejlet, ikke delt. Googles lokale selector skal matche den selector, ASA'en kalder fjern, og Googles fjern-selector skal matche det, ASA'en kalder lokal. En tunnel med 0.0.0.0/0 på den ene side og et enkelt subnet på den anden klarer fase 1 og fejler derefter fase 2 med den samme overskriftsfejl. Ingen side kan udvide den andens liste.

For politikbaserede selectors skal du liste hvert præfiks-par og gemme listen i sagen. Et subnet, der senere tilføjes on-premises, kræver en ændring i begge ender, fordi en ny rute på ASA'en ikke udvider en selector, og resultatet er en tunnel, der er oppe og kun sender trafik for de præfikser, der fandtes på dag et.

Afslut med én host-til-host-strøm og læs bytetællere på begge sider. Tællere, der stiger på ASA'en og står stille på Google, betyder som regel, at svaret forlader gennem et andet interface, eller at selectoren ikke dækker returpræfikset. Notér algoritmerne, levetiderne, selectors og det nye tunnelnavn, fordi den næste forslagsændring gentager denne genopbygning, og de værdier gør den til en kort opgave.