Cloud VPN til Cisco ASA: byggje opp att etter eit avvikande framlegg

NEGOTIATION_FAILURE på ein Cloud VPN-tunnel med ein Cisco ASA i andre enden er nesten alltid usemje om framlegget eller om selectorane, og det første nyttige faktumet er at inga endring rettar det. Cloud VPN låser IKE-framlegget når tunnelobjektet blir oppretta. Det finst ikkje noko felt for å endre ein algoritme på staden, så reparasjonen er ei sletting og ei attoppretting med eit nedskrive utgangspunkt. Handsame det som ein attoppbygging, og arbeidet blir ei sjekkliste i staden for ein ettermiddag med gissing.

Les feilen før du slettar noko

Ein forhandlingsfeil er eit faseproblem, og peer-loggen namngjev vanlegvis fasen. Fase 1 som feilar tyder at endane ikkje vart samde om eit framlegg eller ikkje kunne autentisere kvarandre. Fase 2 som feilar tyder at tunnelen kom opp og at dei verna selectorane ikkje samsvara. Dette er ulike reparasjonar, og logglina er verdt å hente ut før nokon rører ein konfigurasjon.

Feilen utelukkar òg ting. Det er ikkje ei VPC-rute, ikkje ei brannmurregel på tunnelgrensesnittet og ikkje ein namneoppløysingsfeil inne i nettet. Å jage dei gir sjølvsikre endringar som ikkje kan endre utfallet, og dei gjer den endelege rettinga vanskelegare å tilskrive.

Fang båe konfigurasjonane medan dei framleis finst

Å slette ein tunnel tek eit halvt minutt og øydelegg det einaste beviset du hadde. Skriv først ned dei lokale og eksterne selectorane, peer-adressa, kven som eig den delte løyndomen, og crypto map eller IKEv2-profilen til ASA-en. ASA-en svarar på to separate spørsmål: kva som er konfigurert og kva som er oppe akkurat no:

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

På Google-sida, les tunnelobjektet i staden for konsollsamanfattinga, fordi peer-adressa og selector-felta er verdiane du må gjengi nøyaktig:

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

Set desse verdiane i saka før den første slettinga. Attoppbygginga nedanfor verkar berre fordi du kan opprette det same objektet på nytt med éin medviten skilnad.

Algoritmane den eine sida nektar å forhandle om

Cloud VPN vel ikkje frå ei rekkje IKEv1-algoritmar slik ein tradisjonell peer gjer. Peer-innstillingane det ventar er faste: aes-cbc-128 for kryptering, sha1-96 for både integritet og PRF, Diffie-Hellman-gruppe 2, 36,600 sekund for fase 1 og 10,800 sekund for fase 2. ASA-policyen må by på nøyaktig dette settet. Eit ekstra framlegg på ASA-en skadar ikkje så lenge det samsvarande òg står på lista.

IKEv2 gir båe sider meir rom, men reglane held same forma: slå på PFS, vel ei DH-gruppe tunnelen støttar, og hald framleggslista kort nok til at eit avvik er openbert. Ein ASA-peer på Cloud VPN tyder òg statisk ruting, så dei verna prefiksa må planleggjast og listast i staden for å overlatast til BGP.

Ei levetid kopiert frå malen til ein annan leverandør er den vanlege feilen her. Google publiserer desse verdiane som påkravde peer-innstillingar, så set dei; ein kortare verdi blir ikkje forhandla opp til det ASA-en vil ha.

Slett, opprett på nytt og rydd den gamle tilstanden

Slett tunnelen, ikkje gatewayen, og noter namnet Cloud VPN gir erstatninga, fordi namn blir tildelte og ikkje brukte om att. Opprett han på nytt med dei nedskrivne verdiane og same peer-adresse, og legg deretter til det samsvarande framlegget i policylista til ASA-en.

Rydd tryggingsassosiasjonane etter ASA-endringa og før du les resultatet. Ein ASA kan halde fram med å by på ein utdatert policy til den gjeldande SA-en går ut, så ein korrekt konfigurasjon ser øydelagd ut gjennom heile den gamle levetida, og den som overvakar konkluderer med at attoppbygginga mislukkast då ho ikkje var byrja:

clear crypto ikev2 sa
clear crypto ipsec sa

Stadfest at fase 1 kjem opp før du ser på fase 2. Medan fase 1 er nede, er framlegget eller den førehandsdelte nøkkelen feil, og selector-arbeid endrar ikkje det.

Selectorane speglar, deretter avgjer teljarane

Fase 2 verkar berre når båe endar er samde om adressene som blir verna, og semja er spegla, ikkje delt. Den lokale selectoren til Google må samsvare med selectoren ASA-en kallar ekstern, og den eksterne selectoren til Google med det ASA-en kallar lokal. Ein tunnel med 0.0.0.0/0 på den eine sida og eitt enkelt subnett på den andre passerer fase 1 og feilar deretter fase 2 med same hovudfeil. Inga side kan utvide lista til den andre.

For policybaserte selectorar, list opp kvart prefikspar og hald lista i saka. Eit subnett som blir lagt til lokalt seinare krev ei endring i båe endar, fordi ei ny rute på ASA-en ikkje utvidar ein selector, og resultatet er ein tunnel som er oppe og berre slepp trafikk for prefiksa som fanst den første dagen.

Avslutt med éin straum frå vert til vert og les bytteteljarane på båe sider. Teljarar som stig på ASA-en og står stille på Google tyder vanlegvis at svaret går ut gjennom eit anna grensesnitt, eller at selectoren ikkje dekkjer returprefikset. Noter algoritmane, levetidene, selectorane og det nye tunnelnamnet, fordi den neste framleggsendringa gjer denne attoppbygginga om att, og dei verdiane gjer ho til ei kort oppgåve.