VPN കണ്ടെയ്നറിൽ NET_ADMIN: എന്ത്, എവിടെ മാറ്റാം

NET_ADMIN ഒരു പ്രോസസിനെ നെറ്റ്വർക്ക് ഭരണം നടത്താൻ അനുവദിക്കുന്ന ലിനക്സ് കഴിവാണ്, കണ്ടെയ്നറിൽ അത് പ്രോസസ് പ്രവർത്തിക്കുന്ന നെറ്റ്വർക്ക് നാമസ്ഥലത്തിനുള്ളിൽ കൃത്യമായി അതാണ് ചെയ്യുന്നത്. ഇത് സോക്കറ്റ് തുറക്കാനുള്ള അനുമതിയല്ല, ഉപകരണത്തിന്റെയോ റൂട്ടിന്റെയോ പകരമല്ല. രസകരമായ ചോദ്യം എപ്പോഴും കഴിവ് നൽകിയോ എന്നതല്ല, മറിച്ച് ഏത് നാമസ്ഥലമാണ് മാറ്റം സ്വീകരിക്കുന്നത് എന്നതാണ്.

കഴിവ് എന്തെല്ലാം ഉൾക്കൊള്ളുന്നു

സ്വന്തം നാമസ്ഥലത്തിനുള്ളിൽ NET_ADMIN ഉള്ള ഒരു പ്രോസസിന് ഇന്റർഫേസുകൾ ഉയർത്താനും താഴ്ത്താനും വിലാസങ്ങൾ അനുവദിക്കാനും റൂട്ടുകൾ ചേർക്കാനും നീക്കാനും ഫയർവാൾ നിയമങ്ങൾ എഴുതാനും കഴിയും, ഇത് capabilities(7) ഈ കഴിവിന് കീഴിൽ ശേഖരിക്കുന്ന പ്രവർത്തനങ്ങളുടെ കൂട്ടമാണ്. കെർണൽ ട്രാഫിക് എങ്ങനെ ക്യൂവിൽ നിർത്തി ഫിൽട്ടർ ചെയ്യുന്നു എന്ന് നിയന്ത്രിക്കുന്ന ഇന്റർഫേസ് തലത്തിലുള്ള ക്രമീകരണങ്ങളും ഇതിന് ക്രമീകരിക്കാം. VPN ക്ലയന്റിന് സാധാരണയായി തുടക്കത്തിൽ ഇവയിൽ കുറച്ച് വേണം, പിന്നീട് മറ്റൊന്നും വേണ്ട. അതിനാൽ മിക്ക ഇമേജുകളും ഉപയോഗിക്കുന്നതിലും കൂടുതൽ പരിധി ആവശ്യപ്പെടുന്നു.

ആ നാമസ്ഥലത്തിന് പുറത്തുള്ള പ്രവർത്തനങ്ങൾ ഉൾക്കൊള്ളുന്നില്ല, അടുത്തുള്ള പ്രത്യേകാവകാശങ്ങൾ വെവ്വേറെയാണ്. അസംസ്കൃത പാക്കറ്റുകൾ വായിക്കുന്നതും എഴുതുന്നതും NET_RAW ന് സ്വന്തമാണ്, tun ഉപകരണം സൃഷ്ടിക്കാൻ കഴിവും ഉപകരണ നോഡിലേക്കുള്ള പ്രവേശനവും രണ്ടും വേണം. ഉപകരണമില്ലാത്ത പ്രോസസിന് നെറ്റ്വർക്ക് പ്രശ്നം പോലെ തോന്നുന്ന, പക്ഷേ അല്ലാത്ത അനുമതി പിശക് ലഭിക്കുന്നു.

നാമസ്ഥലമാണ് നാശത്തിന്റെ ആരം നിർണ്ണയിക്കുന്നത്

