നിങ്ങളുടെ VPN പ്രോസസ്സിന് ഏത് Linux കഴിവുകളാണ് വേണ്ടത്?
ഇന്റർഫേസ് സെറ്റപ്പ്, റൂട്ടുകൾ, ഉപകരണ ആക്സസ്, സാധാരണ സോക്കറ്റുകൾ എന്നിവ വെവ്വേറെ അധികാരങ്ങളാണ്. CAP_NET_ADMIN നൽകുന്നതിന് മുമ്പ് പരാജയപ്പെട്ട പ്രവർത്തനം പേരിടുക.
VPN ഡീമണിന് പ്രത്യേക അധികാരമുള്ള നെറ്റ്വർക്ക് പ്രവർത്തനങ്ങൾ ആവശ്യമാണ്, എന്നാൽ സാധാരണ ആപ്ലിക്കേഷനുകൾ ഒരു അധികാരവുമില്ലാതെ പുറത്തേക്കുള്ള സോക്കറ്റുകൾ തുറക്കുന്നു. ആ വിടവിൽ നിന്നാണ് മിക്ക കഴിവ് പിശകുകളും തുടങ്ങുന്നത്: ആരോ അനുമതി പിശക് കാണുന്നു, മുഴുവൻ സെറ്റും നൽകുന്നു, പിന്നീട് ആർക്കും വിശദീകരിക്കാനാകാത്ത കാരണങ്ങളാൽ സേവനം പ്രവർത്തിക്കുന്നു. ചുവടെയുള്ള വിശദീകരണം പരാജയപ്പെട്ട പ്രവർത്തനത്തിൽ നിന്ന് ആരംഭിച്ച് അതിനെ ഒരു അധികാരവുമായി ബന്ധിപ്പിക്കുന്നു, തുടർന്ന് പ്രോസസ്സ് യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്ന സന്ദർഭം പരിശോധിക്കുന്നു. പരിധിയില്ലാത്ത root ആയി പ്രവർത്തിക്കുന്നത് ചില വിന്യാസങ്ങൾക്ക് സാധുവായ ഉത്തരമാണ്, പക്ഷേ അത് സ്ഥിരസ്ഥിതിയല്ല, തീരുമാനമായിരിക്കണം.
പരാജയപ്പെട്ട പ്രവർത്തനത്തിൽ നിന്ന് തുടങ്ങുക
ട്യൂട്ടോറിയൽ വായിക്കുന്നതിന് മുമ്പ് പിശക് വായിക്കുക. ഇന്റർഫേസ് മാറ്റത്തിലെ «പ്രവർത്തനം അനുവദനീയമല്ല», ഉപകരണ നോഡ് തുറക്കാനുള്ള നിരസനം, താഴ്ന്ന പോർട്ടിലെ bind പരാജയം — ഇവ മൂന്ന് വ്യത്യസ്ത അനുമതികളുള്ള മൂന്ന് വ്യത്യസ്ത പ്രശ്നങ്ങളാണ്. പ്രോസസ്സ് ആരംഭിച്ച് ആദ്യ റൂട്ട് മാറ്റത്തിൽ മാത്രം പരാജയപ്പെട്ടാൽ, ഇന്റർഫേസ് നിർമ്മാണം ഇതിനകം വിജയിച്ചു എന്നും അത് പറയുന്നു, ഇത് ഉത്തരത്തെ വളരെ ചുരുക്കുന്നു.
സേവനം നിർത്തിയ അവസ്ഥയിൽ പരാജയം പുനർനിർമ്മിക്കുക, തുടർന്ന് നടപ്പാക്കൽ അനുവദിക്കുന്നെങ്കിൽ അതേ ഉപയോക്താവിന് കീഴിൽ മുൻപിലായി ആരംഭിക്കുക. നിങ്ങൾ കാണുന്ന പിശക് ഊഹിക്കേണ്ട ലോഗ് വരിയേക്കാൾ നല്ലതാണ്, കൂടാതെ കഴിവ് പ്രശ്നവും SELinux അല്ലെങ്കിൽ AppArmor നിരസനവും തമ്മിലുള്ള വ്യത്യാസം അത് വ്യക്തമാക്കുന്നു.
ഓരോ പ്രവർത്തനത്തെയും ഒരു അധികാരവുമായി ബന്ധിപ്പിക്കുക
പട്ടിക ഒരു തുടക്ക മാപ്പാണ്, നടപ്പാക്കലിന്റെ ഡോക്യുമെന്റേഷന് പകരമല്ല:
| Operation | Usual authority | Watch for |
|---|---|---|
| Create or configure tun/tap | CAP_NET_ADMIN in the relevant namespace | Creating the device and opening it are separate steps |
| Add routes, rules, firewall entries | CAP_NET_ADMIN | Same capability, different namespace than you think |
| Open /dev/net/tun | Device permissions, not a capability | Group membership or a udev rule may be enough |
| Raw sockets | CAP_NET_RAW | Needed by some user-space tunnel implementations |
| Bind a port below 1024 | CAP_NET_BIND_SERVICE | Irrelevant for most modern tunnel ports |
ആ പട്ടികയിലെ രണ്ട് വരികളാണ് ആളുകൾ കൂട്ടിക്കുഴയ്ക്കുന്നത്. /dev/net/tun തുറക്കുന്നത് ഫയൽ അനുമതിയുടെ ചോദ്യമാണ്; നിങ്ങൾ തുറന്നത് ക്രമീകരിക്കാൻ കേർണലിനോട് ആവശ്യപ്പെടുന്നത് കഴിവിന്റെ ചോദ്യമാണ്. CAP_NET_ADMIN നൽകുന്നത് നിങ്ങളുടെ സേവന ഉപയോക്താവിന് വായിക്കാനാകാത്ത ഉപകരണ നോഡ് ശരിയാക്കുന്നില്ല, നോഡ് ശരിയാക്കുന്നത് നിങ്ങൾക്ക് റൂട്ട് അധികാരം നൽകുന്നുമില്ല. ഇവയിൽ ഏതെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് രണ്ടും പരിശോധിക്കുക.
കേർണൽ WireGuard-നും ഉപയോക്തൃ സ്ഥലത്തെ ടണൽ പ്രോഗ്രാമുകൾക്കും ഒരേ ആവശ്യകതകളല്ല. കേർണൽ മൊഡ്യൂൾ പാത netlink വഴി നിലവിലുള്ള ഇന്റർഫേസ് ക്രമീകരിക്കുന്നു, അതേസമയം ഉപയോക്തൃ സ്ഥലത്തെ നടപ്പാക്കലിന് ഉപകരണവും ചില ഗതാഗതങ്ങൾക്ക് അസംസ്കൃത സോക്കറ്റുകളും ആവശ്യമായേക്കാം.
സന്ദർഭം വായിക്കുക: സേവനം, കണ്ടെയ്നർ അല്ലെങ്കിൽ ഷെൽ
ഹോസ്റ്റിന്റെ നെറ്റ്വർക്ക് നെയിംസ്പേസിലെ ഒരു കഴിവ് ബോധപൂർവം വേർതിരിച്ച സ്റ്റാക്കിലെ അതേ പ്രവർത്തനത്തേക്കാൾ വളരെയധികം സ്വാധീനിക്കാം. കണ്ടെയ്നർ റൺടൈം സാധാരണയായി ചുരുക്കിയ ബൗണ്ടിംഗ് സെറ്റോടെ ആരംഭിക്കുന്നു; ഹോസ്റ്റ് നെറ്റ്വർക്ക് പങ്കിടുന്ന കണ്ടെയ്നറിലേക്ക് NET_ADMIN ചേർക്കുന്നത് സ്വന്തം നെറ്റ്വർക്ക് നെയിംസ്പേസും ഹോസ്റ്റ് മൗണ്ടുകളുമില്ലാത്ത കണ്ടെയ്നറിലേക്ക് ചേർക്കുന്നതിനേക്കാൾ വളരെ വലിയ അനുമതിയാണ്.
systemd യൂണിറ്റുകൾക്ക് യൂണിറ്റ് ഫയൽ പറയുന്നതായി തോന്നുന്നതല്ല, യഥാർത്ഥത്തിൽ പ്രയോഗിക്കുന്നത് വായിക്കുക: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities ഫലപ്രദമായ മൂല്യങ്ങൾ റിപ്പോർട്ട് ചെയ്യുന്നു, അവ നിങ്ങൾ മറന്ന drop-in സെറ്റ് ചെയ്തിരിക്കാം. ഫലപ്രദമായ മൂല്യം ചോദിക്കുക, ഉദ്ദേശിച്ചത് ഒരിക്കലുമരുത്. Ambient കഴിവുകൾ പ്രധാനമാണ്, കാരണം root അല്ലാത്ത സേവനം അവയില്ലാതെ exec വഴി കഴിവുകൾ നഷ്ടപ്പെടുന്നു.
പാക്കേജിന്റെയോ ഇമേജിന്റെയോ പിന്തുണയുള്ള സെറ്റപ്പ് അടിസ്ഥാനമാക്കുക. മറ്റൊരു ട്യൂട്ടോറിയൽ മറ്റൊരു ഉപകരണത്തിനായി അവ പട്ടികപ്പെടുത്തിയതിനാൽ അസംസ്കൃത സോക്കറ്റ് അനുമതികളോ പ്രത്യേക മോഡോ ചേർക്കരുത്; ആ യുക്തി ഒന്നും കൈമാറുന്നില്ല, നിങ്ങൾ നൽകിയ വേർതിരിവ് അത് നഷ്ടപ്പെടുത്തുന്നു. സംശയമുണ്ടെങ്കിൽ ഒന്നും നൽകരുത്, ആവശ്യമായ കൃത്യമായ പ്രവർത്തനത്തിനായി നടപ്പാക്കലിന്റെ കുറിപ്പുകൾ വായിക്കുക.
അധികാരങ്ങൾ കുറഞ്ഞതിന് ശേഷം എന്ത് സംഭവിക്കുന്നു എന്ന് നിരീക്ഷിക്കുക
പല ഡീമണുകളും അധികാരത്തോടെ തുടങ്ങി ഇന്റർഫേസ് ക്രമീകരിച്ച്, പിന്നീട് അധികാരമില്ലാത്ത ഉപയോക്താവിലേക്ക് മാറി ടണൽ നിലനിർത്തുന്നു. ആ നിമിഷം മുതൽ പ്രോസസ്സിന് റൂട്ട് ചേർക്കാനോ ഫയർവാൾ നിയമം മാറ്റിയെഴുതാനോ പുതിയ പ്രത്യേക ഉപകരണം തുറക്കാനോ കഴിയില്ല, വീണ്ടും കണക്റ്റ് ചെയ്യുമ്പോൾ കൃത്യമായി അത് ആവശ്യമാകുന്നത് വരെ ഇത് കുഴപ്പമില്ല. പിന്നീടുള്ള ഫയൽ വായനയും ഹുക്ക് പ്രവർത്തനവും അതേ കാരണത്താൽ പരാജയപ്പെടാം.
ആദ്യ സെക്കൻഡല്ല, മുഴുവൻ ജീവിതചക്രം പരിശോധിക്കുക: ആരംഭം, പുതുക്കൽ അല്ലെങ്കിൽ വീണ്ടും കണക്റ്റ്, നിർത്തുമ്പോൾ വൃത്തിയാക്കൽ. ഇന്റർഫേസ് ആദ്യമായി വിജയകരമായി സൃഷ്ടിച്ചത് തുടർന്നുള്ള എല്ലാ പ്രത്യേക പ്രവർത്തനങ്ങളും പ്രവർത്തിക്കുമെന്ന് തെളിയിക്കുന്നില്ല, പരാജയം സാധാരണയായി ഉൽപാദനത്തിൽ മണിക്കൂറുകൾക്ക് ശേഷം പ്രത്യക്ഷപ്പെടുന്നു.
ഉപയോക്തൃ മാറ്റത്തിലുടനീളം ടണൽ തുറന്ന് സൂക്ഷിക്കുന്ന നടപ്പാക്കലുകൾ സാധാരണയായി അതിനെ ടണലും കീകളും നിലനിർത്താനുള്ള ഓപ്ഷനുകളുമായി ജോടിയാക്കുന്നു. systemd ഭാഗത്ത് തുല്യമായ ചോദ്യം, യൂണിറ്റിന്റെ കഴിവ് സെറ്റ് നിങ്ങൾ ക്രമീകരിച്ച ഉപയോക്തൃ മാറ്റത്തെ അതിജീവിക്കുന്നുണ്ടോ എന്നതാണ്.
നൽകിയ അനുമതിയും അതിന്റെ കാരണവും രേഖപ്പെടുത്തുക
കൃത്യമായ അനുമതി, അത് സാധ്യമാക്കുന്ന പ്രവർത്തനം, അത് പരിഹരിച്ച പിശക് എന്നിവ എഴുതുക. വിന്യാസ കുറിപ്പുകളിലെ ഒരു വരി — «യൂണിറ്റിന്റെ നെറ്റ്വർക്ക് നെയിംസ്പേസിലെ CAP_NET_ADMIN, വീണ്ടും കണക്റ്റ് ചെയ്തതിന് ശേഷമുള്ള റൂട്ട് മാറ്റങ്ങൾക്ക് ആവശ്യം» — അടുത്ത വ്യക്തി അനുമതി വീണ്ടും വിപുലീകരിക്കുന്നത് തടയാൻ മതി.
തുടർന്ന് ഓരോ അപ്ഗ്രേഡിനും ശേഷം ഫലപ്രദമായ സെറ്റ് വീണ്ടും വായിക്കുക. വിൽപ്പനക്കാർ സവിശേഷതകൾ ചേർക്കുന്നു, ഇമേജുകൾ സ്ഥിരസ്ഥിതികൾ മാറ്റുന്നു, കഴിഞ്ഞ വർഷം അനാവശ്യമായിരുന്ന ഒരു കഴിവ് ആരും ശ്രദ്ധിക്കാതെ വാഹകമായി മാറാം.