Kubernetes-ലെ OpenVPN പോഡ് ഒന്നും ഫോർവേഡ് ചെയ്യുന്നില്ലേ? ip_forward പരിശോധിക്കുക

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

chart വഴി ഇൻസ്റ്റാൾ ചെയ്ത OpenVPN ഇമേജ് പ്രവർത്തിപ്പിക്കുന്ന Debian നോഡിൽ ഞാൻ ഇത് കണ്ടു, തുരങ്കം എളുപ്പമുള്ള ഭാഗമായിരുന്നു. ക്ലയന്റിന് 10.8.0.x ലീസ് ലഭിച്ചു, 10.8.0.1 പ്രതികരിച്ചു, 10.96.0.10, ക്ലസ്റ്റർ DNS സേവനം, സമയം കഴിഞ്ഞു. സെർവർ ലോഗിൽ ഒന്നും രോഗാവസ്ഥയായി തോന്നിയില്ല, അതുകൊണ്ടാണ് ആളുകൾ ഒരിക്കലും തൊടേണ്ടതില്ലാത്ത iptables നിയമങ്ങൾ വീണ്ടും എഴുതാൻ തുടങ്ങുന്നത്.

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

ക്ലയന്റിന് എത്തിച്ചേരാൻ കഴിയുന്നതും കഴിയാത്തതും

ഉത്തരം നൽകുന്ന വിലാസം തുരങ്കത്തിന്റെ അന്തിമ ബിന്ദുവിനുള്ളതാണ്, VPN പ്രോസസ് അത് പ്രാദേശികമായി കൈവശം വയ്ക്കുന്നു, അതിനാൽ ഫോർവേഡിംഗ് ഒട്ടും ഉൾപ്പെടുന്നില്ല. മറ്റൊരു പോഡ്, സേവനത്തിന്റെ VIP അല്ലെങ്കിൽ ഇന്റർനെറ്റ് ഉൾപ്പെടെ ബാക്കിയെല്ലാം, കെർണൽ tun0 ൽ നിന്ന് eth0 ലേക്ക് ഒരു പാക്കറ്റ് നീക്കേണ്ടതുണ്ട്. ആ നീക്കം നിരസിക്കപ്പെടുമ്പോൾ, ലക്ഷണം നിരസിക്കലല്ല, ഏകീകൃത നിശ്ശബ്ദതയാണ്, കാരണം തുരങ്കത്തിലൂടെ തിരികെ ICMP പിശക് ഉണ്ടാക്കുന്നത് ഒന്നുമില്ല. നിങ്ങൾക്ക് ടൈംഔട്ടുകൾ ലഭിക്കുന്നു, എത്തിച്ചേരാനാകാത്ത സന്ദേശങ്ങളല്ല, ആരും റൂട്ട് ചെയ്യുന്നില്ല എന്നതിന്റെ സൂചന അതാണ്.

രണ്ട് മിനിറ്റ് വർഗ്ഗീകരണം പാളി ചുരുക്കുന്നു. DNS നാമങ്ങൾ പരാജയപ്പെടുമ്പോൾ സേവന IP-യിലേക്കുള്ള അസംസ്കൃത പിംഗുകൾ വിജയിക്കുന്നുവെങ്കിൽ, പ്രശ്നം ഫോർവേഡിംഗിലല്ല, DNS പ്ലംബിംഗിലാണ്. പിയർ വിലാസത്തിനപ്പുറമുള്ള ഓരോ ലക്ഷ്യവും ടൈംഔട്ട് ആകുന്നുവെങ്കിൽ, വെറും IP ഉൾപ്പെടെ, നെയിംസ്പേസിൽ നിന്ന് തുടങ്ങുക.

നെയിംസ്പേസിനുള്ളിലെ ക്രമീകരണം വായിക്കുക

ഓരോ പോഡിനും സ്വന്തം നെറ്റ്വർക്ക് നെയിംസ്പേസ് ലഭിക്കുന്നു, net.ipv4.ip_forward ഓരോ നെയിംസ്പേസിനുമുള്ള sysctl ആണ്. നോഡിൽ അത് മാറ്റുന്നത് കണ്ടെയ്നറിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, തെറ്റായ യന്ത്രത്തിൽ ഉച്ചയ്ക്ക് ശേഷം ചെലവഴിക്കാനുള്ള വിശ്വസനീയമായ വഴിയാണത്.

kubectl exec -it deploy/openvpn -- sysctl net.ipv4.ip_forward
# net.ipv4.ip_forward = 0

