VPN വഴി Google API: സബ്നെറ്റ് മാത്രമല്ല, VIP-ലേക്ക് റൂട്ട് ചെയ്യുക
VPC സബ്നെറ്റിലേക്കുള്ള റൂട്ട് API-യുടെ VIP വിലാസങ്ങൾ തിരഞ്ഞെടുക്കുന്നില്ല. ശരിയായ പേരുകൾ പരിഹരിക്കുക, VIP പ്രിഫിക്സ് പ്രഖ്യാപിക്കുക, VPC-യിൽ മടക്കപ്പാത നിലനിർത്തുക, പിന്നീട് HTTPS പരിശോധിക്കുക.
SSH വഴി ഓൺ-പ്രിമൈസ് സെർവറിൽ പ്രവേശിച്ച് ടണൽ ഉയർത്തുമ്പോൾ സ്വകാര്യ VM പ്രതികരിക്കുന്നു; പിന്നീട് Google API-യിലേക്കുള്ള ആദ്യ കോൾ റൂട്ട് ഇല്ലാതെ പരാജയപ്പെടുന്നു. VM-ന്റെ സബ്നെറ്റും API-യുടെ VIP വിലാസങ്ങളും വ്യത്യസ്ത ലക്ഷ്യസ്ഥാനങ്ങളാണ്, അതിനാൽ ഒന്നിലേക്കുള്ള റൂട്ട് മറ്റൊന്നിനെ തിരഞ്ഞെടുക്കുന്നില്ല. സ്വകാര്യ API കോൾ പ്രവർത്തിക്കാൻ മൂന്ന് വ്യവസ്ഥകൾ പാലിക്കണം. API-യുടെ പേര് ഒരു VIP-ലേക്ക് പരിഹരിക്കണം, VIP പ്രിഫിക്സ് ടണലിലൂടെ പ്രഖ്യാപിക്കണം, കൂടാതെ മറുപടി എങ്ങനെ തിരികെ അയക്കണമെന്ന് VPC-ക്ക് അറിയണം. പിംഗ് അതിൽ ഒന്നും പറയുന്നില്ല, സബ്നെറ്റിലെ ഒരു മെഷീനിലേക്കുള്ള പ്രവർത്തിക്കുന്ന SSH സെഷനും പറയുന്നില്ല.
API-യുടെ VIP വിലാസങ്ങൾ വേറിട്ട ലക്ഷ്യസ്ഥാനങ്ങളാണ്
ഓൺ-പ്രിമൈസ് നെറ്റ്വർക്കിൽ നിന്നുള്ള API പ്രവേശനത്തിനായി Google സമർപ്പിത VIP വിലാസങ്ങൾ പ്രസിദ്ധീകരിക്കുന്നു, API പേരുകൾക്കായി നിങ്ങളുടെ DNS തിരികെ നൽകേണ്ടത് ആ വിലാസങ്ങളാണ്. രണ്ടും ചെറിയ പ്രിഫിക്സുകളാണ്, ഒന്നും RFC 1918 ഇടമല്ല:
| Record | Resolves to | What it does not give you |
|---|---|---|
| private.googleapis.com | 199.36.153.8/30, the general front door for Google APIs | not a bypass around a service perimeter |
| restricted.googleapis.com | 199.36.153.4/30, reachable only for services a perimeter allows | not the whole API surface, so some names stay out of reach |
പൊതുവായി തോന്നുന്ന വിലാസങ്ങൾ എന്നർത്ഥം റൂട്ട് ടണൽ വിടണമെന്നല്ല സാധാരണ ഇന്റർനെറ്റിന്. ഓൺ-പ്രിമൈസ് ക്ലയന്റിന് ഏകപക്ഷീയമായ ഒരു എഗ്രസ് പോയിന്റിനു പകരം പിന്തുണയുള്ള ഒരു പാതയിലൂടെ Google-ന്റെ ഫ്രണ്ട് എൻഡുകളിൽ എത്താൻ വേണ്ടിയാണ് ഈ പ്രിഫിക്സുകൾ. ടണലിൽ ഉൾപ്പെടുന്ന ലക്ഷ്യസ്ഥാനങ്ങളായി അവയെ കാണുക, പരിശോധിക്കേണ്ട ഹോസ്റ്റുകളായി അല്ല. ഇന്റർനെറ്റ് എഗ്രസിനായി എഴുതിയ ഫയർവാൾ നിയമം സാധാരണയായി അവ ഉപേക്ഷിക്കുന്നു, കോൾ തുടങ്ങുന്നതിന് മുൻപേ പരാജയപ്പെടുന്നതിന്റെ സാധാരണ കാരണം അതാണ്.
ഏത് എൻഡ്പോയിന്റിൽ എത്തുന്നു എന്നത് DNS തീരുമാനിക്കുന്നു
തിരഞ്ഞെടുത്ത എൻഡ്പോയിന്റിനായി Google രേഖപ്പെടുത്തിയ റെക്കോർഡുകളിലേക്ക് പ്രാദേശിക റിസോൾവർ ചൂണ്ടിക്കാണിക്കുക, അപ്പോൾ ആപ്ലിക്കേഷന് ആവശ്യമായ പേരുകൾ ആ VIP ഉപയോഗിച്ച് മറുപടി നൽകും. വെറുതെ googleapis.com മാപ്പ് ചെയ്യുന്നത് ഒരു ഇൻവെന്ററിയല്ല: പാക്കേജ് രജിസ്ട്രികൾ, കണ്ടെയ്നർ രജിസ്ട്രികൾ, മൈഗ്രേഷൻ കണക്ടറുകൾ എന്നിവയ്ക്ക് അവയുടേതായ രേഖപ്പെടുത്തിയ പേരുകളുണ്ട്. നിയന്ത്രിത VIP എല്ലാ സേവനവും വഹിക്കുന്നുമില്ല, അതിനാൽ പരിഹരിക്കപ്പെടുന്ന ഒരു പേര് ഇപ്പോഴും പിന്തുണയ്ക്കാത്തതാകാം. റിസോൾവർ തൊടുന്നതിന് മുൻപ് ആപ്ലിക്കേഷൻ യഥാർത്ഥത്തിൽ ബന്ധപ്പെടുന്ന ഡൊമെയ്നുകൾ എഴുതി വയ്ക്കുക.
സേവന നാമത്തിനു പകരം VPC VM വിലാസം ഊഹിക്കുന്നത് പരിഹാരമല്ല, സാധാരണയായി മറ്റൊരു ക്ലയന്റ് പരാജയപ്പെടുന്നതുവരെ DNS-ലെ വിടവ് അത് മറയ്ക്കുന്നു.
VIP പ്രിഫിക്സ് പ്രഖ്യാപിക്കുക, ബാക്കി നിലനിർത്തുക
BGP അടിസ്ഥാനമാക്കിയ കണക്ഷനിൽ, ഉദ്ദേശിച്ച സെഷനിലൂടെ ആ പരിധി പ്രാദേശിക റൂട്ടർ പഠിക്കാൻ Cloud Router തിരഞ്ഞെടുത്ത VIP പ്രിഫിക്സ് പ്രഖ്യാപിക്കണം. VPC സബ്നെറ്റുകൾ മാത്രം പ്രഖ്യാപിച്ചാൽ ആ പരിധി കൂടുകയില്ല, ആ വിലാസങ്ങൾക്ക് പ്രാദേശിക റൂട്ടർ അതിന്റെ സ്വതേയുള്ള പാത തുടരും. റൂട്ടിംഗ് പട്ടികയിലെ പ്രിഫിക്സ് മാത്രമാണ് പ്രഖ്യാപനം സെഷൻ കടന്നു എന്നതിന്റെ തെളിവ്.
പുതിയത് ചേർക്കുമ്പോൾ നിലവിലുള്ള പ്രഖ്യാപനങ്ങൾ നിലനിർത്തുക, കാരണം റൂട്ടർ തലത്തിലും പിയർ തലത്തിലുമുള്ള ഓപ്ഷനുകൾക്ക് വ്യത്യസ്ത വ്യാപ്തിയുണ്ട്, സെറ്റ് മാറ്റുന്നത് മുൻപ് പ്രവർത്തിച്ച നെറ്റ്വർക്കുകൾ പിൻവലിച്ചേക്കാം. പിന്നീട് മുഴുവൻ റൂട്ടറിലല്ല, ഓരോ സെഷനിലും ഫലപ്രദമായ പ്രഖ്യാപനം പരിശോധിക്കുക. ഇല്ലാത്ത പ്രിഫിക്സും പിൻവലിച്ച പ്രിഫിക്സും പ്രാദേശിക വശത്തുനിന്ന് ഒരുപോലെ കാണാം, അതിനാൽ സെഷൻ കാഴ്ചയാണ് വിട്ടുപോകലിനെ റിഗ്രഷനിൽ നിന്ന് വേർതിരിക്കുന്നത്.
VPC വശത്തിന് സ്വന്തം റൂട്ടും മടക്കപ്പാതയും വേണം
VPC-യ്ക്കുള്ളിൽ, VIP-യുടെ പാത അടുത്ത ഹോപ്പായി സ്വതേയുള്ള ഇന്റർനെറ്റ് ഗേറ്റ്വേ ഉപയോഗിക്കണം, പേര് അങ്ങനെയെങ്കിലും ആ ട്രാഫിക് Google-ന്റെ നെറ്റ്വർക്കിനുള്ളിൽ തന്നെ തുടരുന്നു. VPN വഴി പ്രാദേശിക ഉറവിടത്തിലേക്ക് മടങ്ങാനുള്ള റൂട്ടും VPC-ക്ക് വേണം, അത് പ്രഖ്യാപിച്ച പ്രിഫിക്സിൽ നിന്ന് വേറിട്ട ഒരു ഒബ്ജക്ടാണ്. ടണലും ക്ലയന്റും ഒരേ പ്രദേശത്തല്ലെങ്കിൽ രേഖപ്പെടുത്തിയ പ്രാദേശിക റൂട്ടിംഗ് ആവശ്യകതകൾ പരിഗണിക്കുക.
മടക്കപ്പാത സ്വതന്ത്രമായി പരിശോധിക്കുക, കാരണം പ്രവർത്തിക്കുന്ന അഭ്യർത്ഥന ദിശ തകർന്ന മറുപടി ദിശ മറയ്ക്കാം. രണ്ട് ദിശ, രണ്ട് റൂട്ട്, ഓരോന്നും അതിന്റേതായ ലക്ഷണത്തോടെ പരാജയപ്പെടുന്നു.
അഭ്യർത്ഥന പരിശോധിക്കുക, പിന്നീട് നിരസിക്കൽ വായിക്കുക
ഈ VIP-കളിൽ നിന്ന് ICMP എക്കോയ്ക്ക് മറുപടി ലഭിക്കുന്നില്ല, അതിനാൽ പരാജയപ്പെട്ട പിംഗ് ഒന്നും തെളിയിക്കുന്നില്ല, വിജയിച്ചത് വളരെ കുറച്ച് മാത്രം. യഥാർത്ഥ ക്ലയന്റിൽ നിന്ന് പേരിന്റെ മറുപടിയും തിരഞ്ഞെടുത്ത റൂട്ടും പരിശോധിക്കുക, പിന്നീട് നിങ്ങൾക്ക് പ്രധാനമായ സേവനത്തിലേക്ക് അധികാരമുള്ള HTTPS അഭ്യർത്ഥന നടത്തുക. അഭ്യർത്ഥന സേവനത്തിൽ എത്തി നിരസിക്കപ്പെട്ടാൽ ക്രെഡൻഷ്യലുകൾ, IAM, ബാധകമായ സേവന പരിധി നയം എന്നിവ നോക്കുക.
സ്വകാര്യ റൂട്ടിംഗ് API അധികാരം നൽകുന്നില്ല, ഐഡന്റിറ്റിക്ക് എന്ത് ചെയ്യാമെന്നതും മാറ്റുന്നില്ല. ട്രാൻസ്പോർട്ട് വിജയവും അധികാരമുള്ള മറുപടിയും വേറിട്ട ഫലങ്ങളാണ്, രണ്ടും വേണം. IPv6 പാതയും വ്യക്തമായി നിലനിർത്തുക, കാരണം IPv4 പ്രിഫിക്സുകൾ ക്രമീകരിക്കുന്നത് IPv6 ഇഷ്ടപ്പെടുന്ന ക്ലയന്റിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.
Google-ന്റെ ഓൺ-പ്രിമൈസ് Private Google Access ഗൈഡ് DNS റെക്കോർഡുകളും റൂട്ടിംഗ് ആവശ്യകതകളും ഒരുമിച്ച് ഉൾക്കൊള്ളുന്നു, അതിനാൽ നിങ്ങളുടെ റിസോൾവർ, പ്രഖ്യാപന ക്രമീകരണങ്ങൾ ഒരു ഫോറം പോസ്റ്റുമായല്ല, അതുമായി താരതമ്യം ചെയ്യുക. പിന്നീട് അതേ അഭ്യർത്ഥന വീണ്ടും പ്രവർത്തിപ്പിച്ച് മറുപടിയും റൂട്ടും അതേ ടിക്കറ്റിൽ രേഖപ്പെടുത്തുക.