Cloud Run മുതൽ ഓൺ-പ്രിമൈസസ് VPN വരെ: Direct VPC egress സജ്ജീകരണം

Cloud VPN ടണൽ Cloud Run-നെ നെറ്റ്‌വർക്കിൽ ഇടുന്നില്ല. സേവനം ശരിയായ സബ്‌നെറ്റിലേക്ക് ബന്ധിപ്പിക്കുക, അതിന്റെ ഉറവിട ശ്രേണി റൂട്ട് ചെയ്യുക, തുടർന്ന് ആ റിവിഷൻ പരിശോധിക്കുക.

ടണൽ പ്രവർത്തിക്കുന്നു, ഒരു VM ഓൺ-പ്രിമൈസസ് സെർവറിലെത്തുന്നു, എന്നാൽ അതേ ഹോസ്റ്റിൽ Cloud Run സേവനം സമയം കഴിഞ്ഞ് പോകുന്നു. ഈ ജോലിയുടെ സാധാരണ തുടക്കമാണിത്, ടണൽ തന്നെയാണ് തെറ്റെന്ന് വരുന്നത് അപൂർവമാണ്. Cloud Run റിവിഷൻ സ്വതവേ നിങ്ങളുടെ VPC-യിൽ ഇരിക്കുന്നില്ല, ഇരുന്നാൽ അത് നിങ്ങൾ ഇതിനകം റൂട്ട് ചെയ്ത VM സബ്‌നെറ്റിന് പകരം സ്വന്തം ഉറവിട വിലാസങ്ങൾ ഉപയോഗിക്കുന്നു. താഴെയുള്ള റൺബുക്ക് സേവനം ബന്ധിപ്പിക്കുന്നു, അതിന്റെ യഥാർത്ഥ ഉറവിട ശ്രേണി റൂട്ട് ചെയ്യുന്നു, തുടർന്ന് അഭ്യർത്ഥന നിർവഹിച്ച റിവിഷനിൽ നിന്ന് പാത തെളിയിക്കുന്നു. അതേ ക്രമത്തിൽ പ്രവർത്തിപ്പിക്കുക, കാരണം ആദ്യ ഘട്ടം ഒഴിവാക്കുന്നതാണ് ഇത്തരം പല കേസുകളും ഒന്നും ശരിയാക്കാത്ത VPN മാറ്റത്തിൽ അവസാനിക്കുന്നതിന്റെ കാരണം.

ടണൽ ഡീബഗ് ചെയ്യുന്നതിന് മുമ്പ് റിവിഷൻ ബന്ധിപ്പിക്കുക

Cloud Run പിന്തുണയ്ക്കുന്നു Direct VPC egress, ഇത് Serverless VPC Access കണക്ടർ ഇല്ലാതെ സേവനത്തിന്റെ ട്രാഫിക് നിങ്ങളുടെ VPC-യിലെ ഒരു സബ്‌നെറ്റിൽ ഇടുന്നു. നിലവിലുള്ള സേവനത്തിന് അപ്‌ഡേറ്റ് ഇങ്ങനെ കാണാം:

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

പ്ലേസ്‌ഹോൾഡറുകൾ മാറ്റുക, വിന്യാസം ലൈവ് ട്രാഫിക്കിനോട് എന്ത് ചെയ്യുന്നുവെന്ന് പരിശോധിക്കുക, സേവനത്തിന്റെ പ്രദേശത്ത് മതിയായ വിലാസ ശേഷിയും ശരിയായ നെറ്റ്‌വർക്ക് അനുമതികളുമുള്ള സബ്‌നെറ്റ് തിരഞ്ഞെടുക്കുക.

ലക്ഷ്യസ്ഥാനത്തിന് യോജിക്കുന്ന egress മോഡ് തിരഞ്ഞെടുക്കുക

private-ranges-only സ്വകാര്യമായി തരംതിരിക്കുന്ന ലക്ഷ്യസ്ഥാനങ്ങൾ VPC വഴി അയയ്ക്കുന്നു. ഇതിന്റെ അർത്ഥം «VPN വഴി എത്താവുന്ന എല്ലാം» എന്നല്ല, സെറ്റിംഗ് അങ്ങനെ തരംതിരിക്കാത്ത ശ്രേണിയിൽ ഓൺ-പ്രിമൈസസ് സേവനം ഇരിക്കുമ്പോഴാണ് ആ വിടവ് കാണുന്നത്. ലക്ഷ്യസ്ഥാനം ഉൾപ്പെട്ടിട്ടില്ലെങ്കിൽ, all-traffic രേഖപ്പെടുത്തിയ മറ്റൊരു മോഡാണ്, അത് സേവനത്തിന്റെ പൊതു ആശ്രിതങ്ങൾ ഉൾപ്പെടെ എല്ലാം VPC വഴി അയയ്ക്കുന്നു. ബോധപൂർവം തിരഞ്ഞെടുത്ത് പരിണിതഫലം മാറ്റ രേഖയിൽ എഴുതുക.

