GCP VM-ലേക്കുള്ള Cloud VPN: NAT IP അല്ല, ആന്തരിക IP ഉപയോഗിക്കുക
ഗേറ്റ്‌വേ എൻഡ്‌പോയിന്റ്, VM-ന്റെ ആന്തരിക വിലാസം, പുറത്തുള്ള ഒന്ന്-ഒന്ന് NAT വിലാസം എന്നിവ മൂന്ന് വ്യത്യസ്ത ജോലികൾ ചെയ്യുന്നു. നിങ്ങളുടെ റൂട്ട് ഏതാണ് ഉപയോഗിക്കുന്നതെന്ന് പരിശോധിക്കുക.
ഒരു ഓൺ-പ്രെമൈസ് നെറ്റ്‌വർക്ക് Cloud VPN വഴി VPC-യിൽ എത്തുമ്പോൾ, Compute Engine സേവനത്തിന്റെ ലക്ഷ്യസ്ഥാനം സാധാരണയായി VM-ന്റെ ആന്തരിക വിലാസമാണ്. പുറത്തുള്ള IPv4 വിലാസം അതേ സ്വകാര്യ റൂട്ടിൽ പകരമായി ഇടാവുന്ന രണ്ടാമത്തെ വിലാസമല്ല. ഈ മേഖലയിലെ മിക്ക ആശയക്കുഴപ്പവും മൂന്ന് ജോലികളുള്ള മൂന്ന് വിലാസങ്ങളെ പരസ്പരം മാറ്റാവുന്നവയായി കാണുന്നതിൽ നിന്നാണ് വരുന്നത്, അതിനാൽ ഒരു നിർദ്ദിഷ്ട പാക്കറ്റ് ഏതാണ് ഉപയോഗിക്കുന്നതെന്ന് പേരിട്ട് തുടങ്ങുക.
മൂന്ന് വിലാസങ്ങൾ, മൂന്ന് ജോലികൾ
അവയിൽ ഏതെങ്കിലും ഡീബഗ് ചെയ്യുന്നതിന് മുൻപ് മൂന്നും പേരിടുക, കാരണം ഉത്തരം അടുത്തതായി പരിശോധിക്കുന്ന വസ്തുവിനെ മാറ്റുന്നു.
| Address | Job |
|---|---|
| Cloud VPN endpoint | where the IPsec peers meet |
| Internal IP | the address your route and firewall must name |
| External IPv4 | the platform's inbound mapping, not a guest address |
ആദ്യത്തേത് ടണലിന്റേതാണ്. രണ്ടാമത്തേത് നിങ്ങളുടെ റൂട്ട്, ഫയർവാൾ രൂപകൽപ്പനയുടേതാണ്. മൂന്നാമത്തേത് ഇൻബൗണ്ട് ഇന്റർനെറ്റ് ആക്സസിന്റേതാണ്, അത് മാപ്പ് ചെയ്യപ്പെടുന്നു, ഘടിപ്പിക്കപ്പെടുന്നില്ല. അവയിലൊന്നിന് പ്രവർത്തിക്കുന്ന രൂപകൽപ്പന മറ്റ് രണ്ടിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.
പുറത്തുള്ള വിലാസം രണ്ടാമത്തെ ഇന്റർഫേസ് ആകാത്തതെന്തുകൊണ്ട്
Compute Engine-ൽ ആന്തരികവും പുറംതള്ളിയുമുള്ള എത്തിച്ചേരൽ എങ്ങനെ വ്യത്യസ്തമാണെന്നതിന് അഡ്രസിംഗ് ഗൈഡാണ് അധികാരം. Compute Engine-ന്റെ പുറത്തുള്ള IPv4 ഇൻസ്റ്റൻസിന്റെ ഏക ആന്തരിക NIC-യിലേക്കുള്ള ഒന്ന്-ഒന്ന് മാപ്പിംഗ് ആണ്, അതിനാൽ ഗസ്റ്റ് ആ NIC-യിൽ ഒരിക്കലും രണ്ടാമത്തെ ഇന്റർഫേസോ രണ്ടാമത്തെ വിലാസമോ കാണുന്നില്ല. VM-ൽ നിന്ന് ഉള്ളിൽ റിപ്പോർട്ട് ചെയ്യുന്നത് ഇപ്പോഴും ഒരു പ്രാഥമിക ആന്തരിക വിലാസമാണ്.
അതുകൊണ്ടാണ് ടണലിലൂടെ 10.24.1.7 ലേക്ക് റൂട്ട് ചെയ്യുന്ന സ്വകാര്യ ക്ലയന്റും VM-ന്റെ പുറത്തുള്ള വിലാസം ലക്ഷ്യമിടുന്ന ക്ലയന്റും വ്യത്യസ്ത പാതകളിലുള്ളത്. പൊതു വിലാസത്തിനായി ഫയർവാൾ നിയമം തുറന്നാലും ടണൽ ട്രാഫിക് വഹിക്കേണ്ട VPC റൂട്ടിൽ ഒന്നും മാറുന്നില്ല, ഗസ്റ്റിലെ റൂട്ട് എഡിറ്റ് ചെയ്താലും പ്ലാറ്റ്‌ഫോമിന്റെ മാപ്പിംഗ് നീങ്ങുന്നില്ല. നിങ്ങളുടെ റൂട്ട് പേരിടുന്ന വിലാസം തിരഞ്ഞെടുക്കുക, പിന്നീട് അതിനെ നിയന്ത്രിക്കുന്ന വസ്തുക്കൾ മാത്രം പരിശോധിക്കുക. ഈ അച്ചടക്കം ഈ ട്രബിൾഷൂട്ടിംഗ് പാതയിൽ നിന്ന് മിക്ക ഊഹങ്ങളും ഒഴിവാക്കുന്നു.
gcloud ഉപയോഗിച്ച് പാത നടക്കുക
ഇൻസ്റ്റൻസിൽ നിന്ന് തുടങ്ങി രണ്ട് വിലാസങ്ങളും ഒരേ വസ്തുവിൽ നിന്ന് വായിക്കുക, എങ്കിൽ നിങ്ങളുടെ ഡോക്യുമെന്റേഷൻ ഏതിനെക്കുറിച്ചാണ് പറയുന്നതെന്ന് അറിയാം:
gcloud compute instances describe app-1 --zone=europe-west1-b \
--format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"തുടർന്ന് പാത യഥാർത്ഥത്തിൽ ആശ്രയിക്കുന്ന റൂട്ടിംഗും അനുമതിയും സ്ഥിരീകരിക്കുക:
gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1ടണൽ പ്രഖ്യാപിച്ചതും പഠിച്ചതുമായ ശ്രേണികൾ വായിക്കുക, വർക്ക്ലോഡ് സബ്‌നെറ്റിനുള്ള VPC റൂട്ട്, ഓൺ-പ്രെമൈസ് ഉറവിടത്തെ അനുവദിക്കുന്ന ഫയർവാൾ നിയമം എന്നിവ. ഗസ്റ്റിലെ ലിസണർ പ്രസക്തമാകുന്നതിന് മുൻപ് ഈ മൂന്നും യോജിക്കണം.
തുടർന്ന് ഗസ്റ്റ് പരിശോധിക്കുക: സേവനം ആന്തരിക വിലാസത്തിൽ കേൾക്കുന്നുണ്ടോ, അതിന്റെ മടക്കപ്പാത വീണ്ടും VPC വഴി പോകുന്നുണ്ടോ? പൊതു വിലാസത്തിൽ മാത്രം ബന്ധിപ്പിച്ച ലിസണർ, ക്ലൗഡ് ഭാഗത്തെ എല്ലാ വസ്തുക്കളും ശരിയായാലും ഈ പരീക്ഷണത്തിൽ പരാജയപ്പെടും.
പൊതു പ്രിഫിക്സ് മറ്റൊരു ചോദ്യമാണ്
മേൽപ്പറഞ്ഞവയൊന്നും VPN-നുള്ളിൽ കൊണ്ടുപോകുന്ന ഓരോ വിലാസവും RFC1918 ആയിരിക്കണമെന്ന് അർത്ഥമാക്കുന്നില്ല. ദൂര നെറ്റ്‌വർക്ക് പൊതു ഇടത്തിൽ നിന്ന് നിയമപരമായി അക്കമിടാം, പ്ലാറ്റ്‌ഫോം റൂട്ടിംഗ് പിന്തുണയ്ക്കുകയും ഓപ്പറേറ്റർക്ക് വിലാസ അധികാരം ഉണ്ടായിരിക്കുകയും ചെയ്താൽ. ഇത് സാധാരണ രൂപകൽപ്പനാ തിരഞ്ഞെടുപ്പാണ്.
ഇത് സാധാരണ പുറത്തുള്ള NAT വിലാസത്തെ മറ്റൊരു ആന്തരിക സബ്‌നെറ്റ് വിലാസമായി കാണുന്നതിന് തുല്യമല്ല. ഒന്ന് നിങ്ങൾ റൂട്ട് ചെയ്യുന്ന പ്രിഫിക്സ്; മറ്റൊന്ന് പ്ലാറ്റ്‌ഫോം ഇൻബൗണ്ട് ആക്സസിൽ പ്രയോഗിക്കുന്ന മാപ്പിംഗ്.
പുറത്തുള്ള IPv6-നും പ്രത്യേകം രൂപകൽപ്പന ചെയ്ത വിലാസ ക്രമീകരണങ്ങൾക്കും സ്വന്തം അർത്ഥശാസ്ത്രമുണ്ട്. നിങ്ങളുടെ പദ്ധതി അവയിലൊന്നിനെ ആശ്രയിക്കുന്നെങ്കിൽ, IPv4 കേസിൽ നിന്ന് സാമാന്യവൽക്കരിക്കാതെ ആ സവിശേഷതയുടെ പ്ലാറ്റ്‌ഫോം ഡോക്യുമെന്റേഷൻ വായിക്കുക. IPv4 മാപ്പിംഗ് സാധാരണ കേസാണ്, ഒരേയൊരു കേസല്ല, ഓരോ അപവാദത്തിനും സ്വന്തം നിയമങ്ങളുണ്ട്.
ആവർത്തിക്കുന്ന ശ്രേണികൾ മറ്റൊരു പ്രശ്നമാണ്
ആവർത്തിക്കുന്ന സ്വകാര്യ ശ്രേണികൾ ആളുകൾ പൊതു വിലാസത്തിലേക്ക് തിരിയുന്നതിന് യഥാർത്ഥ കാരണമാണ്, അത് തെറ്റായ ഉപകരണമാണ്. ലക്ഷ്യസ്ഥാനം VM-ന്റെ NAT വിലാസത്തിലേക്ക് മാറ്റുന്നത് ആവർത്തനം പരിഹരിക്കുന്നില്ല; പാക്കറ്റ് ഏത് വിലാസത്തിനാണെന്ന് അവകാശപ്പെടുന്നു എന്നത് മാറ്റുന്നു, മടക്കപ്പാത എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് നിർവചിക്കാതെ.
ആവർത്തനം ബോധപൂർവ്വം പരിഹരിക്കുക: വീണ്ടും അക്കമിടുക, പിന്തുണയുള്ള വിവർത്തന രൂപകൽപ്പന ഉപയോഗിക്കുക, അല്ലെങ്കിൽ പ്രിഫിക്സുകൾ കൂട്ടിയിടിക്കാത്ത നെറ്റ്‌വർക്കിലൂടെ റൂട്ട് ചെയ്യുക. അവയോരോന്നും ഉടമയുള്ള രൂപകൽപ്പനയാണ്. NAT വിലാസം രൂപകൽപ്പനയല്ല.
രണ്ട് ഫീൽഡുകളും വെവ്വേറെ ഡോക്യുമെന്റ് ചെയ്യുക
ടണൽ പിയറും വർക്ക്ലോഡ് ലക്ഷ്യസ്ഥാനവും രണ്ട് വെവ്വേറെ റൺബുക്ക് ഫീൽഡുകളായി രേഖപ്പെടുത്തുക, ഓരോന്നിനും അതിനെ പിന്തുണയ്ക്കുന്ന റൂട്ടും ഫയർവാൾ നിയമവും ചേർക്കുക. കയറിവരുന്ന IPsec ടണൽ പക്ഷങ്ങൾ യോജിച്ചു എന്ന് മാത്രം പറയുന്നു; വർക്ക്ലോഡ് ഏത് വിലാസത്തിൽ എത്താവുന്നതാണെന്നും അതിന്റെ സ്വകാര്യ റൂട്ട് പൂർണ്ണമാണോ എന്നും ഒന്നും പറയുന്നില്ല.
മറുവശത്ത് യഥാർത്ഥ ക്ലയന്റ് ഉപയോഗിച്ച് സ്ഥിരീകരിക്കുക: പേര് റിസോൾവ് ചെയ്യുക, ആന്തരിക വിലാസം തിരികെ നൽകുന്നുവെന്ന് ഉറപ്പാക്കുക, കണക്ട് ചെയ്യുക, മടക്ക ട്രാഫിക് പരിശോധിക്കുക. Compute Engine IP വിലാസ ഡോക്യുമെന്റേഷൻ മുകളിൽ ഉപയോഗിച്ച ആന്തരിക-പുറം വ്യത്യാസത്തിന്റെ റഫറൻസാണ്.