പൂജ്യം രോഗനിർണയം സ്ഥിരീകരിക്കുന്നു. മൂല്യം നോഡിന്റെ റൺടൈം കോൺഫിഗറേഷനിൽ നിന്നും പാരമ്പര്യമായി ലഭിക്കുന്നില്ല: കണ്ടെയ്നർ സൃഷ്ടിക്കുമ്പോഴെല്ലാം അത് ഇമേജിന്റെ സ്ഥിരസ്ഥിതിയിൽ നിന്ന് തുടങ്ങുന്നു. അതിനാൽ kubectl exec ... sysctl -w ഉപയോഗിച്ച് കൈകൊണ്ട് പ്രയോഗിച്ച തിരുത്ത് അടുത്ത റീസ്റ്റാർട്ടിൽ അപ്രത്യക്ഷമാകുകയും ഇടയ്ക്കിടെ കാണുന്ന തകരാറായി മടങ്ങിവരികയും ചെയ്യുന്നു.

മാനിഫെസ്റ്റ് അത് നിലനിർത്താൻ പ്രവർത്തനക്ഷമമാക്കുക

നിലനിൽക്കുന്ന ഓപ്ഷൻ അതേ പോഡ് സാൻഡ്ബോക്സിൽ പ്രവർത്തിക്കുന്നതും VPN കണ്ടെയ്നർ ആരംഭിക്കുന്നതിന് മുമ്പ് മൂല്യം എഴുതുന്നതുമായ init കണ്ടെയ്നർ ആണ്. പോഡിലെ കണ്ടെയ്നറുകൾ നെറ്റ്വർക്ക് നെയിംസ്പേസ് പങ്കിടുന്നു, അതിനാൽ ക്രമീകരണം പ്രധാന കണ്ടെയ്നറിലേക്ക് പോകുന്നു.

initContainers:
- name: enable-forwarding
  image: busybox:1.36
  command: ["sysctl", "-w", "net.ipv4.ip_forward=1"]
  securityContext:
    privileged: true

ആ privileged: true ആണ് അവലോകകർ എതിർക്കുന്ന വരി, അവർ ശരിയാണ്. sysctl എഴുതാൻ പ്രത്യേകാവകാശമോ ഇടുങ്ങിയ കഴിവോ വേണം, നിയന്ത്രിത Pod Security Standard പ്രവർത്തിപ്പിക്കുന്ന ക്ലസ്റ്റർ പ്രത്യേകാവകാശമുള്ള init കണ്ടെയ്നറിനെ പൂർണ്ണമായി നിരസിച്ചേക്കാം. admission പോഡിനെ നിരസിച്ചാൽ, സൃഷ്ടിക്കുന്ന സമയത്ത് തന്നെ അറിയാം, അത് കുറഞ്ഞത് സത്യസന്ധവും വായിക്കാൻ എളുപ്പവുമാണ്.

കൂടുതൽ വ്യക്തമായ ബദൽ പോഡ് തലത്തിലുള്ള securityContext.sysctls പട്ടികയാണ്, ഇത് ഏതൊരു കണ്ടെയ്നറിനും പ്രത്യേകാവകാശം നൽകാതെ kubelet-ന് നെയിംസ്പേസ്ഡ് sysctl പ്രയോഗിക്കാൻ അനുവദിക്കുന്നു. ക്ലസ്റ്ററിന്റെ അനുവദനീയ പട്ടികയിലെ പേരുകൾ മാത്രമേ ഇത് ഉൾക്കൊള്ളുന്നുള്ളൂ. net.ipv4.ip_forward ആ പട്ടികയിലുണ്ടോ എന്നത് kubelet എങ്ങനെ കോൺഫിഗർ ചെയ്തു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു, അതിന് പുറത്തുള്ള sysctl ആവശ്യപ്പെടുന്ന പോഡ് admission-ൽ നിരസിക്കപ്പെടുകയോ സാൻഡ്ബോക്സ് വീണ്ടും ശ്രമിക്കുമ്പോൾ CreateContainerConfigError-ൽ കുടുങ്ങുകയോ ചെയ്യുന്നു. ഫീൽഡ് തകർന്നതാണെന്ന് കരുതുന്നതിന് മുമ്പ് അനുവദനീയ പട്ടിക പരിശോധിക്കുക.

ഏതെങ്കിലും ഒരു സമീപനം കൈകൊണ്ട് നിർമ്മിക്കുന്നതിന് മുമ്പ്, chart ഇതിനകം സ്വിച്ച് വെളിപ്പെടുത്തുന്നുണ്ടോ നോക്കുക, പലപ്പോഴും ipForwardInitContainer: true പോലെ എന്തെങ്കിലും ആയി. chart മൂല്യം ഉപയോഗിക്കുന്നത് നിങ്ങളുടെ override ഫയൽ ചെറുതായി നിലനിർത്തുകയും അടുത്ത അപ്ഗ്രേഡിനെ അതിജീവിക്കുകയും ചെയ്യുന്നു, കൈകൊണ്ട് പാച്ച് ചെയ്ത Deployment മാറ്റങ്ങൾ അത് ചെയ്യുന്നില്ല.