സ്വന്തം ബ്രിഡ്ജ് നെറ്റ്വർക്കിലുള്ള കണ്ടെയ്നർ സ്വന്തം loopback, സ്വന്തം ഇന്റർഫേസുകൾ, സ്വന്തം റൂട്ടിംഗ് പട്ടിക എന്നിവയിൽ എത്തുന്നു. അവിടെ NET_ADMIN നൽകിയാൽ VPN ക്ലയന്റിന് ഹോസ്റ്റിന്റെ റൂട്ടിംഗ് തീരുമാനങ്ങൾ തൊടാതെ ടണൽ നിർമ്മിക്കാം, ഇതാണ് മിക്ക കണ്ടെയ്നർ ഇമേജുകളും അനുമാനിക്കുന്ന ക്രമീകരണം.

ആ കണ്ടെയ്നർ ഹോസ്റ്റ് നെറ്റ്വർക്കിംഗിലേക്ക് മാറ്റുക, അപ്പോൾ അതേ അനുമതി ഇപ്പോൾ ഹോസ്റ്റിന്റെ റൂട്ടുകളും ഹോസ്റ്റിന്റെ ഫയർവാളും തിരുത്തുന്നു, കാരണം വേറെ നാമസ്ഥലം ബാക്കിയില്ല. ഒരു ടണൽ കൈകാര്യം ചെയ്യേണ്ടിയിരുന്ന ക്ലയന്റിന് ഇപ്പോൾ മുഴുവൻ യന്ത്രത്തിന്റെയും ട്രാഫിക് വഴിതിരിച്ചുവിടാം, അതിന്റെ ടിയർഡൗൺ സ്ക്രിപ്റ്റിലെ പിഴവ് ഹോസ്റ്റിൽ ആരും എഴുതാത്ത നിയമങ്ങൾ ബാക്കിവെക്കുന്നു. കഴിവിൽ തന്നെ ഒന്നും മാറിയില്ല; സന്ദർഭം മാറി. അതുകൊണ്ടാണ് ഒരേ compose ഫയൽ രണ്ട് ഹോസ്റ്റുകളിൽ വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നത്.

ഒന്നായി ചേരുന്ന മൂന്ന് മുൻവ്യവസ്ഥകൾ

VPN കണ്ടെയ്നറുകളിലെ സ്റ്റാർട്ടപ്പ് പരാജയങ്ങൾ സാധാരണയായി മൂന്ന് വെവ്വേറെ കാര്യങ്ങളിൽ ഒന്നിനെ ബാധിക്കുന്നു: കഴിവ്, ടണൽ ഉപകരണം, പ്രോട്ടോക്കോളിനുള്ള കെർണൽ പിന്തുണ. മൂന്നും ഒരുമിച്ച് നൽകുന്നത് പ്രവർത്തിക്കും, അടുത്ത പരാജയം ആരോപിക്കാനാകാത്തതുമാക്കും. ഏറ്റവും ചെറിയ compose ഭാഗം കഴിവ് നൽകി ഉപകരണ നോഡ് വ്യക്തമായി കൈമാറുന്നു:

services:
  vpn:
    image: example/vpn-client:latest
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1

ഏത് sysctl വേണമെന്ന് ഇമേജിന്റെ സ്വന്തം ഡോക്യുമെന്റേഷനിൽ വായിക്കുക, കാരണം കണ്ടെയ്നറിലെ sysctl ന് അധിക പ്രത്യേകാവകാശമോ ഹോസ്റ്റ് തലത്തിലുള്ള ക്രമീകരണമോ ആവശ്യമായി വരാം. ഇമേജ് ഉപയോക്തൃ സ്ഥല മോഡ് മാത്രം പിന്തുണയ്ക്കുന്നിടത്ത് ഉപകരണം ഒട്ടും വേണ്ട, കഴിവുകളുടെ പട്ടിക അതനുസരിച്ച് ചെറുതാകുന്നു.

മോഡല്ല, സങ്കുചിത പ്രവർത്തനം നൽകുക

