Cloud VPN nei Cisco ASA: weropbouwe nei in misferstân yn it foarstel

NEGOTIATION_FAILURE op in Cloud VPN-tunnel mei in Cisco ASA oan de oare kant is hast altyd in misferstân oer it foarstel of de selektors, en it earste nuttige feit is dat gjin bewurking dat oplost. Cloud VPN fêstiget it IKE-foarstel as it tunnelobjekt oanmakke wurdt. Der is gjin fjild om in algoritme op plak te feroarjen, dus de reparaasje is wiskje en opnij oanmeitsje mei in fêstleine begjinpunt. Behannelje it as in weropbou en it wurk wurdt in checklist ynstee fan in middei gokken.

Lês de flater foardat jo eat wiskje

In ûnderhannelingsflater is in fazeprobleem, en it peer-log neamt meast de faze. Faze 1 dy't mislearret betsjut dat de einen it net iens wurde koene oer in foarstel of inoar net autentisearje koene. Faze 2 dy't mislearret betsjut dat de tunnel omheech kaam en de beskerme selektors net oerienkamen. Dat binne ferskillende reparaasjes, en it logrigel is it wurdich om te heljen foardat immen in konfiguraasje oanrekket.

De flater slút ek dingen út. It is gjin VPC-route, gjin firewallregel op 'e tunnelinterface en gjin namme-oplossingsflater yn it netwurk. Dat efterfolgje jout selsbewuste feroarings dy't it resultaat net feroarje kinne, en makket de úteinlike reparaasje hurder ta te skriuwen.

Fêstlizze beide konfiguraasjes wylst se noch besteane

In tunnel wiskje duorret in heale minút en ferneatiget it iennige bewiis dat jo hiene. Foar dy tiid skriuw de lokale en fiere selektors op, it peer-adres, wa't it dielde geheim hat, en de crypto map of it IKEv2-profyl fan 'e ASA. De ASA beantwurdet twa aparte fragen: wat is konfigurearre en wat is op it stuit omheech:

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

Lês oan 'e Google-kant it tunnelobjekt ynstee fan 'e konsolesamfetting, want it peer-adres en de selektor-fjilden binne de wearden dy't jo krekt werjaan moatte:

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

Set dy wearden yn 'e kaart foardat de earste wiskbeurt. De weropbou hjirûnder wurket allinnich omdat jo itselde objekt opnij meitsje kinne mei ien bewuste ferskil.

De algoritmes dêr't ien kant net oer ûnderhannelje wol

Cloud VPN kiest net út in rige IKEv1-algoritmes lykas in tradisjonele peer. De peer-ynstellings dy't it ferwachtet binne fêst: aes-cbc-128 foar fersifering, sha1-96 foar sawol yntegriteit as PRF, Diffie-Hellman-groep 2, 36,600 sekonden foar faze 1 en 10,800 sekonden foar faze 2. It ASA-belied moat krekt dy set biede. In twadde foarstel op 'e ASA docht gjin kwea salang't it oerienkommende ek yn 'e list stiet.

IKEv2 jout beide kanten mear romte, mar de regels hâlde deselde foarm: set PFS oan, kies in DH-groep dy't de tunnel stipet, en hâld de foarstellige koart genôch dat in misferstân dúdlik is. In ASA-peer op Cloud VPN betsjut ek statyske routing, dus de beskerme prefiksen moatte pland en list wurde ynstee fan oan BGP oerlitten.

In libbensdoer kopiearre út 'e sjabloan fan in oare leveransier is hjir de gewoane ferkearde draai. Google publisearret dizze wearden as ferplichte peer-ynstellings, dus set se; in koartere wearde wurdt net opûnderhannele oant wat de ASA wol.

Wiskje, meitsje opnij en skjinje de âlde tastân

Wiskje de tunnel, net de gateway, en notearje de namme dy't Cloud VPN oan 'e ferfanging jout, want nammen wurde tawiisd en net werbrûkt. Meitsje him opnij mei de fêstleine wearden en itselde peer-adres, en foegje dan it oerienkommende foarstel ta oan 'e beliedslist fan 'e ASA.

Skjinje de befeiligingsassosjaasjes nei de ASA-feroaring en foardat jo it resultaat lêze. In ASA kin in ferâldere belied bliuwe biede oant de hjoeddeiske SA ferrint, dus in korrekte konfiguraasje liket stikken foar de hiele âlde libbensdoer en de waarnimmer konkludearret dat de weropbou mislearre doe't er noch net begûn wie:

clear crypto ikev2 sa
clear crypto ipsec sa

Befêstigje dat faze 1 omheech komt foardat jo nei faze 2 sjogge. Wylst faze 1 del is, is it foarstel of de pre-shared key ferkeard, en selektorwurk sil dat net feroarje.

Selektors spegelje, dan beslisse tels

Faze 2 wurket allinnich as beide einen it iens binne oer de beskerme adressen, en de iensidigens is spegele, net dield. De lokale selektor fan Google moat lykje mei de selektor dy't de ASA fier neamt, en de fiere selektor fan Google mei wat de ASA lokaal neamt. In tunnel mei 0.0.0.0/0 oan ien kant en ien subnet oan 'e oare kant hellet faze 1 en mislearret dan faze 2 mei deselde haadflater. Gjin kant kin de list fan 'e oare ferbrede.

Foar beliedsbasearre selektors, list elk prefikspaar en hâld de list yn 'e kaart. In subnet dat letter op it plak tafoege wurdt, freget bewurking oan beide kanten, want in nije route op 'e ASA ferbreedt gjin selektor, en it resultaat is in tunnel dy't omheech is en allinnich ferkear trochlit foar de prefiksen dy't op dei ien bestiene.

Einigje mei ien host-nei-host-stroom en lês byttellers oan beide kanten. Tels dy't op 'e ASA klimme en op Google flak bliuwe, betsjutte meast dat it antwurd troch in oare interface fuortgiet, of dat de selektor it weromprefiks net dekt. Notearje de algoritmes, libbensdoeren, selektors en de nije tunnelnamme, want de folgjende foarstelferoaring werhellet dizze weropbou en dy wearden meitsje der in koarte taak fan.