Kubernetes-ലെ VPN ക്ലയന്റ് IP: അത് സംരക്ഷിക്കണോ അതോ SNAT ചെയ്യണോ?
Kubernetes-ൽ VPN ക്ലയന്റിന്റെ യഥാർത്ഥ വിലാസവും സ്രോതസ്സ് NAT-ഉം തമ്മിൽ മൂന്ന് നിബന്ധനകളുടെ അടിസ്ഥാനത്തിൽ തിരഞ്ഞെടുക്കുക, തുടർന്ന് മടങ്ങിവരുന്ന പാതയും pod മാറ്റവും പരിശോധിക്കുക.
എവിടെയോ ടണലിനും backend-നും ഇടയിൽ ക്ലയന്റിന്റെ വിലാസം ഒന്നുകിൽ അതിജീവിക്കുന്നു അല്ലെങ്കിൽ മാറ്റിസ്ഥാപിക്കപ്പെടുന്നു, രണ്ട് ഫലങ്ങളും ന്യായീകരണീയമാണ്. തിരഞ്ഞെടുപ്പ് സ്വീകരിക്കുന്ന സേവനത്തിന്റെ ഉടമയുടേതാണ്, CNI ഇൻസ്റ്റാൾ ചെയ്തവരുടേതല്ല. ഓരോ ക്ലയന്റിനുമുള്ള അനുമതി, ക്വോട്ടകൾ അല്ലെങ്കിൽ ഓഡിറ്റ് രേഖകൾ പ്രധാനമാകുമ്പോൾ, വിലാസം എല്ലാ ഹോപ്പും കടക്കണം. പങ്കിട്ട ആരോപണം സ്വീകാര്യമാകുമ്പോൾ, സ്രോതസ്സ് NAT നിങ്ങൾ ഇല്ലെങ്കിൽ എന്നെന്നും പരിപാലിക്കേണ്ട ഒരു റൂട്ടിംഗ് പ്രശ്നം ഒഴിവാക്കുന്നു.
വിലാസം യഥാർത്ഥത്തിൽ എവിടെ അപ്രത്യക്ഷമാകുന്നു
ദൂരെയുള്ള ക്ലയന്റിന്റെ പാക്കറ്റ് VPN pod-ലേക്ക് ടണൽ പരിധിക്കുള്ളിലെ ആന്തരിക സ്രോതസ്സുമായി എത്തുന്നു, പറയട്ടെ 10.90.0.42. pod ആ പാക്കറ്റ് ClusterIP അല്ലെങ്കിൽ pod IP-യിലേക്ക് അയയ്ക്കുമ്പോൾ, മൂന്ന് വ്യത്യസ്ത സംവിധാനങ്ങൾക്ക് സ്രോതസ്സ് വീണ്ടും എഴുതാം. node-ന്റെ CNI masquerade നിയമം pod ക്ലസ്റ്റർ CIDR-ന് പുറത്തേക്ക് അയയ്ക്കുന്ന ട്രാഫിക് ഉൾക്കൊള്ളുന്നു. ലക്ഷ്യ node-ലെ kube-proxy-യുടെ conntrack എൻട്രി Service ഹോപ്പ് തന്നെ ഉൾക്കൊള്ളുന്നു. കണക്ഷൻ അവസാനിപ്പിക്കുന്ന പ്രോക്സി പാക്കറ്റ് അയയ്ക്കുന്നേയില്ല, അതിനാൽ അവസാനം നിങ്ങൾ കാണുന്ന സ്രോതസ്സ് പ്രോക്സിയുടേതാണ്.
ഇവയിൽ ഓരോന്നും വ്യത്യസ്ത പാളിയിൽ ജീവിക്കുന്നു, അതുകൊണ്ടാണ് ഒരു Service ഫീൽഡ് ഏതാണ്ട് ഒരിക്കലും മുഴുവൻ പാതയും ശരിയാക്കാത്തത്.
VPN-ന്റെ പൊതു Service-ൽ externalTrafficPolicy പുറത്തുള്ള കണക്ഷനെക്കുറിച്ച് മാത്രം തീരുമാനിക്കുന്നു: Local ദൂരെയുള്ള വിലാസം അത് സ്വീകരിച്ച node-ൽ നിലനിർത്തുന്നു, Cluster kube-proxy-യെ പാക്കറ്റ് മറ്റൊരു node-ന് നൽകാനും അവിടെ masquerade ചെയ്യാനും അനുവദിക്കുന്നു. ആ ക്രമീകരണം നിങ്ങളുടെ ക്ലയന്റുകൾ ബന്ധിപ്പിക്കുന്ന listener-നെ നിയന്ത്രിക്കുന്നു. നിങ്ങളുടെ VPN പ്രക്രിയ പിന്നീട് ക്ലസ്റ്ററിലേക്ക് അയയ്ക്കുന്ന ഡീക്രിപ്റ്റ് ചെയ്ത പാക്കറ്റിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല.
തർക്കം തീർക്കുന്ന മൂന്ന് നിബന്ധനകൾ
ഈ വിഷയം വരുമ്പോഴെല്ലാം അതേ മൂന്ന് ചോദ്യങ്ങൾ അതേ ക്രമത്തിൽ ഞാൻ ചോദിക്കുന്നു, കാരണം ആദ്യത്തേത് സാധാരണയായി ചർച്ച അവസാനിപ്പിക്കുന്നു. പ്രത്യേക ജോലിഭാരത്തിന് ഉത്തരം നൽകുക, മുഴുവൻ ക്ലസ്റ്ററിനല്ല. ഒരേ കമ്പനിയിലെ രണ്ട് ക്ലസ്റ്ററുകൾ വ്യത്യസ്ത ഉത്തരങ്ങളിൽ എത്താം, രണ്ടും ശരിയായിരിക്കാം.
| Question | Preserve | SNAT |
|---|---|---|
| Does the backend enforce policy per client? | Yes, the address is the identity | Only if a trusted proxy supplies identity |
| Can the cluster route 10.90.0.0/24 back to a stable gateway? | Required | Not needed |
| Is the workload a forwarder or a proxy? | Forwarder | Proxy is fine |
backend ആദ്യ ചോദ്യത്തിന് അതെ, രണ്ടാമത്തേതിന് ഇല്ല എന്ന് പറഞ്ഞാൽ, നിങ്ങൾക്ക് നെറ്റ്വർക്ക് ജോലിയാണുള്ളത്, manifest തിരുത്തലല്ല. മൂന്നാമത്തെ വരി പ്രോക്സി എന്ന് പറഞ്ഞാൽ, വിലാസം ഒരിക്കലും അതിജീവിക്കുമായിരുന്നില്ല, അതിന് വിപരീതം പറയുന്നത് ഒരാഴ്ചത്തെ പാക്കറ്റ് ക്യാപ്ചറിംഗ് ചെലവാണ്.
preserve മോഡ് നെറ്റ്വർക്കിൽ നിന്ന് ആവശ്യപ്പെടുന്നത്
സ്രോതസ്സ് സംരക്ഷിക്കുക എന്നാൽ ലക്ഷ്യ node ട്രാഫിക് സജീവമായ VPN ഗേറ്റ്വേ വഴി 10.90.0.42-ലേക്ക് തിരികെ അയയ്ക്കണം. VPN പൂൾ ക്ലസ്റ്റർ CIDR അല്ല, അതിനാൽ ഒരു CNI-യും അത് നിങ്ങൾക്കുവേണ്ടി സ്വതവേ റൂട്ട് ചെയ്യുന്നില്ല. നിങ്ങൾ തന്നെ റൂട്ട് ചേർത്ത്, അത് ചൂണ്ടുന്ന ഗേറ്റ്വേ അന്തിമബിന്ദു പുനർനിശ്ചയത്തെ അതിജീവിക്കുന്നുവെന്ന് ഉറപ്പാക്കുന്നു.
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2ആ അടുത്ത ഹോപ്പ് pod വിലാസമാണ്, pod വിലാസങ്ങൾ നീങ്ങുന്നു. റൂട്ട് Service VIP-ലേക്കോ സ്ഥിരമായി നിൽക്കുന്ന node വിലാസത്തിലേക്കോ തിരിക്കുക, അല്ലെങ്കിൽ ഓരോ പുറത്താക്കലിനും ശേഷം നിങ്ങൾ ഗേറ്റ്വേയെ പിന്തുടരുമെന്ന് സമ്മതിക്കുക. വിപരീത പാത ഫിൽട്ടറിംഗ് മറ്റൊരു കെണിയാണ്: കർശന മോഡ്, വന്ന ഇന്റർഫേസുമായി പൊരുത്തപ്പെടാത്ത മടങ്ങിവരവ് പാതയുള്ള പാക്കറ്റുകൾ വീഴ്ത്തുന്നു, ഇത് സംരക്ഷിത VPN പ്രവാഹത്തിന്റെ കൃത്യമായ രൂപമാണ്.
അയഞ്ഞ സാധൂകരണം പലപ്പോഴും പ്രവർത്തിക്കുന്ന മടങ്ങിവരവ് പാതയും backend വിട്ടതിന് ശേഷം അപ്രത്യക്ഷമാകുന്ന ഉത്തരങ്ങളും തമ്മിലുള്ള വ്യത്യാസമാണ്. VPN node-ലെ masquerade നിയമങ്ങളും ടണൽ പരിധി ഒഴിവാക്കണം, അല്ലെങ്കിൽ അയച്ച പാക്കറ്റ് pod-ന്റെ വിലാസത്തോടെ പുറത്തുപോകും, നിങ്ങൾ ഏത് റൂട്ട് നിർമ്മിച്ചാലും. ഈ ഒഴിവാക്കൽ iptables കൈകൊണ്ട് തിരുത്തുന്നതിന് പകരം CNI-യുടെ സ്വന്തം കോൺഫിഗറേഷനിൽ പ്രകടിപ്പിക്കുക, കാരണം ഏജന്റ് പുനരാരംഭത്തിൽ തന്റെ ശൃംഖലകൾ വീണ്ടും എഴുതുന്നു, നിങ്ങളുടെ കൈകൊണ്ട് എഴുതിയ നിയമം അടുത്ത അപ്ഗ്രേഡ് വരെ മാത്രം നിലനിൽക്കും.
NetworkPolicy പ്രവേശന നിയന്ത്രണമാണ്, റൂട്ടിംഗ് അല്ല. ഒരു നയം കർശനമാക്കുന്നത് masquerade ഇതിനകം മാറ്റിയ വിലാസം ഒരിക്കലും പുനഃസ്ഥാപിക്കില്ല.
SNAT-ന്റെ ചെലവ് എന്താണ്, അത് എങ്ങനെ രേഖപ്പെടുത്താം
ക്ലസ്റ്ററിലേക്കുള്ള സ്രോതസ്സ് NAT വിലകുറഞ്ഞ രൂപകൽപ്പനയാണ്, അത് തെറ്റല്ല. backend VPN pod-ന്റെയോ node-ന്റെയോ വിലാസം കാണുന്നു, ലോഗുകൾ പരസ്പരം ഒത്തുപോകുന്നു, മടങ്ങിവരവ് റൂട്ട് ഉണ്ടായിരിക്കേണ്ടതില്ല. നിങ്ങൾ നഷ്ടപ്പെടുത്തുന്നത് നെറ്റ്വർക്ക് പാളിയിൽ രണ്ട് ക്ലയന്റുകളെ വേർതിരിച്ചറിയാനുള്ള കഴിവാണ്, അതിനാൽ ക്വോട്ട, വിലക്കുകൾ, ഓഡിറ്റ് അടയാളങ്ങൾ മറ്റെവിടെനിന്നോ വരണം.
സാധാരണയായി ആ മറ്റെവിടെ എന്നത് അപ്ലിക്കേഷനാണ്: സെഷൻ ടോക്കൺ, ഒപ്പിട്ട ഹെഡർ, അല്ലെങ്കിൽ നിങ്ങൾ നിയന്ത്രിക്കുന്ന പ്രോക്സി എഴുതുന്ന PROXY പ്രോട്ടോക്കോൾ വരി. ഇവ സ്വീകർത്താവിന്, പ്രോക്സി പാതയിലുള്ളപ്പോഴും ഹെഡർ ക്ലയന്റ് ഭാഗത്തുനിന്ന് സജ്ജമാക്കാൻ കഴിയാത്തപ്പോഴും മാത്രം വിശ്വസിക്കാവുന്ന ഒരു ഐഡന്റിറ്റി നൽകുന്നു. runbook-ൽ ഏതാണ് ബാധകമെന്ന് വ്യക്തമാക്കുക, കാരണം അടുത്ത എൻജിനീയർ ലോഗിലെ വിലാസമാണ് ക്ലയന്റ് എന്ന് അനുമാനിക്കും. അല്ല, ഒരു സംഭവം ആ അനുമാനത്തെ ചെലവേറിയതാക്കാൻ മതി.
ഈ കൈമാറ്റം എഴുതപ്പെട്ടിരിക്കുന്നിടത്തോളം സത്യസന്ധമായി തുടരും.
പ്രവർത്തിക്കുന്ന പാതയെ ഭാഗ്യമുള്ള പാതയിൽ നിന്ന് വേർതിരിക്കുന്ന പരിശോധനകൾ
പുതിയ കണക്ഷൻ ഉപയോഗിച്ച് പരിശോധിക്കുക, കാഷ് ചെയ്ത കണക്ഷൻ ഉപയോഗിച്ചല്ല, രണ്ട് ദിശകളിലും പരിശോധിക്കുക. പല പരാജയങ്ങളും ഇടയ്ക്കിടെയെന്ന് തോന്നുന്നത് പുതിയ പ്രവാഹങ്ങൾ വീണ്ടും എഴുതിയ പാത സ്വീകരിക്കുന്നതുകൊണ്ടാണ്.
ഒരു അനുവദനീയമായ അഭ്യർത്ഥനയ്ക്കിടയിൽ tuple മൂന്ന് സ്ഥലങ്ങളിൽ പിടിക്കുക: ഡീക്രിപ്ഷന് ശേഷം ഉടൻ, VPN pod-ന്റെ പുറത്തുകടക്കൽ ഇന്റർഫേസിൽ, ഒപ്പം backend-ൽ. രണ്ടാമത്തെയും മൂന്നാമത്തെയും പിടുത്തത്തിനിടയിൽ സ്രോതസ്സ് മാറുന്നുവെങ്കിൽ, കാരണം pod-ന് താഴെയാണ്. രണ്ടാമത്തേതിന് മുമ്പ് മാറുന്നുവെങ്കിൽ, pod തന്നെ വിവർത്തനം ചെയ്യുന്നു.
തുടർന്ന് VPN pod ഇല്ലാതാക്കി പുനർനിശ്ചയത്തിനിടയിൽ പരീക്ഷണം ആവർത്തിക്കുക. പുറത്താക്കലിൽ ഒടിയുന്ന സംരക്ഷിത പാത അപൂർണമാണ്, ഇപ്പോൾ നിലവിലില്ലാത്ത വിലാസത്തിൽ പിന്നിട്ട NAT നിയമവും അങ്ങനെതന്നെ. അവസാനം, നിരസിക്കപ്പെടുമെന്ന് നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന സ്രോതസ്സിൽ നിന്ന് ഒരു അഭ്യർത്ഥന അയച്ച്, നിരസിക്കൽ നയത്തിൽ നിന്നാണോ കാണാത്ത റൂട്ടിൽ നിന്നല്ലേ എന്ന് സ്ഥിരീകരിക്കുക.