ഒരു സാധാരണ Linux ആപ്പ് TUN തൊടാതെ VPN ഉപയോഗിക്കുന്നു

സ്ഥാപിച്ച Linux VPN ഉപയോഗിക്കുന്ന ബ്രൗസർ /dev/net/tun തുറക്കുന്നില്ല. അത് ഒരു സോക്കറ്റ് തുറക്കുന്നു, ആ സോക്കറ്റിന്റെ പാക്കറ്റുകൾ ഏത് ഇന്റർഫേസിലൂടെ പുറത്തുപോകുന്നു എന്ന് കേർണൽ തീരുമാനിക്കുന്നു. ടണൽ സൃഷ്ടിച്ച പ്രോസസ്, അത് വഹിക്കുന്ന ട്രാഫിക്കിന്റെ പ്രോസസിൽനിന്ന് വ്യത്യസ്തമായ ജോലി ചെയ്യുന്നു. ഈ രണ്ട് റോളുകൾ വേർതിരിച്ചു നിർത്തുന്നത് മിക്ക അനുമതി ചോദ്യങ്ങൾക്കും അവ ചോദിക്കുന്നതിനു മുമ്പേ ഉത്തരം നൽകുന്നു.

സോക്കറ്റിൽനിന്ന് ടണലിലേക്ക് ഒരു പാക്കറ്റ് പിന്തുടരുക

സാധാരണ ആപ്പ് connect അല്ലെങ്കിൽ send വിളിക്കുന്നു, കേർണൽ ലക്ഷ്യത്തിലേക്കുള്ള റൂട്ട് നോക്കുന്നു. തിരഞ്ഞെടുത്ത റൂട്ട് ടണൽ ഇന്റർഫേസിലേക്ക് ചൂണ്ടുന്നെങ്കിൽ, പാക്കറ്റ് VPN ഡീമൺ വായിക്കുന്ന ഉപകരണത്തിന്റെ ക്യൂവിൽ ചേരുന്നു. ഡീമൺ അത് എൻക്രിപ്റ്റ് ചെയ്ത് ഫിസിക്കൽ ഇന്റർഫേസിലൂടെ പുറത്തയക്കുന്നു. ആ വിവരണത്തിലെ ഓരോ അമ്പും അനുമതി ചോദ്യത്തിന് ഉത്തരം നൽകാവുന്ന ഒരിടമാണ്.

ആ വഴിയിൽ ആപ്പ് ഉപകരണത്തെക്കുറിച്ച് അറിയണമെന്ന് ഒന്നും ആവശ്യപ്പെടുന്നില്ല. ഡീമൺ ഫയൽ ഡിസ്ക്രിപ്റ്റർ കൈവശം വെക്കുകയും ഇന്റർഫേസ് പ്രവർത്തനങ്ങൾ നടത്തുകയും ചെയ്യുന്നു, ആപ്പ് സാധാരണ നെറ്റ്‌വർക്ക് API മാത്രം കാണുന്നു.

രണ്ടു പകുതികളും ഒരിക്കൽ വരയ്ക്കുക, അപ്പോൾ അനുമതി ചോദ്യങ്ങൾ സ്ഥാപിക്കാൻ എളുപ്പമാകും. മുകൾ പകുതി ആപ്പുകളുടെ ലോകമാണ്, താഴെയുള്ളത് ഡീമണിന്റേതാണ്.

ഉപകരണം ആർക്ക് വേണം, ആർക്ക് വേണ്ട എന്ന് തീരുമാനിക്കുക

TUN ഇന്റർഫേസ് സൃഷ്ടിക്കാനോ അതിൽ ചേരാനോ ഉപകരണ പ്രവേശനവും കൂടാതെ അത് കോൺഫിഗർ ചെയ്യാനുള്ള കഴിവും വേണം, അതുകൊണ്ടാണ് പിന്തുണയുള്ള VPN സേവനം നെറ്റ്‌വർക്ക് അഡ്മിനിസ്ട്രേഷൻ അധികാരത്തോടെ തുടങ്ങുന്നത് അല്ലെങ്കിൽ പ്രത്യേക സഹായിയെ ഉപയോഗിക്കുന്നത്. ആ ആവശ്യം ഡീമണിന്റേതാണ്. ബ്രൗസർ, ഡാറ്റാബേസ് ക്ലയന്റ്, ഫയൽ കൈമാറ്റ ഉപകരണം എന്നിവയെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല. ആ കഴിവ് വേണ്ട സേവനത്തിന് അത് സ്വന്തം സെറ്റപ്പ് ഘട്ടത്തിനാണ് വേണ്ടത്, ക്ലയന്റുകൾക്കല്ല.

റൂട്ടും നയവും സ്ഥാപിച്ചുകഴിഞ്ഞാൽ, സാധാരണ പ്രോസസ് ലഭിച്ച വഴി തന്റെ സാധാരണ സോക്കറ്റ് വിളികളിലൂടെ ഉപയോഗിക്കുന്നു. അതിന് ഉപകരണ നോഡ് വേണ്ട, root-ഉം വേണ്ട.

