Google HA VPN uz Cisco maršrutētāju: vispirms plānojiet pīra resursu
Pirms Cisco maršrutētāja konfigurēšanas nosauciet abas Google saskarnes, pīra resursu, IKEv2 līgumu un katru BGP sesiju, pēc tam izvēlieties vienu pīru vai divus.
Pirmais lēmums HA VPN no Cisco uz Google nav tas, kuru šifrēšanas profilu izmantot, bet gan tas, vai tuneļus pabeigs viena vietējā ierīce vai divas. Google HA VPN vārtejai ir divas saskarnes, un katra gaida atbilstošu pīra tuneli. Tas dod divus tuneļus neatkarīgi no tā, vai jums ir divi maršrutētāji, un atšķirība ir tajā, vai viens barošanas avots vai programmatūras atjauninājums var nogāzt visu projektu.
Lēmums ir viena pīra ierīce vai divas
Izvēlieties izkārtojumu pēc trim nosacījumiem: vai varat pieņemt vietēju atteices punktu, vai ir jāizmanto abas mākoņa saskarnes un cik lielu atkārtotu konverģenci jūsu darba slodzes tolerē. Ja kāds no trim ir stingra prasība, divas pīra ierīces ir godīgā atbilde.
Izlemiet to pirms konsoles atvēršanas, jo atbilde maina to, cik tuneļu un BGP sesiju darba lapai jāapraksta.
Uzrakstiet darba lapu pirms jebkuras komandas
Darba lapā ir piecas rindas, un katrai nepieciešams īpašnieks:
| 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 |
Ārējais pīra resurs ir apraksta jūsu saskarnes Google Cloud iekšienē, un tā izveide nekonfigurē Cisco maršrutētāju. Šī asimetrija pārsteidz cilvēkus, kuri gaida, ka mākoņa konsole būs patiesības avots abiem galiem. Tas ir paziņojums par to, ko Google vajadzētu gaidīt, un maršrutētājam joprojām ir jāatbilst tam. Google pīra vārtejas ceļvedis attiecina šo paziņojumu uz tuneļa, BGP, ugunsmūra un IKE darbu, ko vēl esat parādā.
Ja rindai nav īpašnieka, to aizpildīs tas, kurš pārejas laikā ir dežūrā.
Turiet trīs adreses lomas atsevišķi
Publiskās pīra adreses pārvadā ārējo IPsec apmaiņu. Iekšējais BGP pāris pieder aizsargātajam loģiskajam savienojumam, kas iet tam pāri. Izziņotie LAN un VPC prefiksi apraksta darba slodzes aiz šī savienojuma. Iekšējās VM adreses kopēšana ārējā pīra laukā sajauc pirmās divas lomas, un kļūme izskatās kā sarunu problēma, nevis datu ievades kļūda.
Plānojiet divus atbilstošus pīra tuneļus, pa vienam katrai HA VPN saskarnei. Abu mākoņa saskarņu izmantošana pati par sevi nenovērš vietējo atteices punktu, jo abi tuneļi joprojām var nolaisties uz viena un tā paša korpusa.
Uzrakstiet adreses lomu blakus katrai darba lapas vērtībai. Šis viens ieradums novērš lielāko daļu sajaukšanas.
Pārtulkojiet darba lapu Cisco izdevumā
Sāciet ar atbalstīto pīra dokumentāciju vai jūsu platformai piemērotu Google konfigurācijas veidni, pēc tam saskaņojiet katru vietturi ar darba lapu. Pārbaudiet IKEv2 autentifikāciju, ESP priekšlikumus, PFS un tuneļa un maršrutēšanas modeli kopā, jo neatbilstība vienā no tiem parasti izpaužas kā neatbilstība citā. Izmantojiet faktisko platformu un programmatūras izdevumu, lai izvēlētos, kas tiek atbalstīts, jo Classic VPN recepte ir cits sākumpunkts.
Turiet koplietoto noslēpumu ārpus ekrānuzņēmumiem, biļešu pielikumiem un atbalsta piezīmēm. Iepriekš koplietota atslēga, kas ielīmēta lietas komentārā, ir akreditācijas datu atklāšana, nevis problēmu novēršanas artefakts.
Ja veidne un darba lapa nesakrīt, apstājieties un atrisiniet to uz papīra. Ierīce nešķīrs jūsu vietā.
Pieņemiet katru tuneli pēc tā paša pierādījumiem
HA VPN nepieciešamas BGP sesijas, un veiksmīgas IKE sarunas nosaka tikai pirmo posmu. Iekšējai sesijai jāceļas, paredzētie prefiksi jāizziņo un jāpieņem, un pirms darba slodzes trafika kustības jābūt derīgiem maršrutiem un ugunsmūra atļaujām. To reģistrēšana kā vienu zaļu gaismu slēpj to, kurš posms patiesībā neizdevās.
Reģistrējiet pieņemšanas pierādījumus katram tunelim: pārrunātās drošības asociācijas, BGP kaimiņa stāvokli, gaidītos apgūtos prefiksus un paredzēto darba slodzes ceļu. Pēc tam veiciet kontrolētu kļūmes un atjaunošanas pārbaudi, jo tunelis, kas nekad nav sabojājies, ir tunelis, kura atjaunošanas ceļš nav pārbaudīts.
Šis ieraksts ir atkārtoti lietojams nākamajā reizē, kad mainīsies projekts, un tā ir atšķirība starp savstarpēju sadarbspēju un komandas fragmentu, kura pieņēmumi tika zaudēti.