പ്രത്യേകാവകാശ മോഡ് ഓരോ കഴിവും കൈമാറി അതേ സമയം ഉപകരണ പ്രവേശനം വിശാലമാക്കുന്നു, അതിനാൽ മൂന്ന് മുൻവ്യവസ്ഥകളിൽ ഏതാണ് കുറവെന്ന് അത് മറയ്ക്കുന്നു. കണ്ടെയ്നറിന്റെ പരാജയ രീതികളെ ഹോസ്റ്റ് മാറ്റങ്ങളിൽ നിന്ന് വേർതിരിച്ചറിയാനാകാത്തതുമാക്കുന്നു. എഴുതാൻ നീളമുണ്ടെങ്കിലും വ്യക്തമായ പട്ടികയ്ക്ക് മുൻഗണന നൽകുക.

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

രഹസ്യങ്ങൾ വേറെ തീരുമാനത്തിന്റെ ഭാഗമാണ്. NET_ADMIN കൈവശം വെക്കുന്നത് ക്ലയന്റ് ഏത് പിയർ ഐഡന്റിറ്റി അവതരിപ്പിക്കുന്നു, ഏത് ക്രെഡൻഷ്യലുകൾ ലോഡ് ചെയ്യുന്നു, അവ എങ്ങനെ കറക്കുന്നു എന്നിവയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. നെറ്റ്വർക്ക് ഭരണം വിശ്വാസം നൽകുന്നില്ല.

മാറ്റം പരിശോധിച്ച് അനുമതി എന്തിനാണെന്ന് രേഖപ്പെടുത്തുക

ടണൽ ഡീബഗ് ചെയ്യുന്നതിന് മുമ്പ് കണ്ടെയ്നറിന് യഥാർത്ഥത്തിൽ എന്ത് ലഭിച്ചു എന്ന് സ്ഥിരീകരിക്കുക. താഴെയുള്ള പരിശോധന ചേർത്ത കഴിവുകളും നെറ്റ്വർക്ക് മോഡും റിപ്പോർട്ട് ചെയ്ത്, ഉള്ളിൽ നിന്ന് ഇന്റർഫേസ് പട്ടിക എങ്ങനെ കാണുന്നു എന്ന് കാണിക്കുന്നു:

docker inspect --format '{{.HostConfig.CapAdd}} {{.HostConfig.NetworkMode}} {{.HostConfig.Privileged}}' vpn
docker exec vpn sh -c 'grep CapEff /proc/self/status'
docker exec vpn ip -br addr
docker exec vpn ip route

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

ടിയർഡൗൺ പാതയും പരിശോധിക്കുക, കാരണം ഫയർവാൾ നിയമങ്ങൾ എഴുതുന്ന ക്ലയന്റ് അവ പിന്നിൽ വിട്ടേക്കാം. കണ്ടെയ്നർ നിർത്തി ഹോസ്റ്റ് നെറ്റ്വർക്കിംഗ് ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ ഹോസ്റ്റിന്റെ നിയമ സമുച്ചയം വീണ്ടും പരിശോധിക്കുക. തുടക്കത്തിൽ രണ്ട് സെക്കൻഡ് മാത്രം ആവശ്യമുള്ള അനുമതിയെ അത് വിശദീകരിക്കുന്ന കുറിപ്പില്ലാതെ compose ഫയലിൽ സ്ഥിരമായ ആവശ്യകതയായി വിവരിക്കരുത്.

ഓരോ കഴിവിനും അടുത്ത് കാരണം എഴുതുക: ഏത് പ്രവർത്തനത്തിന് അത് വേണ്ടിയിരുന്നു, അതില്ലാതെ എന്ത് പരാജയപ്പെടുന്നു. ആ കുറിപ്പ് ഇമേജ് അപ്ഡേറ്റുകൾക്ക് ശേഷവും നിലനിൽക്കുന്നു, അതാണ് അവലോകനം ചെയ്ത പ്രത്യേകാവകാശ പട്ടികയും പകർത്തി ഒട്ടിച്ച് വളർന്ന പട്ടികയും തമ്മിലുള്ള വ്യത്യാസം.