ഉപകരണ അനുമതികൾ മാറ്റുന്നത് ആപ്പിന് ലക്ഷ്യത്തിലേക്ക് പ്രവേശനം നൽകാനുള്ള വഴിയല്ല. അത് ഉപകരണത്തിന്റെ അതിർത്തി മറ്റൊരിടത്തേക്ക് നീക്കുന്നു മാത്രം.

ആപ്പ് യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്ന നെയിംസ്പേസ് പരിശോധിക്കുക

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

അത് ip netns list ഉം ip -n NAME route ഉം ഉപയോഗിച്ചോ, പ്രോസസിന്റെ നെയിംസ്പേസ് ലിങ്ക് പരിശോധിച്ചോ പരിശോധിക്കുക. ഉത്തരം സാധാരണയായി ഒറ്റ കമാൻഡിൽ കാണാം.

ഒരേ ഹോസ്റ്റിലെ രണ്ട് ഉപയോക്താക്കൾക്ക് നയപ്രകാരം വ്യത്യസ്ത വഴികളും നൽകാം. അത് നെറ്റ്‌വർക്ക് തീരുമാനമാണ്, ഉപകരണ ഉടമസ്ഥതയുടെ തെളിവല്ല.

കഴിവുകളെ നെറ്റ്‌വർക്ക് നയത്തിൽനിന്ന് വേർതിരിക്കുക

ചില ടൂളുകൾക്ക് സോക്കറ്റിനെക്കാൾ കൂടുതൽ വേണം. പാക്കറ്റുകൾ പിടിക്കാൻ അസംസ്കൃത സോക്കറ്റ് വേണം, റൂട്ടുകൾ മാറ്റാൻ അഡ്മിനിസ്ട്രേഷൻ അധികാരവും വേണം. അവ വെവ്വേറെ അനുമതികളുള്ള വെവ്വേറെ പ്രവർത്തനങ്ങളാണ്, ഒന്ന് നൽകുന്നത് VPN ഉപയോഗിക്കാനുള്ള പൊതുവായ ആവശ്യകതയായി വായിക്കരുത്.

സ്വന്തം ടണൽ നടപ്പാക്കുന്ന പ്രോഗ്രാം മൂന്നാമത്തെ കേസാണ്. ഡീമണിന്റെ റോൾ എടുക്കുന്നതിനാൽ അത് യഥാർത്ഥത്തിൽ TUN തുറക്കുന്നു, അതുകൊണ്ടാണ് അതിന് ഡീമണിന്റെ പ്രത്യേകാവകാശങ്ങൾ വേണ്ടത്.

പ്രത്യേകാവകാശത്തിന് പേരിടുന്നതിന് മുമ്പ് പ്രവർത്തനത്തിന് പേരിടുക. രണ്ടും വേർതിരിക്കാൻ സാധാരണയായി കാണുന്നതിനേക്കാൾ എളുപ്പമാണ്.

രണ്ട് അക്കൗണ്ടുകൾ ഉപയോഗിച്ച് വിഭജനം പരിശോധിക്കുക

ടണൽ സേവനമായി ബന്ധിപ്പിച്ച്, പിന്നീട് ആപ്പ് സാധാരണ ഉപയോക്താവായി പ്രവർത്തിപ്പിച്ച് അത് സ്വകാര്യ വിഭവത്തിൽ എത്തുന്നുവെന്ന് ഉറപ്പാക്കുക. ആ ഉപയോക്താവിന്റെ ഷെല്ലിൽനിന്ന് ലക്ഷ്യത്തിനായി ip route get പരിശോധിച്ച് ഏത് ഇന്റർഫേസ് തിരഞ്ഞെടുത്തുവെന്ന് കാണുക. റൂട്ട് ശരിയാണെങ്കിലും കണക്ഷൻ ഇപ്പോഴും പരാജയപ്പെടുന്നെങ്കിൽ, പ്രശ്നം നയമാണ്, പ്രത്യേകാവകാശമല്ല.

ഫലമായി വരുന്ന രൂപകൽപ്പന വ്യക്തമായ അതിർത്തിയുള്ള ഏറ്റവും കുറഞ്ഞ പ്രത്യേകാവകാശമാണ്: ഒരു ഘടകം സെറ്റപ്പും ടണൽ വിഭവങ്ങളും സ്വന്തമാക്കുന്നു, വർക്ക്ലോഡുകൾ അവയുടെ സാധാരണ അക്കൗണ്ടുകൾ നിലനിർത്തുന്നു, നെറ്റ്‌വർക്ക് നയം എന്ത് കടന്നുപോകാമെന്ന് തീരുമാനിക്കുന്നു. എല്ലാം root ആയി പ്രവർത്തിപ്പിക്കുന്നത് ആ റോളുകളെ ഒന്നും വിശദീകരിക്കാതെ തകർക്കുന്നു.