രണ്ടാം പകുതി: മടങ്ങിവരവ് പാതയും നയവും

ഫോർവേഡിംഗ് ഓൺ ആയിരിക്കേണ്ടത് ആവശ്യമാണ്, പര്യാപ്തമല്ല. ക്ലയന്റുകൾ ക്ലസ്റ്റർ നെറ്റ്വർക്കിന് റൂട്ടില്ലാത്ത സ്വകാര്യ പൂൾ ഉപയോഗിക്കുന്നുവെങ്കിൽ, മറുപടികൾക്ക് തുരങ്കത്തിലേക്ക് തിരികെ വഴി കണ്ടെത്താനാകില്ല, കൂടാതെ പോഡ് ആ ട്രാഫിക്ക് അതിന്റെ ലക്ഷ്യത്തിലേക്ക് മാസ്ക് ചെയ്യണം.

നയം അതിന് മുകളിലാണ്. NetworkPolicy വസ്തുക്കളും ക്ലൗഡ് ഫയർവാൾ നിയമങ്ങളും വിവർത്തനത്തിന് ശേഷം പാക്കറ്റ് വഹിക്കുന്ന സ്രോതസ്സ് വിലാസത്തിനെതിരെ വിലയിരുത്തുന്നു, അതിനാൽ ക്ലയന്റ് പൂളിനായി എഴുതിയ ഒരു നിയമം മാസ്കിംഗ് പ്രവർത്തനക്ഷമമാകുമ്പോൾ നിശ്ശബ്ദമായി പൊരുത്തപ്പെടുന്നത് നിർത്തിയേക്കാം.

ക്ലയന്റുകൾക്ക് ക്ലസ്റ്ററിനുള്ളിലെ സേവനങ്ങളിൽ മാത്രം എത്തിച്ചേരേണ്ടതുണ്ടെങ്കിൽ, VPN സേവനത്തിന്റെ VIP-യിൽ അവസാനിപ്പിക്കുന്നത് പോഡ് നെറ്റ്വർക്കിലേക്ക് റൂട്ട് ചെയ്യുന്നതിനേക്കാൾ ചെറിയ രൂപകൽപ്പനയാണ്. ഇത് ക്ലയന്റ് പൂളിനെ CNI-യുടെ റൂട്ടിംഗ് ടേബിളിൽ നിന്ന് പൂർണ്ണമായും പുറത്ത് നിർത്തുന്നു.

പരാജയപ്പെടുന്ന ഹോപ്പ് ക്ലയന്റിൽ നിന്ന് വേർതിരിക്കുക

പുറത്തേക്ക് പ്രവർത്തിക്കുക, ആദ്യത്തെ നിശ്ശബ്ദ ഘട്ടത്തിൽ നിർത്തുക. VPN പിയറിൽ തുടങ്ങുക, പിന്നീട് ഏതെങ്കിലും പോഡിന്റെ വിലാസം ശ്രമിക്കുക, പിന്നീട് സേവന VIP, അതിനുശേഷം മാത്രം പൊതു ലക്ഷ്യം. ഓരോ വിജയവും അതിർത്തിയെ ഒരു ഹോപ്പ് നീക്കുന്നു, ഓരോ പരാജയവും പരിശോധിക്കേണ്ട പാളിയെ പേരിടുന്നു. ഏതെങ്കിലും റോൾഔട്ടിന് ശേഷം exec ചെയ്ത് അകത്തുകയറി sysctl വീണ്ടും വായിക്കുക, കാരണം മാറ്റിയ പോഡ് ഇമേജിന്റെ സ്ഥിരസ്ഥിതിയിൽ നിന്ന് തുടങ്ങുന്നു, മാനിഫെസ്റ്റിൽ ഒരിക്കലും ഉണ്ടായിരുന്നില്ലാത്ത തിരുത്ത് ഇതിനകം പോയിക്കഴിഞ്ഞു.

Kubernetes-ന്റെ ഡോക്യുമെന്റേഷൻ ക്ലസ്റ്ററിൽ sysctl ഉപയോഗിക്കുന്നത് സംബന്ധിച്ച് ഏത് പേരുകൾ പോഡ് സെക്യൂരിറ്റി കോൺടെക്സ്റ്റിലൂടെ സജ്ജമാക്കാം എന്ന് പട്ടികപ്പെടുത്തുന്നു, admission മാറ്റം നിരസിക്കുമ്പോൾ ആദ്യം നോക്കേണ്ടത് അവിടെയാണ്.