ഇതിനകം കണക്ടർ ഉപയോഗിക്കുന്ന സേവനത്തിന് ടോഗിൾ അല്ല, മൈഗ്രേഷൻ വേണം, അതിനാൽ രണ്ടും കോൺഫിഗർ ചെയ്യുന്നതിന് പകരം അത് ആസൂത്രണം ചെയ്യുക.

VM ഉറവിടമല്ല, Cloud Run ഉറവിടം റൂട്ട് ചെയ്യുക

Direct VPC egress തിരഞ്ഞെടുത്ത സബ്‌നെറ്റിൽ നിന്ന് താൽക്കാലിക വിലാസങ്ങൾ അനുവദിക്കുന്നു, ഓൺ-പ്രിമൈസസ് വശം ട്രാഫിക് ആ ശ്രേണിയിലേക്ക് തിരികെ അയയ്ക്കണം. മറ്റൊരു VM സബ്‌നെറ്റിനായി എഴുതിയ റിട്ടേൺ റൂട്ട് അല്ലെങ്കിൽ ഫയർവാൾ അനുമതി ഡയഗ്രാമിൽ ശരിയായി കാണും, പ്രായോഗികത്തിൽ പരാജയപ്പെടും. സബ്‌നെറ്റ് CIDR ഓർമ്മയിൽ നിന്നല്ല, VPC-യിൽ നിന്ന് എടുക്കുക, തുടർന്ന് റിമോട്ട് ഉപകരണത്തിന്റെ ക്രിപ്റ്റോ ACL അല്ലെങ്കിൽ റൂട്ട് പട്ടിക അത് ഉൾക്കൊള്ളുന്നുവെന്ന് ഉറപ്പാക്കുക.

ഡൈനാമിക് റൂട്ടിംഗിനൊപ്പം, Cloud Router യഥാർത്ഥത്തിൽ എന്ത് പ്രഖ്യാപിക്കുന്നു, VPC എന്ത് ഇറക്കുമതി ചെയ്യുന്നു എന്നിവ ഏതെങ്കിലും ഇഷ്ടാനുസൃത പ്രഖ്യാപന നയം ഉൾപ്പെടെ പരിശോധിക്കുക. കൺസോളിൽ ഉണ്ടെങ്കിലും ഈ ലക്ഷ്യസ്ഥാനത്തിന് തിരഞ്ഞെടുക്കാത്ത റൂട്ട് റൂട്ട് ഇല്ലാത്തതിന് തുല്യമാണ്.

എല്ലാം ഉണ്ടായിരിക്കേണ്ട മൂന്ന് വ്യവസ്ഥകൾ

പ്രവർത്തിക്കുന്ന പാതയ്ക്ക് താഴെയുള്ള എല്ലാം വേണം, ഓരോന്നും അതിന്റേതായ രീതിയിൽ പരാജയപ്പെടുന്നു:

  • VPC-യിൽ ഉദ്ദേശിച്ച Cloud VPN കണക്ഷനിലൂടെ ഓൺ-പ്രിമൈസസ് പ്രിഫിക്സിലേക്കുള്ള ഒരു റൂട്ട്.
  • Cloud Run സബ്‌നെറ്റിനായി ഓൺ-പ്രിമൈസസ് വശത്ത് ഒരു റിവേഴ്സ് റൂട്ട്.
  • ഉറവിടം, ലക്ഷ്യം, പോർട്ട് എന്നിവ അനുവദിക്കുന്ന ഫയർവാൾ, IPsec സംരക്ഷണ പരിധി.

കാണാത്ത റൂട്ട് സാധാരണയായി റിമോട്ട് വശത്ത് തെളിവില്ലാതെ സമയം കഴിയുന്നതുപോലെ കാണപ്പെടുന്നു. റിവേഴ്സ് റൂട്ട് പ്രശ്നം അഭ്യർത്ഥന വന്ന് മറുപടി അപ്രത്യക്ഷമാകുന്നതുപോലെ കാണപ്പെടുന്നു. ഫയർവാൾ അല്ലെങ്കിൽ സെലക്ടർ പ്രശ്നം ഉപകരണത്തെ ആശ്രയിച്ച് നിരസിക്കലോ നിശ്ശബ്ദ വീഴ്ചയോ ആയി കാണാം. മൂന്നിൽ ഏതാണ് നിങ്ങളുടേതെന്ന് കണ്ടെത്തുന്നത് അടുത്ത കമാൻഡ് ഏറെ ചുരുക്കുന്നു.

