GCP Cloud VPN: ഗേറ്റ്‌വേ, ടണൽ, ഫയർവാൾ എന്നിവ ക്രമത്തിൽ പരിശോധിക്കുക

നിങ്ങളുടെ കൺസോൾ പച്ച ടണൽ കാണിക്കുന്നു, ഓൺ-പ്രെമിസ് മോണിറ്ററിംഗിന് ഇപ്പോഴും ഒരു ഇൻസ്റ്റൻസിൽ പോലും എത്താൻ കഴിയുന്നില്ല, ടണൽ വീണ്ടും നിർമ്മിക്കുന്നതാണ് വ്യക്തമായ പരിഹാരം എന്ന് തോന്നുന്നു. എന്നാൽ അങ്ങനെയാകുന്നത് അപൂർവമാണ്. സ്ഥാപിതമായ ടണൽ രണ്ട് ഗേറ്റ്‌വേകൾ IKE കൈമാറ്റം പൂർത്തിയാക്കിയത് മാത്രം തെളിയിക്കുന്നു. പാക്കറ്റിന് എപ്പോഴെങ്കിലും നിങ്ങളുടെ VPC-യിലേക്ക് പ്രവേശനം ലഭിച്ചിരുന്നോ എന്നതിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല.

ആ പച്ച ഐക്കണും ഒരു മറുപടിയും തമ്മിൽ നാല് തീരുമാനങ്ങളുണ്ട്, അവ പ്രവചനാത്മകമായ ക്രമത്തിൽ പരാജയപ്പെടുന്നു. ഏറ്റവും വിലകുറഞ്ഞതിൽ നിന്ന് തുടങ്ങുക.

മൂന്ന് ഒബ്ജക്റ്റുകൾ, അവയിൽ ഒന്ന് മാത്രം എൻക്രിപ്റ്റ് ചെയ്യുന്നു

VPN ഗേറ്റ്‌വേ നിങ്ങളുടെ പിയർ എൻക്രിപ്റ്റ് ചെയ്യുന്ന ബാഹ്യ വിലാസം കൈവശം വയ്ക്കുന്നു. കൺസോളിൽ നിങ്ങൾ അത് ഒരിക്കലും കൈകൊണ്ട് സൃഷ്ടിക്കുന്നില്ല: കണക്ഷൻ ഫോമിനുള്ളിൽ ഒരു വിലാസം തിരഞ്ഞെടുക്കുകയോ റിസർവ് ചെയ്യുകയോ ചെയ്യുക, ഗേറ്റ്‌വേ അതിനൊപ്പം പ്രത്യക്ഷപ്പെടും. HA ഗേറ്റ്‌വേ രണ്ട് ഇന്റർഫേസുകളിൽ രണ്ട് വിലാസങ്ങൾ എടുക്കുന്നു, ഇത് പിന്നീട് ക്വോട്ട പരിശോധനയിൽ പ്രധാനമാണ്.

ടണൽ ആ ഗേറ്റ്‌വേയും പിയറും തമ്മിലുള്ള ജോടിയാണ്. അത് പങ്കിട്ട രഹസ്യവും സംരക്ഷിക്കുമെന്ന് വാഗ്ദാനം ചെയ്യുന്ന ട്രാഫിക് സെലക്ടർമാരും വഹിക്കുന്നു. ആ സെലക്ടർമാരിലാണ് മിക്ക നിശ്ശബ്ദ പരാജയങ്ങളും തുടങ്ങുന്നത്. പ്രാദേശിക സെലക്ടർ 10.0.0.0/24 ഉൾക്കൊള്ളുന്ന ടണൽ, സ്ഥിതി എത്ര ആരോഗ്യകരമായി തോന്നിയാലും 10.0.1.0/24 എത്തിക്കില്ല.

വിദൂര ഭാഗം സ്വന്തം പട്ടിക സൂക്ഷിക്കുന്നു, സാധാരണയായി അതിനെ എൻക്രിപ്ഷൻ ഡൊമെയ്ൻ എന്ന് വിളിക്കുന്നു, അവസാനിപ്പിക്കുന്ന ഹാർഡ്‌വെയർ അതിനെ നിങ്ങളുടേതുമായി താരതമ്യം ചെയ്യുന്നു. ഒരിക്കലും നൽകിയിട്ടില്ലാത്ത ഒരു സെലക്ടറിനെക്കുറിച്ച് ഒരു ഭാഗവും ചർച്ച ചെയ്യുന്നില്ല.

