GCE-യിൽ OpenVPN: routes push ചെയ്യുന്നതിന് മുമ്പ് alias IP ചേർക്കുക

ഒരു ക്ലയന്റ് Compute Engine VM-ലെ OpenVPN സെർവറിലേക്ക് ഡയൽ ചെയ്യുന്നു, സ്റ്റാറ്റസ് വിൻഡോ കണക്ട് ചെയ്തു എന്ന് പറയുന്നു, എന്നാൽ VPC-യ്ക്കുള്ളിലെ ഒരു host-ലേക്കുള്ള ping ഇപ്പോഴും എങ്ങോട്ടും എത്തുന്നില്ല. സഹജമായ പ്രവണത മറ്റൊരു push വരി ചേർക്കാനാണ്, അത് ഒരിക്കലും ശരിയാക്കുന്നില്ല. Compute Engine തന്റെ സ്വന്തം route പട്ടികയുടെയും VM ഇന്റർഫേസ് യഥാർത്ഥത്തിൽ കൈവശം വയ്ക്കുന്ന വിലാസങ്ങളുടെയും അടിസ്ഥാനത്തിൽ packet എവിടെ പോകണമെന്ന് തീരുമാനിക്കുന്നു, അതിനാൽ VM-ന് സ്വന്തമല്ലാത്ത tunnel pool എന്നത് ആരും എത്തിക്കാത്ത pool ആണ്.

കോൺഫിഗറേഷൻ ഫയലിന് പകരം പരാജയപ്പെടുന്ന packet-നെ പിന്തുടരുക, കാണാത്ത ഭാഗങ്ങൾ ക്രമത്തിൽ പ്രത്യക്ഷപ്പെടും.

മരിക്കുന്ന packet-ൽ നിന്ന് തുടങ്ങുക

SYN ക്ലയന്റിനെ വിട്ട്, tunnel-ലേക്ക് പ്രവേശിച്ച്, VPC-യ്ക്കുള്ളിലെ ഒരു ലക്ഷ്യത്തിലേക്കുള്ള encapsulated packet ആയി VM-ലെത്തുന്നു. OpenVPN അത് decapsulate ചെയ്ത് eth0 വഴി അയയ്ക്കാൻ ശ്രമിക്കുന്നു, അവിടെ fabric എല്ലാറ്റിനും മുമ്പായി ഒരു ചോദ്യം ചോദിക്കുന്നു: ഈ instance ലക്ഷ്യ വിലാസത്തിന്റെ ഉടമയാണോ. മറ്റൊരാളുടെ subnet-ൽ നിന്ന് മുറിച്ചെടുത്ത tunnel pool ആ ചോദ്യത്തിൽ പരാജയപ്പെടുന്നു, ഏതെങ്കിലും route അല്ലെങ്കിൽ firewall നിയമം പരിശോധിക്കുന്നതിന് മുമ്പ് packet എറിയപ്പെടുന്നു.

അതിനാൽ ക്ലയന്റിൽ നിന്ന് VPC-യിലേക്കുള്ള ദിശയ്ക്ക് രണ്ട് വേറിട്ട ആവശ്യകതകളുണ്ട്, അവയിൽ ഒന്നും push നിർദ്ദേശമല്ല. VM-ന് tunnel pool മൂടുന്ന alias പരിധി വേണം, അതാണ് അതിനെ ആ വിലാസങ്ങളുടെ നിയമാനുസൃത ഉടമയാക്കുന്നത്. VPC-യ്ക്ക് ഓരോ സംരക്ഷിത prefix-നും VM-നെ next hop ആയി പേരിടുന്ന route വേണം. ഒന്ന് വിട്ടുപോയാൽ packet മറ്റെവിടെയോ മരിക്കുന്നു, ക്ലയന്റ് അതേ നിശ്ശബ്ദത കാണുന്നു.

പരാജയം അതേ ക്രമത്തിൽ വായിക്കുക, കാരണം ക്ലയന്റിന്റെ വശത്തുനിന്ന് രണ്ട് വ്യവസ്ഥകളും ഒരേപോലെ തോന്നുന്നു. ഒന്നും ഉത്തരം നൽകാതിരിക്കെ കണക്ട് ചെയ്തു എന്ന് റിപ്പോർട്ട് ചെയ്യുന്ന tunnel topology പ്രശ്നത്തിന്റെ അടയാളമാണ്, മോശം cipher-ന്റേതല്ല.

instance tunnel pool-ന്റെ ഉടമയാണോ