ഒരു താൽക്കാലിക Cloud Run വിലാസം പോലും അനുവദിച്ച പട്ടികയിൽ ചേർക്കരുത്. സബ്‌നെറ്റ് ശ്രേണിയും ആപ്ലിക്കേഷന് യോജിക്കുന്ന അധികാര രൂപകൽപ്പനയും ഉപയോഗിക്കുക.

അഭ്യർത്ഥന നിർവഹിച്ച റിവിഷൻ പരിശോധിക്കുക

പരിശോധിക്കുന്നതിന് മുമ്പ് വിന്യസിച്ച നെറ്റ്‌വർക്ക് ക്രമീകരണങ്ങളും ട്രാഫിക് വിഭജനവും പരിശോധിക്കുക, കാരണം അപ്‌ഡേറ്റ് പുതിയ റിവിഷൻ സൃഷ്ടിച്ചേക്കാം, അഭ്യർത്ഥനകൾ ഇപ്പോഴും പഴയതിലെത്തുന്നു. തുടർന്ന് ഉപയോക്തൃ അഭ്യർത്ഥന ചെയ്യുന്ന അതേ പ്രവർത്തനം അതേ റിവിഷനിൽ നിന്ന് ചെയ്യുക. ലക്ഷ്യം സ്വകാര്യ ഹോസ്റ്റ്നെയിമാണെങ്കിൽ, ആ പരിസ്ഥിതിയിലെ അതിന്റെ പരിഹാരവും അത് ഉണ്ടാക്കിയ വിലാസവും പരിശോധിക്കുക, കാരണം നിങ്ങളുടെ ലാപ്‌ടോപ്പിലെ കോർപ്പറേറ്റ് DNS ഉത്തരം സേവനത്തിന്റെ നാമമേഖലയെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. TLS ഹോസ്റ്റ്നെയിം പരിശോധനയും റിമോട്ട് ആപ്ലിക്കേഷന്റെ സ്വന്തം പ്രാമാണീകരണവും നിലനിർത്തുക.

Direct VPC-യുടെ രേഖപ്പെടുത്തിയ സ്റ്റാർട്ടപ്പ് കണക്ഷൻ കാലതാമസങ്ങൾ പ്രതീക്ഷിക്കുക, ഓരോ കോൾഡ് സ്റ്റാർട്ടും തകർന്ന ടണലായി രോഗനിർണയം ചെയ്യുന്നതിന് പകരം ക്ലയന്റിന് തയ്യാറെടുപ്പോ വീണ്ടും ശ്രമിക്കാനുള്ള തന്ത്രമോ നൽകുക.

റോൾബാക്കും ഇത് ചെയ്യാത്തതും

റോൾബാക്ക് ചെയ്യാൻ, സേവനത്തിന്റെ നെറ്റ്‌വർക്ക്, egress ക്രമീകരണങ്ങൾ മുൻ മൂല്യങ്ങളിലേക്ക് തിരികെ കൊണ്ടുവരികയും മുൻ റിവിഷൻ ഇപ്പോഴും ട്രാഫിക് നിർവഹിക്കുന്നുവെന്ന് ഉറപ്പാക്കുകയും ചെയ്യുക. മാറ്റ രേഖയിൽ gcloud കമാൻഡ് സൂക്ഷിക്കുക, കാരണം ഭാഗിക മാറ്റത്തിന്റെ വിപരീതം ആറ് ആഴ്ച കഴിഞ്ഞ് വ്യക്തമല്ല. VPC ബന്ധം നീക്കുന്നത് സേവനത്തെ അതിന്റെ മുൻ egress പാതയിലേക്ക് മടക്കുന്നു, സംഭവവേളയിൽ അതാണ് നിങ്ങൾക്ക് വേണ്ടതെന്നും വരാം.

ഈ രൂപകൽപ്പന Cloud Run ആരംഭിക്കുന്ന കണക്ഷനുകളും അവയുടെ മറുപടികളും ഉൾക്കൊള്ളുന്നു. ഇത് ഓൺ-പ്രിമൈസസ് നെറ്റ്‌വർക്കിന് സേവനത്തിനുള്ളിൽ വിലാസയോഗ്യമായ സോക്കറ്റ് നൽകുന്നില്ല, കാരണം അകത്തേക്കുള്ള വെളിപ്പെടുത്തൽ ingress തീരുമാനമാണ്.

അനുബന്ധ ലേഖനങ്ങൾ