Google HA VPN papunta sa Cisco router: planuhin muna ang peer resource
Pangalanan ang dalawang interface ng Google, ang peer resource, ang IKEv2 na kasunduan at bawat BGP session bago i-configure ang Cisco router, pagkatapos pumili ng isang peer o dalawa.
Ang unang desisyon sa isang HA VPN mula Cisco patungong Google ay hindi kung aling crypto profile ang gagamitin, kundi kung isang on-premises na device o dalawa ang magtatapos sa mga tunnel. Ang HA VPN gateway ng Google ay may dalawang interface, at bawat isa ay umaasa ng katumbas na peer tunnel. Nagbibigay ito sa iyo ng dalawang tunnel mayroon man o wala kang dalawang router, at ang pagkakaiba ay kung ang isang power supply o software upgrade ay maaaring magpabagsak sa buong disenyo.
Ang desisyon ay isang peer device o dalawa
Piliin ang layout mula sa tatlong kondisyon: kung matatanggap mo ang isang lokal na failure point, kung dapat gamitin ang parehong cloud interface, at kung gaano karaming reconvergence ang kaya ng iyong workloads. Kung ang alinman sa tatlo ay isang mahigpit na kinakailangan, dalawang peer device ang tapat na sagot.
Pagpasyahan iyon bago mo buksan ang isang console, dahil binabago ng sagot kung gaano karaming tunnel at BGP session ang dapat ilarawan ng worksheet.
Isulat ang worksheet bago ang anumang command
Ang worksheet ay may limang row, at bawat isa ay nangangailangan ng may-ari:
| Row | What it records |
|---|---|
| Google side | Project, VPC, region, HA VPN gateway, and the external address of each interface |
| Peer side | The Cisco external addresses, plus the external peer VPN gateway resource that represents them |
| Tunnel pairs | Which peer interface maps to each Google interface, with IKE version, secret and crypto parameters |
| Routing | Cloud Router, local and remote AS numbers, and one inside BGP pair per tunnel |
| Workloads | Approved on-premises and VPC prefixes, and what firewall policy should permit between them |
Inilalarawan ng external peer resource ang iyong mga interface sa loob ng Google Cloud, at ang paggawa nito ay hindi nagko-configure ng Cisco router. Nakakagulat ang kawalan ng simetrya na ito sa mga umaasang ang cloud console ang magiging pinagmumulan ng katotohanan para sa dalawang dulo. Isa itong deklarasyon ng dapat asahan ng Google, at kailangan pa ring tumugma ng router dito. Ang gabay sa peer gateway ng Google ay nag-uugnay ng deklarasyong iyon sa trabahong tunnel, BGP, firewall at IKE na utang pa sa iyo.
Kung ang isang row ay walang may-ari, ito ay pupunan ng sinumang naka-shift sa panahon ng cutover.
Panatilihing hiwalay ang tatlong papel ng address
Dinadala ng mga pampublikong peer address ang panlabas na IPsec exchange. Ang panloob na BGP pair ay kabilang sa protektadong lohikal na koneksyon na tumatakbo sa ibabaw nito. Inilalarawan ng mga inanunsyong LAN at VPC prefix ang mga workload sa likod ng koneksyong iyon. Ang pagkopya ng panloob na address ng VM sa field ng external peer ay naghahalo sa unang dalawang papel, at ang failure ay mukhang problema sa negosasyon kaysa error sa pagpasok ng data.
Magplano ng dalawang katumbas na peer tunnel, isa para sa bawat HA VPN interface. Ang paggamit ng parehong cloud interface ay hindi nag-aalis ng lokal na failure point nang mag-isa, dahil ang dalawang tunnel ay maaari pa ring mapunta sa parehong chassis.
Isulat ang papel ng address sa tabi ng bawat value sa worksheet. Ang nag-iisang ugali na iyon ay pumipigil sa karamihan ng paghahalo.
Isalin ang worksheet sa Cisco release
Magsimula sa sinusuportahang peer documentation o sa katumbas na Google configuration template para sa iyong platform, pagkatapos ay i-reconcile ang bawat placeholder laban sa worksheet. Suriin nang magkasama ang IKEv2 authentication, ESP proposals, PFS at ang tunnel at routing model, dahil ang mismatch sa isa sa mga ito ay karaniwang lumalabas bilang mismatch sa iba. Gamitin ang aktwal na platform at software release upang piliin ang sinusuportahan, dahil ang Classic VPN recipe ay ibang panimulang punto.
Ilayo ang shared secret mula sa mga screenshot, attachment ng ticket at support notes. Ang pre-shared key na naipaste sa isang case comment ay pagbubunyag ng credential, hindi isang troubleshooting artefact.
Kung hindi magkasundo ang template at ang worksheet, huminto at lutasin ito sa papel. Hindi ka huhusgahan ng device.
Tanggapin ang bawat tunnel sa sarili nitong ebidensya
Kailangan ng HA VPN ang mga BGP session, at ang matagumpay na IKE negotiation ay nagtatatag lamang ng unang yugto. Kailangang bumangon ang panloob na session, kailangang maianunsyo at matanggap ang mga inilalayong prefix, at kailangang may mga kapaki-pakinabang na ruta at pahintulot ng firewall bago gumalaw ang trapiko ng workload. Ang itala ang lahat ng iyon bilang isang berdeng ilaw ay nagtatago kung aling yugto ang talagang nabigo.
Itala ang ebidensya ng pagtanggap sa bawat tunnel: napagkasunduang security association, estado ng BGP neighbor, inaasahang natutunang prefix at ang inilalayong landas ng workload. Pagkatapos ay magpatakbo ng kontroladong pagsusuri ng failure at recovery, dahil ang tunnel na hindi pa nabigo ay tunnel na hindi pa nasubok ang landas ng recovery.
Ang rekord na iyon ay magagamit muli sa susunod na magbago ang disenyo, at iyon ang pagkakaiba ng pagpapatakbo nang magkasama at ng isang piraso ng command na nawala ang mga palagay.