Google HA VPN മുതൽ Cisco റൗട്ടർ വരെ: ആദ്യം പിയർ റിസോഴ്സ് ആസൂത്രണം ചെയ്യുക
Cisco റൗട്ടർ കോൺഫിഗർ ചെയ്യുന്നതിന് മുമ്പ് രണ്ട് Google ഇന്റർഫേസുകൾ, പിയർ റിസോഴ്സ്, IKEv2 കരാർ, ഓരോ BGP സെഷനും പേരിടുക, തുടർന്ന് ഒരു പിയർ അല്ലെങ്കിൽ രണ്ടെണ്ണം തിരഞ്ഞെടുക്കുക.
Cisco-യിൽ നിന്ന് Google-ലേക്കുള്ള HA VPN-ൽ ആദ്യ തീരുമാനം ഏത് ക്രിപ്റ്റോ പ്രൊഫൈൽ ഉപയോഗിക്കണം എന്നതല്ല, മറിച്ച് ഒരു പ്രാദേശിക ഉപകരണമോ രണ്ടോ ടണലുകൾ അവസാനിപ്പിക്കുമെന്നതാണ്. Google-ന്റെ HA VPN ഗേറ്റ്വേയ്ക്ക് രണ്ട് ഇന്റർഫേസുകളുണ്ട്, ഓരോന്നും അനുബന്ധ പിയർ ടണൽ പ്രതീക്ഷിക്കുന്നു. ഇത് നിങ്ങൾക്ക് രണ്ട് റൗട്ടറുകൾ ഉണ്ടായാലും ഇല്ലെങ്കിലും രണ്ട് ടണലുകൾ നൽകുന്നു, വ്യത്യാസം ഒരു വൈദ്യുതി വിതരണമോ സോഫ്റ്റ്വേർ അപ്ഗ്രേഡോ മുഴുവൻ രൂപകൽപ്പനയും വീഴ്ത്തുമോ എന്നതാണ്.
തീരുമാനം ഒരു പിയർ ഉപകരണമോ രണ്ടോ എന്നതാണ്
മൂന്ന് വ്യവസ്ഥകളുടെ അടിസ്ഥാനത്തിൽ ലേഔട്ട് തിരഞ്ഞെടുക്കുക: പ്രാദേശിക പരാജയ പോയിന്റ് സ്വീകരിക്കാമോ, രണ്ട് ക്ലൗഡ് ഇന്റർഫേസുകളും ഉപയോഗിക്കണമോ, നിങ്ങളുടെ വർക്ക്ലോഡുകൾ എത്ര പുനഃസംഗമം സഹിക്കുന്നു. മൂന്നിൽ ഏതെങ്കിലും കർശനമായ ആവശ്യകതയാണെങ്കിൽ, രണ്ട് പിയർ ഉപകരണങ്ങളാണ് സത്യസന്ധമായ ഉത്തരം.
കൺസോൾ തുറക്കുന്നതിന് മുമ്പ് അത് തീരുമാനിക്കുക, കാരണം ഉത്തരം വർക്ക്ഷീറ്റ് എത്ര ടണലുകളും BGP സെഷനുകളും വിവരിക്കണം എന്നത് മാറ്റുന്നു.
ഏതെങ്കിലും കമാൻഡിന് മുമ്പ് വർക്ക്ഷീറ്റ് എഴുതുക
വർക്ക്ഷീറ്റിൽ അഞ്ച് വരികളുണ്ട്, ഓരോന്നിനും ഉടമ ആവശ്യമാണ്:
| 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 |
ബാഹ്യ പിയർ റിസോഴ്സ് Google Cloud-നുള്ളിലെ നിങ്ങളുടെ ഇന്റർഫേസുകൾ വിവരിക്കുന്നു, അത് സൃഷ്ടിക്കുന്നത് Cisco റൗട്ടർ കോൺഫിഗർ ചെയ്യുന്നില്ല. ഈ അസമമിതി, ക്ലൗഡ് കൺസോൾ രണ്ട് അറ്റങ്ങൾക്കും സത്യത്തിന്റെ ഉറവിടമാകുമെന്ന് പ്രതീക്ഷിക്കുന്നവരെ അത്ഭുതപ്പെടുത്തുന്നു. ഇത് Google എന്ത് പ്രതീക്ഷിക്കണം എന്നതിനെക്കുറിച്ചുള്ള ഒരു പ്രഖ്യാപനമാണ്, റൗട്ടർ ഇപ്പോഴും അതിനോട് പൊരുത്തപ്പെടണം. Google-ന്റെ പിയർ ഗേറ്റ്വേ ഗൈഡ് ആ പ്രഖ്യാപനത്തെ നിങ്ങൾ ഇപ്പോഴും കടപ്പെട്ടിരിക്കുന്ന ടണൽ, BGP, ഫയർവാൾ, IKE ജോലിയിലേക്ക് മാപ്പ് ചെയ്യുന്നു.
ഒരു വരിക്ക് ഉടമയില്ലെങ്കിൽ, മാറ്റത്തിനിടയിൽ ഡ്യൂട്ടിയിലുള്ളയാൾ അത് പൂരിപ്പിക്കും.
മൂന്ന് വിലാസ റോളുകൾ വേർതിരിച്ച് നിർത്തുക
പൊതു പിയർ വിലാസങ്ങൾ ബാഹ്യ IPsec കൈമാറ്റം വഹിക്കുന്നു. ആന്തരിക BGP ജോഡി അതിന് മുകളിലൂടെ പോകുന്ന സംരക്ഷിത ലോജിക്കൽ കണക്ഷനിൽ ഉൾപ്പെടുന്നു. പ്രഖ്യാപിത LAN, VPC പ്രിഫിക്സുകൾ ആ കണക്ഷന് പിന്നിലെ വർക്ക്ലോഡുകൾ വിവരിക്കുന്നു. VM-ന്റെ ആന്തരിക വിലാസം ബാഹ്യ പിയർ ഫീൽഡിലേക്ക് പകർത്തുന്നത് ആദ്യ രണ്ട് റോളുകളെ കലർത്തുന്നു, പരാജയം ഡാറ്റ എൻട്രി പിശകിനെക്കാൾ ഒരു ചർച്ചാ പ്രശ്നം പോലെ തോന്നുന്നു.
ഓരോ HA VPN ഇന്റർഫേസിനും ഒന്ന് വീതം രണ്ട് അനുബന്ധ പിയർ ടണലുകൾ ആസൂത്രണം ചെയ്യുക. രണ്ട് ക്ലൗഡ് ഇന്റർഫേസുകളും ഉപയോഗിക്കുന്നത് പ്രാദേശിക പരാജയ പോയിന്റ് സ്വയം ഒഴിവാക്കുന്നില്ല, കാരണം രണ്ട് ടണലുകളും ഇപ്പോഴും ഒരേ ചാസിസിൽ ഇറങ്ങാം.
വർക്ക്ഷീറ്റിലെ ഓരോ മൂല്യത്തിനും അടുത്ത് വിലാസ റോൾ എഴുതുക. ആ ഒരു ശീലം മിക്ക കലർപ്പും തടയുന്നു.
വർക്ക്ഷീറ്റ് Cisco പതിപ്പിലേക്ക് വിവർത്തനം ചെയ്യുക
പിന്തുണയുള്ള പിയർ ഡോക്യുമെന്റേഷനിൽ നിന്നോ നിങ്ങളുടെ പ്ലാറ്റ്ഫോമിന് അനുയോജ്യമായ Google കോൺഫിഗറേഷൻ ടെംപ്ലേറ്റിൽ നിന്നോ തുടങ്ങുക, തുടർന്ന് ഓരോ പ്ലേസ്ഹോൾഡറും വർക്ക്ഷീറ്റുമായി ഒത്തുനോക്കുക. IKEv2 പ്രമാണീകരണം, ESP നിർദ്ദേശങ്ങൾ, PFS, ടണൽ, റൂട്ടിംഗ് മോഡൽ എന്നിവ ഒരുമിച്ച് പരിശോധിക്കുക, കാരണം അവയിലൊന്നിലെ പൊരുത്തക്കേട് സാധാരണയായി മറ്റൊന്നിലെ പൊരുത്തക്കേടായി പ്രത്യക്ഷപ്പെടുന്നു. എന്താണ് പിന്തുണയ്ക്കുന്നത് എന്ന് തിരഞ്ഞെടുക്കാൻ യഥാർത്ഥ പ്ലാറ്റ്ഫോമും സോഫ്റ്റ്വേർ പതിപ്പും ഉപയോഗിക്കുക, കാരണം Classic VPN പാചകക്കുറിപ്പ് മറ്റൊരു ആരംഭ പോയിന്റാണ്.
പങ്കിട്ട രഹസ്യം സ്ക്രീൻഷോട്ടുകൾ, ടിക്കറ്റ് അറ്റാച്ച്മെന്റുകൾ, പിന്തുണാ കുറിപ്പുകൾ എന്നിവയിൽ നിന്ന് അകറ്റി നിർത്തുക. ഒരു കേസ് കമന്റിൽ ഒട്ടിച്ച മുൻകൂട്ടി പങ്കിട്ട കീ ക്രെഡൻഷ്യലുകളുടെ വെളിപ്പെടുത്തലാണ്, പ്രശ്നപരിഹാര കലാസൃഷ്ടിയല്ല.
ടെംപ്ലേറ്റും വർക്ക്ഷീറ്റും യോജിക്കുന്നില്ലെങ്കിൽ, നിർത്തി അത് പേപ്പറിൽ പരിഹരിക്കുക. ഉപകരണം നിങ്ങൾക്കുവേണ്ടി തീരുമാനിക്കില്ല.
ഓരോ ടണലും അതിന്റെ സ്വന്തം തെളിവുകളിൽ സ്വീകരിക്കുക
HA VPN-ന് BGP സെഷനുകൾ ആവശ്യമാണ്, വിജയകരമായ IKE ചർച്ച ആദ്യ ഘട്ടം മാത്രം സ്ഥാപിക്കുന്നു. ആന്തരിക സെഷൻ ഉയരണം, ഉദ്ദേശിച്ച പ്രിഫിക്സുകൾ പ്രഖ്യാപിച്ച് സ്വീകരിക്കണം, വർക്ക്ലോഡ് ട്രാഫിക് നീങ്ങുന്നതിന് മുമ്പ് ഉപയോഗപ്രദമായ റൂട്ടുകളും ഫയർവാൾ അനുമതികളും നിലവിലുണ്ടാകണം. അവയെ ഒരൊറ്റ പച്ച വെളിച്ചമായി രേഖപ്പെടുത്തുന്നത് ഏത് ഘട്ടമാണ് യഥാർത്ഥത്തിൽ പരാജയപ്പെട്ടത് എന്ന് മറയ്ക്കുന്നു.
ഓരോ ടണലിനും സ്വീകരണ തെളിവുകൾ രേഖപ്പെടുത്തുക: ചർച്ച ചെയ്ത സുരക്ഷാ അസോസിയേഷനുകൾ, BGP അയൽക്കാരന്റെ അവസ്ഥ, പ്രതീക്ഷിച്ച പഠിച്ച പ്രിഫിക്സുകൾ, ഉദ്ദേശിച്ച വർക്ക്ലോഡ് പാത. തുടർന്ന് നിയന്ത്രിത പരാജയവും വീണ്ടെടുക്കലും പരിശോധന നടത്തുക, കാരണം ഒരിക്കലും പരാജയപ്പെടാത്ത ടണൽ അതിന്റെ വീണ്ടെടുക്കൽ പാത പരീക്ഷിക്കാത്ത ടണലാണ്.
ആ രേഖ അടുത്ത തവണ രൂപകൽപ്പന മാറുമ്പോൾ വീണ്ടും ഉപയോഗിക്കാം, അത് പരസ്പര പ്രവർത്തനവും അനുമാനങ്ങൾ നഷ്ടപ്പെട്ട ഒരു കമാൻഡ് ശകലവും തമ്മിലുള്ള വ്യത്യാസമാണ്.