VPN-ന് ആവശ്യമുള്ളതിനേക്കാൾ പ്രിവിലേജ് മോഡ് വിശാലമാകുന്നത് എന്തുകൊണ്ട്

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

ഫ്ലാഗ് യഥാർത്ഥത്തിൽ മാറ്റുന്നത് എന്ത്

പ്രിവിലേജുള്ള കണ്ടെയ്നറിന് വിശാലമായ കഴിവുകളും ഹോസ്റ്റ് ഉപകരണങ്ങളിലേക്കുള്ള പ്രവേശനവും ലഭിക്കുന്നു, ഇത് നെറ്റ്വർക്ക് പാത ആവശ്യപ്പെടുന്നതിനേക്കാൾ വളരെ വലിയ അനുമതിയാണ്. കൃത്യമായ കൂട്ടം നാടോടിക്കഥയല്ല, റൺടൈം രേഖപ്പെടുത്തുന്നു, കൂടാതെ Docker-ന്റെ കണ്ടെയ്നർ പ്രവർത്തിപ്പിക്കുന്നതിനുള്ള രേഖകൾ ലഭ്യമായ പ്രിവിലേജ് ഓപ്ഷനുകൾ വിവരിക്കുന്നു. ഒരിക്കൽ വായിച്ചാൽ ടണൽ മൊത്തത്തിന്റെ ചെറിയ ഭാഗമാണെന്ന് കാണാൻ മതി.

രണ്ട് ഇടുങ്ങിയ ആവശ്യകതകൾ മിക്ക VPN കണ്ടെയ്നറുകളെയും ഉൾക്കൊള്ളുന്നു. ഒരു ഇന്റർഫേസ് കോൺഫിഗർ ചെയ്യാൻ നെറ്റ്വർക്ക് അഡ്മിനിസ്ട്രേഷൻ കഴിവ് വേണം, ടണൽ ഉപകരണം തുറക്കാൻ ആ നിർദ്ദിഷ്ട ഉപകരണ നോഡിലേക്കുള്ള പ്രവേശനം വേണം. ഇവ വെവ്വേറെ അനുമതികളാണ്, രണ്ടും ഒരുമിച്ച് നൽകിയാലും അത് സർവവ്യാപിയായ ഓപ്ഷനേക്കാൾ ഇടുങ്ങിയതാണ്. പ്രിവിലേജ് കൂട്ടത്തിന്റെ ബാക്കി ഭാഗത്തിന് ടണലുമായി യാതൊരു ബന്ധവുമില്ല. ഹോസ്റ്റ് തലത്തിലുള്ള പ്രവേശനം യഥാർത്ഥത്തിൽ ആവശ്യമുള്ള ജോലിഭാരങ്ങൾക്കാണ് ഇത് ഉള്ളത്, VPN കണ്ടെയ്നർ സാധാരണയായി അവയിലൊന്നല്ല.

ഓരോ പിശകിനെയും ഒരു മുൻവ്യവസ്ഥയുമായി ചേർക്കുക

പിശക് സന്ദേശം അടിച്ചമർത്തുന്നതിന് മുൻപ് വായിച്ചാൽ ഏത് മുൻവ്യവസ്ഥയാണ് കുറവെന്ന് പറയും. ഉപകരണ നോഡിനെക്കുറിച്ചുള്ള സന്ദേശം ഉപകരണത്തെ പേരിടുന്നു, അനുവദിക്കാത്ത പ്രവർത്തനത്തെക്കുറിച്ചുള്ള സന്ദേശം ഒരു കഴിവിനെ പേരിടുന്നു, മൊഡ്യൂളിനെയോ sysctl-നെയോ കുറിച്ചുള്ള സന്ദേശം കർണൽ പിന്തുണയെ പേരിടുന്നു. ഇവയിൽ ഓരോന്നിനും വ്യത്യസ്ത പരിഹാരമുണ്ട്, അവയിൽ ഒന്ന് മാത്രമാണ് കഴിവ്.

കുറവായ കോൺഫിഗറേഷൻ ഫയൽ എല്ലാ കഴിവുകളും നൽകിയ ശേഷവും കുറവായി തുടരുന്നു, അതുകൊണ്ടാണ് പ്രിവിലേജ് മോഡ് ചിലപ്പോൾ ഒന്നും തന്നെ മാറ്റാത്തത്. കണ്ടെയ്നർ തുടങ്ങുന്നു, ടണൽ ഇപ്പോഴും പരാജയപ്പെടുന്നു, യഥാർത്ഥ പിശക് ഒരിക്കലും അനുമതികളെക്കുറിച്ചായിരുന്നില്ല. കർണൽ പിന്തുണ മൂന്നാമത്തെ കേസാണ്, തെറ്റായി വായിക്കാൻ ഏറ്റവും എളുപ്പമുള്ളതും. ഹോസ്റ്റിൽ ലോഡ് ചെയ്യാത്ത മൊഡ്യൂൾ പ്രിവിലേജില്ലാത്ത കണ്ടെയ്നറിനുള്ളിൽ നിന്ന് ലോഡ് ചെയ്യാൻ കഴിയില്ല, കണ്ടെയ്നറിനുള്ളിൽ കൂടുതൽ കഴിവുകൾ നൽകുന്നത് ഹോസ്റ്റിന്റെ അവസ്ഥ മാറ്റുന്നില്ല.