റൂട്ടിംഗ് തരം റൂട്ട് പട്ടികയിൽ എത്തുന്നത് എന്തെന്ന് നിർണ്ണയിക്കുന്നു

Cloud VPN മൂന്ന് റൂട്ടിംഗ് രൂപങ്ങൾ നൽകുന്നു, അവ വ്യക്തമായി കലരുന്നില്ല. നയാധിഷ്ഠിത റൂട്ടിംഗ് സ്ഥിര സെലക്ടർ ജോടികൾ നിലനിർത്തുന്നു, റൂട്ട് അധിഷ്ഠിത റൂട്ടിംഗ് നിങ്ങൾ തന്നെ സ്ഥിര റൂട്ടുകൾ ചേർക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നു, ഡൈനാമിക് റൂട്ടിംഗ് BGP-യിൽ Cloud Router വഴി പ്രിഫിക്സുകൾ പ്രഖ്യാപിക്കുന്നു. ഉദ്ദേശ്യപൂർവം ഒന്ന് തിരഞ്ഞെടുക്കുക.

സ്ഥിര റൂട്ടുകൾ കൈകൊണ്ട് എഴുതി അരികിൽ വെച്ച ഡൈനാമിക് ടണൽ, BGP സെഷൻ ആടുമ്പോഴെല്ലാം ഒഴിയുന്ന ഒരു റൂട്ട് പട്ടിക സൃഷ്ടിക്കുന്നു.

ടണൽ പുനർനിർമ്മിക്കാതെ സംരക്ഷിത പ്രിഫിക്സുകൾ മാറ്റാൻ അനുവദിക്കുന്ന ഏക രൂപമാണ് ഡൈനാമിക്, അത് നിങ്ങൾ പരിശോധിക്കേണ്ട ഒബ്ജക്റ്റുകളുടെ കൂട്ടത്തിലേക്ക് Cloud Router-നെ വലിച്ചിടുന്നു. പിയർ BGP സംസാരിക്കാൻ കഴിയാത്ത ഹാർഡ്‌വെയർ ഫയർവാൾ ആകുമ്പോൾ സ്ഥിര സെലക്ടർമാർ പ്രായോഗികമായി തുടരും. അപ്പോൾ രണ്ട് അറ്റങ്ങൾക്കും ഒരേ ശ്രേണികൾ വേണം, കൂടുതൽ നിർദ്ദിഷ്ടമായ എൻട്രി രണ്ടിലും വിജയിക്കണം. ഒരു സബ്‌നെറ്റ് വ്യത്യാസമുള്ള ജോഡി സ്ഥാപിതമായി പിന്നീട് നിങ്ങളുടെ പകുതി ട്രാഫിക് വഹിക്കുന്നു.

സൂചിതമായ നിരസിക്കൽ ടണലിന് പിന്നിലാണ്

ഇൻബൗണ്ട് ട്രാഫിക് ഏറ്റവും കുറഞ്ഞ മുൻഗണനയിലുള്ള സൂചിതമായ നിരസിക്കലിനെതിരെ വിലയിരുത്തുന്നു, ആ നിയമം പാക്കറ്റ് എൻക്രിപ്റ്റ് ചെയ്ത് എത്തിയത് ശ്രദ്ധിക്കുന്നില്ല. ഒരു ഫയർവാൾ നിയമം ഓൺ-പ്രെമിസ് ശ്രേണിയും ഉപയോഗത്തിലുള്ള പോർട്ടും പേരിടുന്നതുവരെ പാക്കറ്റ് ഡീക്രിപ്റ്റ് ചെയ്യപ്പെടുകയും പരിശോധിക്കപ്പെടുകയും ഉപേക്ഷിക്കപ്പെടുകയും ചെയ്യുന്നു. VPN ലോഗ് മുഴുവൻ സമയവും വൃത്തിയായി തുടരുന്നു, കാരണം ടണൽ വാഗ്ദാനം ചെയ്തത് കൃത്യമായി ചെയ്തു.

പകരം, ടണൽ പ്രവർത്തിക്കുകയും പ്രോബ് സമയപരിധി കഴിയുകയും ചെയ്യുമ്പോൾ ഫയർവാൾ നിരസിക്കൽ ലോഗ് വായിക്കുക, തുടർന്ന് നിയമം സ്രോതസ്സ് ശ്രേണിയിലേക്കും ആവശ്യമായ പോർട്ടുകളിലേക്കും പരിമിതപ്പെടുത്തുക:

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

