നിങ്ങളുടെ GCP VM-ന് OpenVPN IPv6 പൂളിനോട് പ്രതികരിക്കാൻ കഴിയാത്തത് എന്തുകൊണ്ട്

നിങ്ങളുടെ IPv6 VPN ക്ലയന്റ് വർക്ക്ലോഡിൽ എത്തുന്നു, വർക്ക്ലോഡ് ടണലിനുള്ളിലേക്ക് മറുപടി നൽകുന്നു, എന്നാൽ മറുപടി ഒരിക്കലും എത്തുന്നില്ല. ഫയർവാൾ അല്ലെങ്കിൽ ടണലിനെ കുറ്റപ്പെടുത്താനാണ് ആദ്യ തോന്നൽ, സാധാരണയായി രണ്ടും കുറ്റക്കാരല്ല. OpenVPN നൽകുന്ന വിലാസം ടണലിനുള്ളിൽ മാത്രം നിലനിൽക്കുന്ന ഒരു ആന്തരിക നെറ്റ്വർക്കാണ്; fd42:90::/64 ഒരു പ്രത്യേക VM-ന് പിന്നിലായിരിക്കണമെന്ന് നിങ്ങൾ പറയുന്നതുവരെ Google Cloud-ന് അറിയില്ല.

ഈ വസ്തുത രണ്ട് വേറിട്ട സിസ്റ്റങ്ങൾ പഠിക്കണം, അവയിൽ ഒന്ന് മാത്രമാണ് OpenVPN. എന്തെങ്കിലും തിരികെ അയക്കാൻ VPC-ക്ക് ഒരു റൂട്ട് ആവശ്യമാണ്, വരുന്നത് ഫോർവേഡ് ചെയ്യാൻ VM-ന് അനുമതി നൽകണം. ഏതെങ്കിലും പകുതിയിൽ പിഴച്ചാൽ ലക്ഷണം ഒരേപോലെ തോന്നും.

പൂൾ ഒരു ആന്തരിക നെറ്റ്വർക്കാണ്, സബ്നെറ്റ് അല്ല

OpenVPN നിങ്ങൾ തിരഞ്ഞെടുക്കുന്ന ശ്രേണിയിൽ നിന്ന് IPv6 വിലാസങ്ങൾ നൽകാം, ആ ശ്രേണി ടണലിന്റെ രണ്ട് അറ്റങ്ങൾ യോജിക്കുന്ന ഒരു സാങ്കൽപ്പികതയാണ്. അത് Google Cloud സബ്നെറ്റ് അല്ല, VPC സബ്നെറ്റ് പട്ടികയിൽ കാണുന്നില്ല, VM-ന്റെ നെറ്റ്വർക്ക് ഇന്റർഫേസിന് ആ വിലാസങ്ങൾ ലഭിക്കുന്നുമില്ല. അതിനാൽ ക്ലയന്റിന് മറുപടി നൽകുന്ന വർക്ക്ലോഡ്, നെറ്റ്വർക്ക് റൂട്ട് ചെയ്യാനാവില്ലെന്ന് കരുതുന്ന ഒരു വിലാസത്തിലേക്ക് പാക്കറ്റ് അയക്കുന്നു.

VPC ഇതിനകം ഉപയോഗിക്കുന്ന ഓരോ ശ്രേണിക്കും പുറത്ത് പൂൾ നിർത്തുക. നിങ്ങളുടെ മറ്റ് ടണലുകൾക്ക് പിന്നിലെ ശ്രേണികൾക്കും പുറത്ത് നിർത്തുക. ഓവർലാപ്പ് വ്യക്തമായ ഒരു റൂട്ടിംഗ് പരാജയത്തെ ലോഡിന് കീഴിൽ മാത്രം പ്രത്യക്ഷപ്പെടുന്ന ഇടയ്ക്കിടെയുള്ള പരാജയമാക്കി മാറ്റുന്നു.

fd42:90::/64 പോലുള്ള അദ്വിതീയ ലോക്കൽ അഡ്രസ്സിംഗ് ഈ ആന്തരിക നെറ്റ്വർക്കിന് ന്യായമായ തിരഞ്ഞെടുപ്പാണ്. ഡിസൈൻ സ്വഭാവത്താൽ തന്നെ സ്വകാര്യമാണെന്ന് പ്രിഫിക്സ് ഓർമ്മിപ്പിക്കുന്നു. ULA പൂളിലുള്ള ഒന്നും അതിനെ പൊതു ഇന്റർനെറ്റിൽ നിയമാനുസൃത സ്രോതസ്സാക്കുന്നില്ല.

VPC-ക്ക് ഒരു ലക്ഷ്യവും അടുത്ത ഹോപ്പും നൽകുക

