Cloud VPN til Cisco ASA: bygg på nytt etter en avvikende proposal

NEGOTIATION_FAILURE på en Cloud VPN-tunnel med en Cisco ASA i andre enden er nesten alltid uenighet om forslaget eller om selectorene, og det første nyttige faktum er at ingen redigering retter det. Cloud VPN låser IKE-forslaget når tunnelobjektet opprettes. Det finnes ikke noe felt for å endre en algoritme på stedet, så reparasjonen er en sletting og en gjenoppretting med et notert utgangspunkt. Behandle det som en gjenoppbygging, og arbeidet blir en sjekkliste i stedet for en ettermiddag med gjetting.

Les feilen før du sletter noe

En forhandlingsfeil er et faseproblem, og peer-loggen navngir vanligvis fasen. Fase 1 som feiler betyr at endene ikke ble enige om et forslag eller ikke kunne autentisere hverandre. Fase 2 som feiler betyr at tunnelen kom opp og at de beskyttede selectorene ikke samsvarte. Dette er forskjellige reparasjoner, og logglinjen er verdt å hente ut før noen rører en konfigurasjon.

Feilen utelukker også ting. Det er ikke en VPC-rute, ikke en brannmurregel på tunnelgrensesnittet og ikke en navneoppløsningsfeil inne i nettet. Å jage dem gir selvsikre endringer som ikke kan endre utfallet, og de gjør den endelige rettelsen vanskeligere å tilskrive.

Fang begge konfigurasjonene mens de fortsatt finnes

Å slette en tunnel tar et halvt minutt og ødelegger det eneste beviset du hadde. Skriv først ned de lokale og eksterne selectorene, peer-adressen, hvem som eier den delte hemmeligheten, og ASA-ens crypto map eller IKEv2-profil. ASA-en svarer på to separate spørsmål: hva som er konfigurert og hva som er oppe akkurat nå:

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

På Google-siden, les tunnelobjektet i stedet for konsollsammendraget, fordi peer-adressen og selector-feltene er verdiene du må gjengi nøyaktig:

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

Sett disse verdiene i saken før den første slettingen. Gjenoppbyggingen nedenfor virker bare fordi du kan gjenopprette det samme objektet med én bevisst forskjell.

Algoritmene den ene siden nekter å forhandle om

Cloud VPN velger ikke fra en rekke IKEv1-algoritmer slik en tradisjonell peer gjør. Peer-innstillingene den forventer er faste: aes-cbc-128 for kryptering, sha1-96 for både integritet og PRF, Diffie-Hellman-gruppe 2, 36,600 sekunder for fase 1 og 10,800 sekunder for fase 2. ASA-policyen må tilby nøyaktig dette settet. Et ekstra forslag på ASA-en skader ikke så lenge det samsvarende også står på listen.

IKEv2 gir begge sider mer rom, men reglene beholder samme form: slå på PFS, velg en DH-gruppe tunnelen støtter, og hold forslagslisten kort nok til at et avvik er åpenbart. En ASA-peer på Cloud VPN betyr også statisk ruting, så de beskyttede prefiksene må planlegges og listes i stedet for å overlates til BGP.

En levetid kopiert fra en annen leverandørs mal er den vanlige feilen her. Google publiserer disse verdiene som påkrevde peer-innstillinger, så sett dem; en kortere verdi forhandles ikke opp til det ASA-en vil ha.

Slett, gjenopprett og rydd den gamle tilstanden

Slett tunnelen, ikke gatewayen, og noter navnet Cloud VPN gir erstatningen, fordi navn tildeles og ikke gjenbrukes. Gjenopprett den med de noterte verdiene og samme peer-adresse, og legg deretter til det samsvarende forslaget i ASA-ens policyliste.

Rydd sikkerhetsassosiasjonene etter ASA-endringen og før du leser resultatet. En ASA kan fortsette å tilby en utdatert policy til den gjeldende SA-en utløper, så en korrekt konfigurasjon ser ødelagt ut gjennom hele den gamle levetiden, og den som overvåker konkluderer med at gjenoppbyggingen mislyktes da den ikke var begynt:

clear crypto ikev2 sa
clear crypto ipsec sa

Bekreft at fase 1 kommer opp før du ser på fase 2. Mens fase 1 er nede, er forslaget eller den forhåndsdelte nøkkelen feil, og selector-arbeid endrer ikke det.

Selectorene speiler, deretter avgjør tellerne

Fase 2 virker bare når begge ender er enige om adressene som beskyttes, og enigheten er speilet, ikke delt. Googles lokale selector må samsvare med selectoren ASA-en kaller ekstern, og Googles eksterne selector med det ASA-en kaller lokal. En tunnel med 0.0.0.0/0 på den ene siden og ett enkelt subnett på den andre passerer fase 1 og feiler deretter fase 2 med samme hovedfeil. Ingen side kan utvide den andres liste.

For policybaserte selectorer, list hvert prefikspar og hold listen i saken. Et subnett som legges til lokalt senere krever en endring i begge ender, fordi en ny rute på ASA-en ikke utvider en selector, og resultatet er en tunnel som er oppe og bare slipper trafikk for prefiksene som fantes den første dagen.

Avslutt med én strøm fra vert til vert og les byttetellere på begge sider. Tellere som stiger på ASA-en og står stille på Google betyr vanligvis at svaret går ut gjennom et annet grensesnitt, eller at selectoren ikke dekker returprefikset. Noter algoritmene, levetidene, selectorene og det nye tunnelnavnet, fordi den neste forslagsendringen gjentar denne gjenoppbyggingen, og de verdiene gjør den til en kort jobb.