NEGOTIATION_FAILURE në një tunel Cloud VPN me një Cisco ASA në skajin tjetër është pothuajse gjithmonë një mospërputhje propozimi ose selektorësh, dhe fakti i parë i dobishëm është se asnjë redaktim nuk e rregullon. Cloud VPN e fikson propozimin IKE kur krijohet objekti i tunelit. Nuk ka fushë për të ndryshuar një algoritëm në vend, prandaj riparimi është fshirje dhe rikrijim me një pikënisje të shënuar. Trajtojeni si rindërtim dhe puna bëhet listë kontrolli në vend të një pasdite me hamendje.

Lexoni dështimin përpara se të fshini çdo gjë

Një dështim negociimi është problem faze, dhe regjistri i palës tjetër zakonisht e emërton fazën. Dështimi i fazës 1 do të thotë që skajet nuk u morën vesh për një propozim ose nuk mundën të autentikoheshin reciprokisht. Dështimi i fazës 2 do të thotë që tuneli u ngrit dhe selektorët e mbrojtur nuk përputheshin. Këto janë riparime të ndryshme, dhe rreshti i regjistrit ia vlen të nxirret përpara se dikush të prekë një konfigurim.

Dështimi gjithashtu përjashton gjëra. Nuk është rrugë VPC, nuk është rregull firewalls në ndërfaqen e tunelit dhe nuk është defekt i zgjidhjes së emrave brenda rrjetit. Ndjekja e tyre prodhon ndryshime të sigurta në vetvete që nuk mund ta ndryshojnë rezultatin, dhe e bëjnë rregullimin përfundimtar më të vështirë për t'u atribuar.

Kapni të dyja konfigurimet ndërsa ekzistojnë ende

Fshirja e një tuneli zgjat gjysmë minute dhe shkatërron provën e vetme që kishit. Përpara kësaj, shënoni selektorët lokalë dhe të largët, adresën e palës tjetër, kush e zotëron sekretin e përbashkët, dhe crypto map ose profilin IKEv2 të ASA-së. ASA përgjigjet dy pyetjeve të ndara: çfarë është konfiguruar dhe çfarë është ngritur tani:

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

Në anën e Google, lexoni objektin e tunelit në vend të përmbledhjes së konsolës, sepse adresa e palës tjetër dhe fushat e selektorit janë vlerat që duhet t'i riprodhoni saktësisht:

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

Vendosini ato vlera në tiketë përpara fshirjes së parë. Rindërtimi më poshtë funksionon vetëm sepse mund të rikrijoni të njëjtin objekt me një ndryshim të qëllimshëm.

Algoritmet për të cilat njëra palë refuzon të negociojë

Cloud VPN nuk zgjedh nga një gamë algoritmesh IKEv1 si një palë tradicionale. Cilësimet e palës që pret janë fikse: aes-cbc-128 për kriptim, sha1-96 për integritet dhe PRF, grupi Diffie-Hellman 2, 36,600 sekonda për fazën 1 dhe 10,800 sekonda për fazën 2. Politika e ASA-së duhet të ofrojë saktësisht atë grup. Një propozim i dytë në ASA nuk dëmton për sa kohë edhe ai që përputhet është në listë.

IKEv2 u jep më shumë hapësirë të dy palëve, por rregullat mbajnë të njëjtën formë: aktivizoni PFS, zgjidhni një grup DH që tuneli e mbështet dhe mbani listën e propozimeve aq të shkurtër sa mospërputhja të jetë e dukshme. Një palë ASA në Cloud VPN nënkupton edhe rrugëtim statik, prandaj prefikset e mbrojtura duhet të planifikohen dhe të listohen, jo të lihen në dorë të BGP.

Një jetëgjatësi e kopjuar nga modeli i një prodhuesi tjetër është kthesa e gabuar e zakonshme këtu. Google i publikon këto vlera si cilësime të detyrueshme të palës, prandaj vendosini; një vlerë më e shkurtër nuk negociohet lart deri në atë që kërkon ASA.

Fshini, rikrijoni dhe pastroni gjendjen e vjetër

Fshini tunelin, jo gateway-in, dhe shënoni emrin që Cloud VPN i jep zëvendësuesit, sepse emrat caktohen dhe nuk ripërdoren. Rikrijeni me vlerat e shënuara dhe të njëjtën adresë të palës tjetër, pastaj shtoni propozimin që përputhet në listën e politikave të ASA-së.

Pastroni shoqatat e sigurisë pas ndryshimit në ASA dhe përpara se të lexoni rezultatin. Një ASA mund të vazhdojë të ofrojë një politikë të vjetruar derisa SA aktuale të skadojë, prandaj një konfigurim i saktë duket i prishur gjatë gjithë jetëgjatësisë së vjetër dhe vëzhguesi përfundon se rindërtimi dështoi kur ai nuk kishte filluar:

clear crypto ikev2 sa
clear crypto ipsec sa

Konfirmoni se faza 1 ngrihet përpara se të shikoni fazën 2. Ndërsa faza 1 është poshtë, propozimi ose çelësi i ndarë paraprakisht janë të gabuar, dhe puna me selektorët nuk do ta ndryshojë atë.

Selektorët pasqyrohen, pastaj vendosin numëruesit

Faza 2 funksionon vetëm kur të dy skajet merren vesh për adresat e mbrojtura, dhe marrëveshja është pasqyrë, jo e përbashkët. Selektori lokal i Google duhet të përputhet me selektorin që ASA e quan të largët, dhe selektori i largët i Google me atë që ASA e quan lokal. Një tunel me 0.0.0.0/0 në njërën anë dhe një nënrrjetë të vetme në anën tjetër kalon fazën 1 dhe pastaj dështon në fazën 2 me të njëjtin gabim kryesor. Asnjëra palë nuk mund të zgjerojë listën e palës tjetër.

Për selektorët e bazuar në politikë, listoni çdo çift prefiksesh dhe mbani listën në tiketë. Një nënrrjetë e shtuar më vonë në ambientin lokal kërkon redaktim në të dy skajet, sepse një rrugë e re në ASA nuk zgjeron një selektor, dhe rezultati është një tunel që është ngritur dhe kalon trafik vetëm për prefikset që ekzistonin ditën e parë.

Përfundoni me një rrjedhë të vetme host-më-host dhe lexoni numëruesit e bajteve në të dyja anët. Numëruesit që rriten në ASA ndërsa mbeten të sheshtë në Google zakonisht nënkuptojnë se përgjigjja del nga një ndërfaqe tjetër, ose se selektori nuk e mbulon prefiksin e kthimit. Shënoni algoritmet, jetëgjatësitë, selektorët dhe emrin e ri të tunelit, sepse ndryshimi i ardhshëm i propozimit e përsërit këtë rindërtim dhe ato vlera e kthejnë atë në një punë të shkurtër.

Artikuj të ngjashëm