മറുപടിക്ക് ലക്ഷ്യം പൂളും അടുത്ത ഹോപ്പ് VPN VM-ഉം ആയ ഒരു VPC റൂട്ട് വേണം. നിലവിലെ സ്റ്റാറ്റിക് റൂട്ട് ഡോക്യുമെന്റേഷൻ IPv6 ലക്ഷ്യ ശ്രേണികൾ ഉൾക്കൊള്ളുന്നു, ഏത് അടുത്ത ഹോപ്പ് തരങ്ങൾ യോഗ്യമാണെന്ന് പട്ടികപ്പെടുത്തുന്നു, അതിനാൽ പഴയ IPv4 ഉദാഹരണം പകർത്തുന്നതിന് പകരം നിങ്ങളുടെ ടോപ്പോളജിക്ക് പിന്തുണയുള്ള രൂപം പരിശോധിക്കുക.

അടുത്ത ഹോപ്പ് വിലാസം ഇൻസ്റ്റൻസിന്റെ ക്ലൗഡ് ഇന്റർഫേസിന് യഥാർത്ഥത്തിൽ അനുവദിച്ചിട്ടുള്ള ഒന്നായിരിക്കണം. VM-ന്റെ ആന്തരിക ടണൽ വിലാസം അതല്ല. അത് ഉപയോഗിച്ചാലും വൃത്തിയായി ഇൻസ്റ്റാൾ ചെയ്യപ്പെടുന്നതും ഒരിക്കലും ഒരു പാക്കറ്റുമായി പൊരുത്തപ്പെടാത്തതുമായ ഒരു റൂട്ട് ഉണ്ടാകും. റൂട്ട് എഴുതുന്നതിന് മുൻപ് ഇന്റർഫേസ് പട്ടിക വായിക്കുക.

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

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

ഫോർവേഡിംഗ് രണ്ട് തവണ പ്രവർത്തനക്ഷമമാക്കണം

ഒരു റൂട്ട് പാക്കറ്റ് ഇൻസ്റ്റൻസിലേക്ക് എത്തിക്കുന്നു. അത് തനിക്ക് വിലാസമില്ലാത്ത ഒന്ന് ഫോർവേഡ് ചെയ്യാൻ ഇൻസ്റ്റൻസിനെ തയ്യാറാക്കുന്നില്ല, ആ അനുമതി രണ്ട് തലങ്ങളിലുണ്ട്.

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

sysctl -w net.ipv6.conf.all.forwarding=1

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

ആർക്ക് എന്താണ് ഉള്ളതെന്ന് OpenVPN-നോട് പറയുക

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

രണ്ടും കൂട്ടിക്കലർത്തിയാൽ സെർവറിലേക്കുള്ള പിംഗ് പ്രവർത്തിക്കുകയും അതിന് പിന്നിൽ ഒന്നും പ്രവർത്തിക്കാതിരിക്കുകയും ചെയ്യുന്ന ടണൽ ഉണ്ടാകും. ഏത് കേസാണ് നിർമ്മിക്കുന്നതെന്ന് തീരുമാനിച്ച്, രണ്ടാമത്തെ push വരി ചേർത്ത് പ്രതീക്ഷിക്കുന്നതിന് പകരം യോജിക്കുന്ന എൻട്രി എഴുതുക.

ഇന്റർനെറ്റ് എഗ്രസ് ഈ ഡിസൈനിന് പുറത്ത് നിർത്തുക

സ്വകാര്യ ആക്സസും ഇന്റർനെറ്റ് ആക്സസും വേറിട്ട പ്ലാനുകളാണ്. റൂട്ടിംഗും ഫോർവേഡിംഗും യോജിച്ചാൽ ULA പൂളിന് ടണൽ വഴി VPC വർക്ക്ലോഡുകളിൽ എത്താം, അതേ പൂളിന് VPC വഴി പൊതു ഇന്റർനെറ്റിലേക്ക് വഴിയില്ല, കാരണം ക്ലൗഡ് ഗേറ്റ്വേ ഏകപക്ഷീയമായ ഒരു ടണൽ സ്രോതസ്സിനെ സ്വന്തമായി സ്വീകരിക്കില്ല.

ക്ലയന്റുകൾക്ക് ഇന്റർനെറ്റ് എഗ്രസും വേണമെങ്കിൽ, അതിനായി പിന്തുണയുള്ള അഡ്രസ്സിംഗും റൂട്ടിംഗ് ഡിസൈനും ആസൂത്രണം ചെയ്യുക, അത് സ്വകാര്യ പൂളിൽ നിന്ന് സ്വതന്ത്രമായി നിർത്തുക, രണ്ട് പാതകളും വെവ്വേറെ പരീക്ഷിക്കുക. പ്രവർത്തിക്കുന്ന ഒരു പാത മറ്റൊന്നിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, രണ്ടും കൂട്ടിക്കലർത്തുന്ന ഡിസൈൻ തകർന്ന ടണൽ പോലെ തോന്നുന്ന രീതിയിൽ പരാജയപ്പെടുന്നു.