Ang NEGOTIATION_FAILURE sa isang Cloud VPN tunnel na may Cisco ASA sa kabilang dulo ay halos palaging hindi pagtugma ng panukala o ng mga selector, at ang unang kapaki-pakinabang na katotohanan ay walang anumang pagbabago ang makakapag-ayos nito. Inaayos ng Cloud VPN ang panukalang IKE kapag nilikha ang tunnel object. Walang field para palitan ang algorithm sa lugar, kaya ang pag-aayos ay pagbura at muling paggawa na may naitalang panimulang punto. Ituring itong muling pagtatayo at ang gawain ay magiging checklist sa halip na hapon ng hula.

Basahin ang kabiguan bago burahin ang anuman

Ang kabiguan sa negosasyon ay problema sa yugto, at karaniwang pinapangalanan ng log ng kapares ang yugto. Ang pagpalya ng yugto 1 ay nangangahulugang hindi nagkasundo ang dalawang dulo sa panukala o hindi nila na-verify ang isa't isa. Ang pagpalya ng yugto 2 ay nangangahulugang umangat ang tunnel ngunit hindi tugma ang mga protektadong selector. Magkaibang pag-aayos ang mga ito, at sulit na kunin ang linya sa log bago may humawak sa configuration.

Inaalis din ng kabiguan ang ilang bagay. Hindi ito VPC route, hindi firewall rule sa interface ng tunnel, at hindi error sa paglutas ng pangalan sa loob ng network. Ang paghabol sa mga ito ay lumilikha ng kumpiyansang pagbabago na hindi mababago ang resulta, at pinapahirapan ang pag-uugnay ng huling pag-aayos.

Kunin ang dalawang configuration habang naroon pa

Ang pagbura ng tunnel ay tumatagal ng kalahating minuto at sinisira ang tanging ebidensyang mayroon ka. Bago iyon, isulat ang lokal at malayong selector, address ng kapares, kung kanino ang shared secret, at ang crypto map o IKEv2 profile ng ASA. Sinasagot ng ASA ang dalawang magkaibang tanong: ano ang naka-configure at ano ang nakaangat ngayon:

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

Sa panig ng Google, basahin ang tunnel object sa halip na ang buod sa console, dahil ang address ng kapares at mga field ng selector ang mga halagang kailangan mong kopyahin nang eksakto:

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

Ilagay ang mga halagang iyon sa ticket bago ang unang pagbura. Gumagana lamang ang muling pagtatayo sa ibaba dahil kaya mong muling likhain ang parehong object na may isang sinadyang pagkakaiba.

Ang mga algorithm na ayaw pag-usapan ng isang panig

Hindi pumipili ang Cloud VPN mula sa hanay ng mga algorithm ng IKEv1 tulad ng tradisyonal na kapares. Ang mga setting ng kapares na inaasahan nito ay permanente: aes-cbc-128 para sa encryption, sha1-96 para sa integridad at PRF, grupong Diffie-Hellman 2, 36,600 segundo para sa yugto 1 at 10,800 segundo para sa yugto 2. Dapat ihandog ng patakaran ng ASA ang eksaktong set na iyon. Ang pangalawang panukala sa ASA ay walang pinsala basta naroon din sa listahan ang tugma.

Nagbibigay ang IKEv2 ng mas maraming espasyo sa dalawang panig, ngunit nananatiling pareho ang hugis ng mga patakaran: i-enable ang PFS, pumili ng DH group na sinusuportahan ng tunnel, at panatilihing sapat na maikli ang listahan ng panukala upang halata ang hindi pagtugma. Ang kapares na ASA sa Cloud VPN ay nangangahulugan din ng static routing, kaya ang mga protektadong prefix ay dapat planuhin at ilista sa halip na ipaubaya sa BGP.

Ang tagal na kinopya mula sa template ng ibang vendor ang karaniwang maling liko dito. Inilalathala ng Google ang mga halagang ito bilang kinakailangang setting ng kapares, kaya itakda ang mga ito; ang mas maikling halaga ay hindi nakikipagnegosasyon pataas hanggang sa gusto ng ASA.

Burahin, muling likhain at linisin ang lumang estado

Burahin ang tunnel, hindi ang gateway, at itala ang pangalang ibinibigay ng Cloud VPN sa kapalit, dahil ang mga pangalan ay itinatakda at hindi ginagamit muli. Muling likhain ito gamit ang naitalang halaga at parehong address ng kapares, pagkatapos idagdag ang tugmang panukala sa listahan ng patakaran ng ASA.

Linisin ang mga asosasyon ng seguridad pagkatapos ng pagbabago sa ASA at bago basahin ang resulta. Maaaring patuloy na maghandog ang ASA ng lumang patakaran hanggang sa mag-expire ang kasalukuyang SA, kaya ang tamang configuration ay mukhang sira sa buong tagal ng lumang buhay, at ang nagmamasid ay naghihinuha na nabigo ang muling pagtatayo gayong hindi pa ito nagsisimula:

clear crypto ikev2 sa
clear crypto ipsec sa

Tiyakin na umaangat ang yugto 1 bago tingnan ang yugto 2. Habang nakababa ang yugto 1, mali ang panukala o ang paunang ibinahaging susi, at hindi iyon babaguhin ng gawain sa selector.

Nagmimirror ang mga selector, pagkatapos ang mga counter ang magpapasya

Gumagana lamang ang yugto 2 kapag nagkasundo ang dalawang dulo sa mga protektadong address, at ang kasunduan ay mirror at hindi shared. Dapat tumugma ang lokal na selector ng Google sa selectorn na tinatawag na malayo ng ASA, at ang malayong selector ng Google sa tinatawag na lokal ng ASA. Ang tunnel na may 0.0.0.0/0 sa isang panig at isang subnet sa kabila ay pumapasa sa yugto 1 at pagkatapos ay pumapalya sa yugto 2 na may parehong pangunahing error. Walang panig na makapagpapalawak ng listahan ng kabila.

Para sa mga selectorn na batay sa patakaran, ilista ang bawat pares ng prefix at itago ang listahan sa ticket. Ang subnet na idaragdag mamaya sa lugar ay nangangailangan ng pagbabago sa dalawang dulo, dahil ang bagong ruta sa ASA ay hindi nagpapalawak ng selector, at ang resulta ay tunnel na nakaangat at nagpapadala lamang ng trapiko para sa mga prefix na umiral noong unang araw.

Tapusin sa isang daloy mula host hanggang host at basahin ang mga counter ng byte sa dalawang panig. Ang mga counter na tumataas sa ASA habang patag sa Google ay karaniwang nangangahulugang lumalabas ang sagot sa ibang interface, o hindi sakop ng selector ang pabalik na prefix. Itala ang mga algorithm, tagal, selector at bagong pangalan ng tunnel, dahil inuulit ng susunod na pagbabago ng panukala ang muling pagtatayong ito at ginagawa ng mga halagang iyon na maikling gawain.

Kaugnay na mga artikulo