VM-ന് അതിന്റെ സ്വന്തം subnet-നുള്ളിൽ ദ്വിതീയ പരിധി നൽകുക, തുടർന്ന് OpenVPN കൃത്യമായി ആ പരിധിയിൽ നിന്ന് വിലാസങ്ങൾ വിതരണം ചെയ്യട്ടെ. പ്രാഥമിക വിലാസം 10.156.0.10/20 ആയ instance-ൽ, /28 alias pool-നെ മറ്റ് instance-കൾ ഇതിനകം കൈവശം വയ്ക്കുന്ന വിലാസങ്ങളിൽ നിന്ന് വേർതിരിക്കുന്നു:

gcloud compute instances network-interfaces update openvpn-vm \
  --zone=europe-west1-b \
  --aliases=eth0:10.156.1.0/28

അപ്പോൾ server നിർദ്ദേശം അതേ block വിവരിക്കണം. അതിന്റെ ആദ്യ വിലാസം tunnel-ന്റെ gateway ആകുന്നു, ബാക്കി വിലാസങ്ങൾ ക്ലയന്റുകൾക്ക് നൽകുന്നു. ഇവിടെ രണ്ട് സംഖ്യകൾ ഒരു block വിവരിക്കുന്നു, ഒരു network-ഉം ഒരു netmask-ഉം, അതാണ് OpenVPN ഇപ്പോഴും പ്രതീക്ഷിക്കുന്ന pool സിന്റാക്സ്.

server 10.156.1.0 255.255.255.240

വിലാസം യഥാർത്ഥത്തിൽ ഇന്റർഫേസിലെത്തിയോ, OpenVPN കോൺഫിഗറേഷനിൽ മാത്രമല്ലേ എന്ന് ഉറപ്പാക്കുക. fabric NIC റിപ്പോർട്ട് ചെയ്യുന്നത് അയയ്ക്കുന്നു, daemon വിശ്വസിക്കുന്നതല്ല. ഒരു കമാൻഡ് അത് തീരുമാനിക്കുന്നു:

ip -4 addr show dev eth0

ഒരിക്കലും eth0-ൽ എത്താത്ത ദ്വിതീയ വിലാസം, അല്ലെങ്കിൽ മറ്റൊരു subnet-മായി ഓവർലാപ്പ് ചെയ്യുന്ന pool, പിന്നീട് ആരംഭ പിശകായി അല്ലാതെ ഇടയ്ക്കിടെയുള്ള packet നഷ്ടമായി കാണുന്നു. daemon ആരംഭിക്കുന്നു, ക്ലയന്റുകൾ കണക്ട് ചെയ്യുന്നു, ചില ലക്ഷ്യങ്ങൾ മാത്രം തെറ്റായി പെരുമാറുന്നു. route പട്ടികയിൽ pool എളുപ്പത്തിൽ തിരിച്ചറിയാൻ alias പരിധി ചെറുതായി സൂക്ഷിക്കുക. മറ്റൊരു instance ഉപയോഗിക്കുന്ന subnet-ൽ നിന്ന് അത് ഒരിക്കലും മുറിക്കരുത്.

തിരിച്ചുവരുന്ന traffic-ന് next hop നൽകുക

VPC-യിലെ host-ൽ നിന്നുള്ള മറുപടി tunnel pool-ലെ ക്ലയന്റ് വിലാസത്തിലേക്ക് അയയ്ക്കുന്നു, അത് VPC-യ്ക്ക് അറിയാവുന്ന ഒരു subnet-നും അവകാശപ്പെട്ടതല്ല. ആ pool-ന് route ഇല്ലെങ്കിൽ മറുപടി പൊരുത്തമില്ലാത്ത ആദ്യ hop-ൽ നിൽക്കുന്നു, അഭ്യർത്ഥന മറുവശത്ത് വിജയിച്ചിരിക്കാനും സാധ്യതയുണ്ട്.

gcloud compute routes create openvpn-return \
  --network=prod-vpc \
  --destination-range=192.168.127.0/24 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b \
  --priority=800

അതേ route VPC-യ്ക്കുള്ളിൽ അല്ലാതെ ക്ലയന്റിന് പിന്നിലുള്ള ഏത് prefix-നും ആവശ്യമാണ്. ആ prefix-കൾക്ക് ആ ക്ലയന്റിന്റെ ccd ഫയലിൽ iroute എൻട്രിയും വേണം. ആ എൻട്രി സെർവർ വശത്തെ കണക്കെഴുത്താണ്: ഏത് ക്ലയന്റാണ് prefix-ന്റെ ഉടമ എന്ന് സെർവറിനോട് പറയുന്നു, ക്ലയന്റിൽ തന്നെ ഒന്നും ഇൻസ്റ്റാൾ ചെയ്യുന്നില്ല.

