VPC ലേക്ക് VPN പ്രവർത്തിക്കുന്നു, പക്ഷേ മാനേജുചെയ്ത സേവനം സമയപരിധി കവിയുന്നു
ടണൽ നിങ്ങളുടെ അരികിൽ അവസാനിക്കുന്നു, ദാതാവിന്റെ മുൻവാതിലിൽ അല്ല. റൂട്ട് മാറ്റുന്നതിന് മുമ്പ് ലക്ഷ്യത്തെ VM-ൽ ഹോസ്റ്റ് ചെയ്തത്, VPC-യുമായി ബന്ധിപ്പിച്ചത്, അല്ലെങ്കിൽ പൊതു മാത്രം എന്ന് വർഗ്ഗീകരിക്കുക.
VPN വഴി മാനേജുചെയ്ത ഡാറ്റാബേസ് എത്തിപ്പെടാനുള്ള ശ്രമം സാധാരണയായി പരാജയപ്പെടുന്നത് ആരും റൺബുക്കിൽ എഴുതാത്ത ഒരു കാരണത്താലാണ്: ടണൽ നിങ്ങളുടെ നെറ്റ്വർക്കിന്റെ അരികിൽ അവസാനിക്കുന്നു, എന്നാൽ സേവനം ഒരിക്കലും അതിന്റെ നിങ്ങളുടെ വശത്ത് ഉണ്ടായിരുന്നിട്ടില്ല. റൂട്ട് പട്ടിക ശരിയായി തോന്നുന്നു, ടണൽ സജീവമാണെന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു, എന്നിട്ടും കണക്ഷൻ സമയപരിധി കവിയുന്നു. താഴെയുള്ള നാല് പരിശോധനകൾ ക്രമത്തിൽ നടത്തി വിജയ നിബന്ധന പാലിക്കാത്ത ആദ്യ പരിശോധനയിൽ നിർത്തുക, കാരണം അതിനുശേഷമുള്ള ഓരോ പരിശോധനയും മുൻപുള്ളവ വിജയിച്ചുവെന്ന് സങ്കൽപ്പിക്കുന്നു.
പരിശോധന ഒന്ന്: എൻഡ്പോയിന്റ് യഥാർത്ഥത്തിൽ എവിടെയാണ്?
VPN ഗേറ്റ്വേ നിങ്ങൾ നിയന്ത്രിക്കുന്ന വിലാസമുള്ള രണ്ട് നെറ്റ്വർക്കുകൾ ബന്ധിപ്പിക്കുന്നു. മാനേജുചെയ്ത സേവനം ദാതാവിന്റെ സ്വന്തം മുൻവാതിലിന് പിന്നിൽ പ്രവർത്തിക്കുന്നു, ആ വാതിൽ ഉൽപ്പന്നത്തിനനുസരിച്ച് മൂന്ന് രൂപങ്ങളിൽ ഒന്ന് സ്വീകരിക്കുന്നു. ഏത് രൂപമാണ് കൈകാര്യം ചെയ്യുന്നതെന്ന് അറിയില്ലെങ്കിൽ, ഒരു റൂട്ട് ജോലിയും സഹായിക്കില്ല, കാരണം തകരാർ റൂട്ട് തകരാർ അല്ലായിരിക്കാം.
| Shape | What it means | Pass condition |
|---|---|---|
| Software on your VM | Ordinary subnet addressing | Route and security group permit the client |
| Attached to your VPC | Private, but only inside that VPC | Endpoint associated, source allowed, route present |
| Provider-hosted, public endpoint | Optional private link, not private by default | A private endpoint exists and DNS points at it |
പാഴാക്കുന്ന ഉച്ചയ്ക്കുശേഷങ്ങളിൽ ഭൂരിഭാഗവും ഈ വർഗ്ഗീകരണം ഒഴിവാക്കി നേരിട്ട് റൂട്ട് പട്ടികയിലേക്ക് പോകുന്നതിൽ നിന്നാണ്. പൊതു എൻഡ്പോയിന്റുള്ള ദാതാവ്-ഹോസ്റ്റ് ചെയ്ത സേവനം ഡയഗ്രം എന്ത് പറഞ്ഞാലും നിങ്ങളുടെ ടണലിന് പിന്നിലല്ല, VPC-യുമായി ബന്ധിപ്പിച്ചത് ഒരിക്കലും പൊതു DNS ഉത്തരത്തിൽ പ്രത്യക്ഷപ്പെടുകയുമില്ല.
പരിശോധന രണ്ട്: ElastiCache പോലുള്ള VPC-യുമായി ബന്ധിപ്പിച്ച സേവനം
ആ തരത്തിലുള്ള കാഷുകൾ നിങ്ങളുടെ സ്വന്തം VPC-യ്ക്കുള്ളിൽ വിലാസം നൽകുന്നു, ഇന്റർനെറ്റിന് അഭിമുഖമായ ശ്രോതാവ് അവയ്ക്ക് ഒട്ടുമില്ല. അതേ VPC-യിൽ അവസാനിക്കുന്ന ക്ലയന്റ് VPN അവയിൽ എത്താം, പക്ഷേ മൂന്ന് നിബന്ധനകൾ ഒരുമിച്ച് ഒത്തുചേരുമ്പോൾ മാത്രം. കാഷിന്റെ എൻഡ്പോയിന്റ് നിങ്ങളുടെ ടണലിന് കാണാവുന്ന സബ്നെറ്റുകളുമായി ബന്ധിപ്പിച്ചിരിക്കണം, അതിന്റെ സുരക്ഷാ ഗ്രൂപ്പ് നിങ്ങളുടെ ക്ലയന്റുകൾ വരുന്ന വിലാസം അനുവദിക്കണം, ക്ലയന്റ് വശത്ത് കാഷ് സബ്നെറ്റുകൾ ഉൾക്കൊള്ളുന്ന ഒരു റൂട്ട് വേണം.
സാധാരണ തെറ്റ് അടുത്തെവിടെയെങ്കിലും ഉള്ള ഒരു കണക്ഷനും കണക്കിൽ വരുമെന്ന് കരുതുന്നതാണ്. VPN മറ്റൊരു VPC-യുമായി ബന്ധിപ്പിക്കുന്നതോ peering-ൽ മാത്രം ആശ്രയിക്കുന്നതോ കാഷിന്റെ സുരക്ഷാ ഗ്രൂപ്പോ അതിന്റെ സബ്നെറ്റ് റൂട്ട് പട്ടികയോ നിങ്ങളുടെ ക്ലയന്റുകളിലേക്ക് വ്യാപിപ്പിക്കുന്നില്ല. നിലവിലുള്ള ടണൽ മറ്റെവിടെയോ അവസാനിക്കുമ്പോൾ, ആ VPC-യ്ക്കുള്ളിൽ സ്ഥാപിച്ച ജംപ് ഹോസ്റ്റോ VPN സെർവറോ ആണ് സാധാരണ പകരം വഴി. ആ പകരം വഴി രൂപകൽപ്പനയല്ല, ഒരു വളവാണ്, റൺബുക്കിൽ അത് അങ്ങനെ തന്നെ അടയാളപ്പെടുത്തണം.
പരിശോധന മൂന്ന്: പൊതു പേരുള്ള PaaS എൻഡ്പോയിന്റ്
Azure Database for PostgreSQL ഒരു പൊതു സെർവർ നാമം അവതരിപ്പിക്കുന്നു. hosts ഫയലിൽ പിൻ ചെയ്ത് ഗേറ്റ്വേ വഴി റൂട്ട് ചെയ്യാവുന്ന സ്വകാര്യ വിലാസം അത് നൽകുന്നില്ല. വെർച്വൽ നെറ്റ്വർക്ക് സേവന എൻഡ്പോയിന്റുകൾ ഏത് സബ്നെറ്റുകൾക്ക് ഒരു വിഭവത്തിൽ എത്താമെന്ന് പരിമിതപ്പെടുത്തുന്നു; VPN വഴി വരുന്ന ഓൺ-പ്രെമിസ് ക്ലയന്റിന് അവ അധികാരം നൽകുന്നില്ല.
സ്വകാര്യ ആക്സസ് നേടുക എന്നാൽ സ്വകാര്യ എൻഡ്പോയിന്റോ സ്വകാര്യ ലിങ്ക് രൂപകൽപ്പനയോ കൊണ്ടുവന്ന്, പിന്നീട് പൊതു നാമം ഇന്റർനെറ്റിന് പകരം ആ എൻഡ്പോയിന്റോട് ഉത്തരം നൽകാൻ ഒരു സ്വകാര്യ DNS സോൺ ചേർക്കുക എന്നതാണ്. സേവന എൻഡ്പോയിന്റ് നിയമത്തോടൊപ്പം ചേർത്ത VPN ഡയഗ്രത്തിൽ മാത്രം സമാനമായി തോന്നുന്ന മറ്റൊരു ആർക്കിടെക്ചറാണ്. App Service അതേ യുക്തി വിപരീത ദിശയിൽ പിന്തുടരുന്നു: VNet സംയോജനം ആപ്പിന് VNet-ലേക്ക് പുറത്തേക്കുള്ള വിളികൾ നടത്താൻ അനുവദിക്കുന്നു, നിങ്ങളുടെ ടണലിൽ നിന്ന് അകത്തേക്കുള്ള സ്വകാര്യ പാത അത് സൃഷ്ടിക്കുന്നില്ല. അതിനാൽ അകത്തേക്കുള്ള സ്വകാര്യ ആക്സസിന് സ്വകാര്യ എൻഡ്പോയിന്റ്, App Service പരിതസ്ഥിതി അല്ലെങ്കിൽ ആപ്പിന് മുന്നിലുള്ള ഗേറ്റ്വേ വേണം, അവയിൽ ഏത് ഉപയോഗിക്കാമെന്നത് പ്ലാനിനെ ആശ്രയിച്ചിരിക്കുന്നു.
പരിശോധന നാല്: സ്വന്തം മുൻവാതിലുള്ള ഉൽപ്പന്നങ്ങൾ
Firebase Hosting Cloud VPN-നോട് ബന്ധിപ്പിക്കാൻ കഴിയില്ല, കാരണം ഹോസ്റ്റിംഗ് പാളി ഒരു പ്രോജക്ട് VPC-യ്ക്കുള്ളിലെ എന്തോ അല്ല, ആഗോള മുൻഭാഗമാണ്. രേഖപ്പെടുത്തിയ ബദൽ നിയന്ത്രിത പ്രവേശന കേന്ദ്രം സ്വയം നിർമ്മിക്കുക എന്നതാണ്, പ്രോക്സി ഇൻസ്റ്റൻസോ ബക്കറ്റിനെ ആശ്രയിക്കുന്ന ലോഡ് ബാലൻസറോ ഉപയോഗിച്ച്. ഏതായാലും സൈറ്റ് ശുദ്ധമായ ഹോസ്റ്റിംഗ് ഉൽപ്പന്നമായിരിക്കുന്നത് നിർത്തി ഇപ്പോൾ നിങ്ങൾ പ്രവർത്തിപ്പിക്കുന്ന ഇൻഫ്രാസ്ട്രക്ചറായി മാറുന്നു. ടണൽ അതിനെ മൂടുമെന്ന് ആരെങ്കിലും വാഗ്ദാനം ചെയ്യുന്നതിന് മുമ്പ് ഈ കൈമാറ്റത്തിന് പേര് നൽകേണ്ടതുണ്ട്.
Private API Gateway VPC സേവന വശത്തോട് കൂടുതൽ അടുത്താണ്: interface തരം VPC എൻഡ്പോയിന്റ് ഉത്തരങ്ങൾ സ്വകാര്യ വിലാസങ്ങളായ ഒരു ഹോസ്റ്റ്നാമം പ്രസിദ്ധീകരിക്കുന്നു, നിങ്ങളുടെ കെട്ടിടത്തിൽ നിന്നുള്ള ട്രാഫിക് ടണലിലൂടെയോ സമർപ്പിത ഇന്റർകണക്റ്റിലൂടെയോ എത്തുന്നു. എൻഡ്പോയിന്റ് API-യുമായി ബന്ധിപ്പിച്ചിരിക്കണം, സർട്ടിഫിക്കറ്റും ഹോസ്റ്റ്നാമവും വിളിക്കുന്നവർ ഉപയോഗിക്കുന്ന ഇഷ്ടാനുസൃത ഡൊമെയ്നുമായി പൊരുത്തപ്പെടണം.
Google Cloud VPN ടണലുകൾ പേരുകളല്ല, പിയർ IP വിലാസങ്ങളുമായി ബന്ധിക്കുന്നു. DNS ഫോർവേഡിംഗ് വെവ്വേറെ ക്രമീകരിക്കുന്നു, അതുകൊണ്ടാണ് ടണൽ പൂർണ്ണമായും ആരോഗ്യകരമായിരിക്കുമ്പോഴും വിദൂര സ്വകാര്യ സോണിലെ തിരച്ചിലുകൾ പരാജയപ്പെടുന്നത്.
എന്നിട്ട് അതിർത്തി കണ്ടെത്തുക
VPC-യ്ക്കുള്ളിലെ VM-ൽ നിന്ന് അതേ കണക്ഷൻ പ്രവർത്തിപ്പിക്കുക. അവിടെ വിജയിച്ച് VPN ക്ലയന്റിൽ നിന്ന് പരാജയപ്പെട്ടാൽ, വിടവ് ക്ലയന്റ് പാതയ്ക്കും സേവന എൻഡ്പോയിന്റിനും ഇടയിലാണ്: ഒരു റൂട്ട്, സുരക്ഷാ ഗ്രൂപ്പ്, എൻഡ്പോയിന്റ് നയം അല്ലെങ്കിൽ ഒരു പേര്. രണ്ട് ശ്രമങ്ങളും പരാജയപ്പെട്ടാൽ, ആ നെറ്റ്വർക്കിലുള്ള ഒന്നിനും സേവനത്തിൽ എത്താൻ കഴിയില്ല, VPN ഒരിക്കലും തടസ്സമായിരുന്നില്ല.
getent hosts db.internal.example
nc -vz db.internal.example 5432പേരിന്റെ തിരച്ചിലും പോർട്ട് പരിശോധനയും വെവ്വേറെ ചെയ്യുക, കാരണം അവ വ്യത്യസ്ത കാരണങ്ങളാൽ പരാജയപ്പെടുന്നു, ആ ജോടി പാതയുടെ ഏത് പകുതിയാണ് തകർന്നതെന്ന് പറയുന്നു. പൊതു വിലാസത്തിലേക്ക് നിർണ്ണയിക്കുന്ന ഒരു പേര് സ്വകാര്യ DNS സോൺ പ്രവർത്തനത്തിലില്ല എന്ന് നിങ്ങളോട് പറയുന്നു.