ഒരു ദിശ മാത്രം പ്രവർത്തിക്കുന്നത് ഫയർവാളിന്റെ സൂചനയാണ്

ഔട്ട്ബൗണ്ട് ട്രാഫിക് വ്യത്യസ്തമായി പെരുമാറുന്നു, കാരണം സൂചിതമായ അനുമതി നിയമം ഇൻസ്റ്റൻസുകളെ എവിടെയും അയക്കാൻ അനുവദിക്കുന്നു. ഒരു VM-ൽ എത്താൻ കഴിയാത്ത ഡാറ്റാ സെന്റർ പലപ്പോഴും മറ്റേ ദിശയിൽ തികച്ചും പ്രവർത്തിക്കുന്ന ഔട്ട്ബൗണ്ട് പാതയ്ക്ക് പിന്നിലാണ്. ഈ അസമമിതി ഫയർവാൾ വിട്ടുപോകലിനെ റൂട്ടിംഗ് തകരാറിൽ നിന്ന് വേർതിരിക്കുന്നു, കാരണം റൂട്ടിംഗ് തകരാർ രണ്ട് ദിശകളെയും ഒരുമിച്ച് തകർക്കുന്നു. ഒരു നിയമം കൂടി തിരുത്തുന്നതിന് മുൻപ് വിപരീത ദിശ പരീക്ഷിക്കുക.

വിലാസ സൃഷ്ടിയും ഒരു ക്വോട്ട പ്രവർത്തനമാണ്. ഉപയോഗത്തിലുള്ള ബാഹ്യ വിലാസങ്ങളുടെ പരിധിക്ക് അടുത്തുള്ള പ്രോജക്റ്റ്, അനുമതി പരാജയമായി വായിക്കുന്ന ഒരു പിശകോടെ കണക്ഷൻ നിരസിക്കുന്നു.

സെലക്ടർമാർ, ക്വോട്ടകൾ, പിന്നെ നാല് പരിശോധനകൾ

കൺസോളിൽ നിർമ്മിച്ച ടണലുകൾ ചിലപ്പോൾ gcloud compute vpn-tunnels describe-ൽ നിന്ന് ശൂന്യമായ റിമോട്ട് ട്രാഫിക് സെലക്ടർ നൽകുന്നു, അതേസമയം ജനറേറ്റ് ചെയ്ത റൂട്ടുകൾ ട്രാഫിക് ശരിയായി വഹിക്കുന്നു. ടണൽ തെറ്റാണെന്ന് തീരുമാനിക്കുന്നതിന് മുൻപ് API രേഖപ്പെടുത്തുന്നതിനെ നിങ്ങൾ യഥാർത്ഥത്തിൽ സംരക്ഷിക്കുന്ന ശ്രേണികളുമായി താരതമ്യം ചെയ്യുക. API അല്ലെങ്കിൽ SDK വഴി നിർമ്മിക്കുന്നത് സെലക്ടറെ വ്യക്തമായി നിലനിർത്തുന്നു.

ക്വോട്ടകൾ മറ്റൊരു എളുപ്പത്തിൽ വിട്ടുപോകുന്ന കാര്യമാണ്. അറ്റകുറ്റപ്പണി വിൻഡോയ്ക്ക് മുൻപ് വർദ്ധന അഭ്യർത്ഥിക്കുക, അതിനിടയിൽ അല്ല, ഗേറ്റ്‌വേ ഉള്ള അതേ പ്രോജക്റ്റിൽ വിലാസങ്ങളുടെ എണ്ണം പരിശോധിക്കുക.

പുറത്തുനിന്ന് അകത്തേക്ക് പ്രവർത്തിക്കുക: പിയർ നില, രണ്ട് സെലക്ടർ പട്ടികകൾ, ഓരോ വശത്തിനും ഒരു റൂട്ട്, സ്രോതസ്സ് ശ്രേണിക്കും പോർട്ടിനുമുള്ള ഇൻബൗണ്ട് നിയമം, പിന്നെ പാക്കറ്റ് ക്യാപ്ചർ. ടണൽ പുതിയതായിരിക്കുമ്പോൾ തന്നെ ഗേറ്റ്‌വേ വിലാസം, രണ്ട് സെലക്ടർ പട്ടികകൾ, റൂട്ടിംഗ് തരം എന്നിവ മാറ്റ ടിക്കറ്റിൽ എഴുതുക, കാരണം സബ്‌നെറ്റ് ചേർക്കുന്ന അടുത്ത എൻജിനീയർക്ക് മൂന്നും വേണ്ടിവരും.