push ലിസ്റ്റ് സംഭാഷണത്തിന്റെ ക്ലയന്റ് വശത്തിനായി സൂക്ഷിക്കുക, കാരണം അത് കണക്ട് ചെയ്യുന്ന യന്ത്രത്തിലേക്ക് route-കൾ മാത്രം ചേർക്കുന്നു. VPC subnet-നുള്ള push വരിയും pool-ലേക്ക് തിരിച്ചുള്ള VPC route-ഉം ഒരേ വഴിയുടെ രണ്ട് പകുതികളാണ്, ഏത് പകുതിയും ഒറ്റയ്ക്ക് അഭ്യർത്ഥനകൾ കൊണ്ടുപോകുന്ന പക്ഷേ മറുപടികൾ കൊണ്ടുപോകാത്ത tunnel സൃഷ്ടിക്കുന്നു.

Firewall, forwarding, ഇടയിലുള്ള hop

VPC-യുടെ firewall decapsulated packet വിലയിരുത്തുന്നു, അതിനാൽ ingress നിയമം tunnel pool-നും ആ വഴിയിൽ VM-ലെത്തുന്ന ഏത് site prefix-നും അനുവാദം നൽകണം. default-deny നിലപാട് ഇവിടെ നിശ്ശബ്ദമായി പരാജയപ്പെടുന്നു: decapsulation-ന് ശേഷം packet എറിയപ്പെടുന്നു, OpenVPN ലോഗ് ആരോഗ്യകരമായ session കാണിക്കുന്നു.

terminate ചെയ്യാതെ forward ചെയ്യുന്ന ഏത് Linux host-ലും net.ipv4.ip_forward ഓൺ ആണോ എന്ന് പരിശോധിക്കുക. ഉടമസ്ഥതാ നിയമം അവിടെയും ബാധകമാണ്: തനിക്കില്ലാത്ത subnet-നുവേണ്ടി forward ചെയ്യുന്ന യന്ത്രം VM-നെപ്പോലെ packet എറിയുന്നു. tunnel-നെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് മൂല്യം വായിക്കുക.

കൃത്യമായി ഒരു prefix പരാജയപ്പെടുമ്പോൾ

ഭാഗിക പരാജയം വായിക്കാൻ എളുപ്പമുള്ള സാഹചര്യമാണ്, കാരണം വഴിയിലെ മറ്റെല്ലാം ഇതിനകം തെളിയിക്കപ്പെട്ടിട്ടുണ്ട്. route ലിസ്റ്റിൽ നിന്ന് തുടങ്ങി prefix മൂടേണ്ട എൻട്രിയുടെ ലക്ഷ്യ പരിധിയും next hop-ഉം വായിക്കുക, തുടർന്ന് instance വിവരണം വായിച്ച് അതിന്റെ alias പരിധി സെർവർ വിതരണം ചെയ്യുന്ന pool-മായി താരതമ്യം ചെയ്യുക.

gcloud compute routes list --filter=destination-range~10.164.0.0
 gcloud compute instances describe openvpn-vm --format=get(networkInterfaces[0].aliasIpRanges)

കാണാത്ത route prefix-ന് next hop ഇല്ലാത്തതായി കാണുന്നു, കാണാത്ത alias ഇന്റർഫേസിൽ എറിഞ്ഞ packet ആയി കാണുന്നു; ക്ലയന്റിൽ നിന്ന് രണ്ടും സമാനമായി തോന്നുന്നു, ആ രണ്ട് ഔട്ട്പുട്ടുകളിൽ തികച്ചും വ്യത്യസ്തമാണ്. രണ്ടും ഉണ്ടെങ്കിൽ, ബാക്കിയുള്ള സംശയിതൻ prefix അവകാശപ്പെടുന്ന ക്ലയന്റിന്റെ ccd iroute ആണ്.

നാല് മൂല്യങ്ങൾ tunnel-ന്റെ അടുത്ത് എഴുതുക: alias പരിധി, സെർവറിന്റെ pool, push ചെയ്ത prefix-കൾ, VPC route-കൾ. പഴയ alias pool-ലെ ഓരോ വിലാസവും തകർക്കുന്നു, പഴയ route ഒരു ദിശ തകർക്കുന്നു, കാണാത്ത push prefix ക്ലയന്റിൽ നിന്ന് മറയ്ക്കുന്നു, തെറ്റായ iroute prefix-നെ തെറ്റായ peer-ലേക്ക് അയയ്ക്കുന്നു. അടുത്തതായി subnet ചേർക്കുന്ന വ്യക്തിക്ക് നാലും ഒരിടത്ത് വേണം, ആ കുറിപ്പ് വൈകുന്നേരത്തേക്കാൾ വിലകുറഞ്ഞതാണ്.