ലക്ഷണമല്ല, ആവശ്യകത പരിശോധിക്കുക

ഇമേജ് രേഖപ്പെടുത്തുന്ന ഏറ്റവും കുറഞ്ഞ വിളിയിൽ നിന്ന് തുടങ്ങി അത് പ്രവർത്തിപ്പിച്ച് പരാജയത്തിന്റെ കൃത്യമായ പാഠം സൂക്ഷിക്കുക. പിന്നീട് ഒരു സമയം ഒരു അനുമതി ചേർത്ത് ഏത് കൂട്ടിച്ചേർക്കലാണ് ഫലം മാറ്റിയതെന്ന് രേഖപ്പെടുത്തുക.

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun image:tag
ip -br link show type tun

ഉപകരണം കാണാനും കഴിവ് ഉണ്ടാകാനും സാധിക്കുന്ന, എന്നിട്ടും പരാജയപ്പെടുന്ന കണ്ടെയ്നർ പ്രശ്നം മറ്റെവിടെയോ ആണെന്ന് പറയുന്നു. അത് ഉപയോഗപ്രദമായ ഫലമാണ്, പ്രിവിലേജ് മോഡ് അത് മറച്ചുവെക്കുമായിരുന്നു.

ഹോസ്റ്റിലെ ഉപകരണ അനുമതികളും പരിശോധിക്കുക, കാരണം ശരിയായി നൽകിയ ഉപകരണ നോഡ് തെറ്റായ ഗ്രൂപ്പ് ഉടമസ്ഥതയോടെ കുറവായ അനുമതിയുടെ അതേ പിശക് തന്നെ ഉണ്ടാക്കുന്നു.

പ്രവർത്തിക്കുന്ന ഏറ്റവും ഇടുങ്ങിയ അനുമതി രേഖപ്പെടുത്തുക

വിന്യാസത്തിന് ആവശ്യമുള്ള ഓരോ ഉപകരണവും കഴിവും അവയെ ന്യായീകരിച്ച പിശകിനൊപ്പം എഴുതുക. ആ രേഖയാണ് അടുത്ത ആൾക്ക് എന്തെങ്കിലും സുരക്ഷിതമായി നീക്കാൻ അനുവദിക്കുന്നത്, കണ്ടെയ്നർ പ്രിവിലേജുള്ളതാണെന്ന് റിപ്പോർട്ട് ചെയ്യുമ്പോൾ ഓഡിറ്റർ ആവശ്യപ്പെടുന്നതും അതു തന്നെ.

ചുറ്റുമുള്ള സന്ദർഭവും പരിശോധിക്കുക, കാരണം ഹോസ്റ്റ് നെറ്റ്വർക്കിംഗ്, ഹോസ്റ്റ് മൗണ്ടുകൾ, റൺടൈം ഓപ്ഷനുകൾ എന്നിവയിൽ ഓരോന്നിനും അനുമതിയുടെ സ്വാധീനം വിശാലമാക്കാം. അവയെല്ലാം ചേർക്കുന്ന ഒറ്റപ്പെട്ട ലാബ് വിളി, എത്ര നന്നായി പ്രവർത്തിച്ചാലും, ഉത്പാദന കോൺഫിഗറേഷനല്ല. വിന്യാസം പൂർത്തിയായി പ്രഖ്യാപിക്കുന്നതിന് മുൻപ് ആപ്ലിക്കേഷനും അതിന്റെ DNS സ്വഭാവവും ഒരു ടണൽ പരാജയവും പരിശോധിക്കുക. ഇന്റർഫേസ് സൃഷ്ടിക്കാനുള്ള അനുമതി പുറത്തേക്കുള്ള നയമല്ല, മികച്ച രീതിയിൽ ടണൽ ചെയ്യാൻ കഴിയുന്ന കണ്ടെയ്നർ ആപ്ലിക്കേഷൻ അയക്കുന്നതെല്ലാം ഇപ്പോഴും റൂട്ട് ചെയ്യുന്നു.