Android chroot VPN: ടണൽ പ്രവർത്തിക്കുന്നു, പക്ഷേ ആപ്പുകൾ അത് അവഗണിക്കുന്നത് എന്തുകൊണ്ട്
chroot മാറ്റുന്നത് പാത്ത്നെയിം കണ്ടെത്തൽ മാത്രമാണ്, കേർണലോ നെറ്റ്വർക്ക് നെയിംസ്പേസോ Android-ന്റെ VPN രജിസ്ട്രേഷനോ അല്ല. ഇതിൽ നിന്ന് രണ്ട് ഫലങ്ങൾ ഉണ്ടാകുന്നു, രണ്ടും ആളുകളെ അമ്പരപ്പിക്കുന്നു.
ഫോണിൽ chroot-ന് കീഴിൽ ഒരു Linux വിതരണം പ്രവർത്തിപ്പിക്കാം, അതിൽ ഒരു VPN ക്ലയന്റ് ഇൻസ്റ്റാൾ ചെയ്യാം, ഷെൽ ടണൽ പൂർത്തിയായി എന്ന് അറിയിക്കും. പിന്നീട് ബ്രൗസറിലേക്ക് മാറുമ്പോൾ ഒന്നും സംഭവിക്കാത്തതുപോലെ ട്രാഫിക് മൊബൈൽ ഡാറ്റ വഴി പുറത്തുപോകും. അല്ലെങ്കിൽ നേരെ വിപരീതം: ക്ലയന്റ് Android യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന namespace-ൽ ഒരു ഡിഫോൾട്ട് റൂട്ട് ഇട്ടതിനാൽ ഫോണിലെ എല്ലാ ആപ്പുകളും കണക്റ്റിവിറ്റി നഷ്ടപ്പെടുത്തും. ഈ രണ്ട് ലക്ഷണങ്ങളും ഒരേ കാണാത്ത ഭാഗത്തുനിന്നാണ് വരുന്നത്, രണ്ടും VPN ക്ലയന്റിലെ ബഗ് അല്ല.
ഷെൽ കണക്റ്റ് ചെയ്തു എന്ന് പറയുന്നു, ആപ്പുകൾ യോജിക്കുന്നില്ല
ആദ്യത്തെ ഫലമാണ് സാധാരണം. chroot-ൽ നിന്ന് തുറന്ന ഒരു userspace ടണലിന് അതിന്റെ ഹാൻഡ്ഷേക്ക് പൂർത്തിയാക്കാം, സ്ഥിതിവിവരക്കണക്കുകൾ പ്രിന്റ് ചെയ്യാം, അതേ ഷെൽ ഉണ്ടാക്കുന്ന ട്രാഫിക് കൊണ്ടുപോകാം, പക്ഷേ Android ആപ്പുകൾ ഫോണിന്റെ ഡിഫോൾട്ട് നെറ്റ്വർക്ക് തുടർന്നും ഉപയോഗിക്കും. ഒന്നും അവയെ തടയുന്നില്ല, കാരണം VPN ഉണ്ടെന്ന് Android-നോട് ആരും പറഞ്ഞില്ല.
രണ്ടാമത്തെ ഫലമാണ് അപകടകരമായത്. chroot Android-ന്റെ നെറ്റ്വർക്ക് namespace പങ്കിടുന്നുവെങ്കിൽ — സ്വതവേ അങ്ങനെയാണ് — മതിയായ പ്രിവിലേജുള്ള ഒരു പ്രോസസിന് മുഴുവൻ ഫോണിനെയും ബാധിക്കുന്ന റൂട്ടുകളും TUN ഇന്റർഫേസും ചേർക്കാം. അപ്പോൾ ടണൽ എല്ലാ ആപ്പുകൾക്കും പ്രവർത്തിക്കും, റൂട്ട് ചെയ്യാൻ ഉദ്ദേശിക്കാത്തവ ഉൾപ്പെടെ, ഫോണിന്റെ കണക്റ്റിവിറ്റി ഇപ്പോൾ ലൈഫ്സൈക്കിൾ മാനേജ്മെന്റോ കണക്ഷൻ ഇൻഡിക്കേറ്ററോ always-on പോളിസിയോ ഇല്ലാത്ത ഒരു ഡീമണിനെ ആശ്രയിക്കുന്നു.
ഏതാണ് ലഭിച്ചതെന്ന് ഒരു കമാൻഡിൽ അറിയാം. chroot-നുള്ളിലെ ip route അതിനു പുറത്തുള്ള Android ഷെല്ലിൽ നിന്നുള്ള അതേ കമാൻഡുമായി താരതമ്യം ചെയ്യുക. ഒരേ ഔട്ട്പുട്ട് എന്നാൽ chroot ഹോസ്റ്റ് namespace-ലാണ്: അത് വരുത്തുന്ന ഏതൊരു നെറ്റ്വർക്കിംഗ് മാറ്റവും ഫോൺ മുഴുവൻ ബാധിക്കും. വ്യത്യസ്ത ഔട്ട്പുട്ട് എന്നാൽ ലോഞ്ചർ അതിനായി ഒരു namespace ഉണ്ടാക്കി, അതിന്റെ ടണൽ Android-ന് നിർമ്മാണപരമായി അദൃശ്യമാണ്.
chroot എന്ത് മാറ്റി, എന്ത് മാറ്റിയില്ല
| Object | Effect of a chroot |
|---|---|
| Pathname resolution | Changed: lookups start at the new root |
| Kernel and drivers | Unchanged: the phone's kernel, its TUN driver, its limits |
| Network namespace | Unchanged unless the launcher creates one |
| Android VPN registration | Unchanged: no app consented, no VPN is selected |
chroot സിസ്റ്റം കോൾ ഒരു കാര്യം മാത്രം ചെയ്യുന്നു: പാത്ത്നെയിം റെസല്യൂഷന് ഉപയോഗിക്കുന്ന ഡയറക്ടറി മാറ്റുന്നു. ഇത് ഒരു സുരക്ഷാ അതിർത്തിയല്ലെന്ന് മാൻ പേജ് വ്യക്തമാക്കുന്നു, ഇന്റർഫേസുകൾ, റൂട്ടുകൾ, VPN അവസ്ഥ എന്നിവയെക്കുറിച്ച് ഒന്നും പറയുന്നുമില്ല. Linux കണ്ടെയ്നർ എന്നതിൽ നിന്ന് ആളുകൾ പ്രതീക്ഷിക്കുന്ന എല്ലാം — സ്വകാര്യ നെറ്റ്വർക്ക് സ്റ്റാക്ക്, ഫിൽട്ടർ ചെയ്ത ഫയൽസിസ്റ്റം, റിസോഴ്സ് പരിധികൾ — ലോഞ്ചർ ഉപയോഗിച്ചിരിക്കാവുന്നതോ ഇല്ലായിരിക്കാവുന്നതോ ആയ മറ്റ് മെക്കാനിസങ്ങളിൽ നിന്നാണ് വരുന്നത്.
അതുകൊണ്ടാണ് chroot ഒരു VPN-നെ വേർതിരിക്കുന്നു എന്ന വാദങ്ങൾ സാധാരണയായി തെറ്റായ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നത്. പ്രസക്തമായ ചോദ്യം, പ്രോസസ് ഏത് namespace-ലാണ് പ്രവർത്തിക്കുന്നത്, ഏത് SELinux ഡൊമെയ്നിലാണ് അത് നിയന്ത്രിക്കപ്പെടുന്നത് എന്നതാണ്; രണ്ടും അത് എങ്ങനെ ആരംഭിച്ചു എന്നതിന്റെ സ്വഭാവങ്ങളാണ്, chroot എന്ന വാക്കിന്റേതല്ല.
TUN-ന് മൂന്ന് കാര്യങ്ങൾ വേണം, ഡിവൈസ് നോഡ് അതിൽ ഒന്ന് മാത്രം
പരമ്പരാഗതമായ ഒരു userspace ടണലിന് തുറക്കാവുന്ന ഒരു TUN ഡിവൈസ്, ആ ഡിവൈസിനുള്ള കേർണൽ പിന്തുണ, ഇന്റർഫേസും റൂട്ടുകളും കോൺഫിഗർ ചെയ്യാനുള്ള അനുമതി എന്നിവ വേണം. ഇവ വെവ്വേറെ ആവശ്യകതകളാണ്, /dev-ന് കീഴിൽ ഒരു പാത്ത്നെയിം ഉണ്ടാക്കുന്നത് അവയിലൊന്നും സ്വയം പൂർത്തീകരിക്കുന്നില്ല:
ls -l /dev/net/tun
ip tuntap add dev tun0 mode tunAndroid-ൽ കേർണലിൽ സാധാരണയായി TUN പിന്തുണ കംപൈൽ ചെയ്തിട്ടുണ്ട്, കാരണം പ്ലാറ്റ്ഫോമിന്റെ സ്വന്തം VPN സേവനം അത് ഉപയോഗിക്കുന്നു, പക്ഷേ അതിന്റെ അർത്ഥം നിങ്ങളുടെ പ്രോസസിന് അത് ഉപയോഗിക്കാമെന്നല്ല. ഇന്റർഫേസ് കോൺഫിഗറേഷന് നെറ്റ്വർക്ക് അഡ്മിനിസ്ട്രേഷൻ കഴിവ് വേണം, പ്രോസസിന് ഡിവൈസ് നോഡിൽ എത്താമോ എന്ന് SELinux തീരുമാനിക്കുന്നു. നിഷേധം വ്യക്തമായ കാരണമില്ലാത്ത ഒരു അനുമതി പിശകായി തോന്നും, ഉത്തരം ഓഡിറ്റ് ട്രെയിലിലാണ്:
dmesg | grep avc
logcat -d | grep "avc: denied"Root ഇത് പരിഹരിക്കുന്നില്ല. uid 0 ആയി പ്രവർത്തിക്കുന്ന പ്രോസസുകളെ SELinux മറ്റുള്ളവരെപ്പോലെതന്നെ നിയന്ത്രിക്കുന്നു, അതിനാൽ root ഷെല്ലിൽ നിന്ന് ആരംഭിച്ച chroot-നും താൻ കാണുന്ന ഒരു ഡിവൈസ് നിഷേധിക്കപ്പെടാം. പഴയ ഇൻസ്റ്റാളർ പ്രവർത്തിപ്പിക്കാൻ എൻഫോഴ്സ്മെന്റ് ഓഫ് ചെയ്യുന്നത് ടണലിനപ്പുറം പരിണതഫലങ്ങളുള്ള ഫോൺ മുഴുവൻ ബാധിക്കുന്ന തീരുമാനമാണ്, അത് കാലഹരണപ്പെട്ട ഒരു ബൈനറിയുടെ പരിഹാരവുമല്ല.
Android ആപ്പുകൾ നിങ്ങളുടെ ടണൽ അവഗണിക്കുന്നത് എന്തുകൊണ്ട്
Android-ിന്റെ പിന്തുണയുള്ള മാതൃക, പ്ലാറ്റ്ഫോമിന്റെ VPN സേവനത്തിലൂടെ രജിസ്റ്റർ ചെയ്യുന്ന, ഒരിക്കൽ ഉപയോക്താവിന്റെ സമ്മതം ചോദിക്കുന്ന, തന്റെ ടണലിനായി ഒരു ഫയൽ ഡിസ്ക്രിപ്റ്റർ സ്വീകരിക്കുന്ന ഒരു VPN ആപ്ലിക്കേഷനാണ്. തുടർന്ന് പ്ലാറ്റ്ഫോം ട്രാഫിക് ആ ഡിസ്ക്രിപ്റ്ററിലേക്ക് റൂട്ട് ചെയ്യുകയും ഉപയോക്താവോ അഡ്മിനിസ്ട്രേറ്ററോ തിരഞ്ഞെടുത്ത ആപ്പ് പരിധി നടപ്പിലാക്കുകയും ചെയ്യുന്നു; അതുകൊണ്ടാണ് അതേ മെക്കാനിസം പ്രതി-ആപ്പ്, പ്രതി-പ്രൊഫൈൽ ആകാനും always-on, block-without-VPN ക്രമീകരണങ്ങളുമായി സംയോജിപ്പിക്കാനും കഴിയുന്നത്. Android VPN ഡെവലപ്മെന്റ് ഗൈഡ് ആ ഹാൻഡ്ഷേക്ക് വിവരിക്കുന്നു, പ്രധാന കാര്യം അത് ഒരു രജിസ്ട്രേഷനാണ്, ഒരു റൂട്ടിംഗ് തന്ത്രമല്ല.
chroot-നുള്ളിലെ ഒരു ഡീമൺ ഒരിക്കലും രജിസ്റ്റർ ചെയ്യുന്നില്ല. സമ്മത ഡയലോഗ് ഇല്ല, സ്റ്റാറ്റസ് ബാറിൽ കീ ഐക്കൺ ഇല്ല, പ്രതി-ആപ്പ് ഉൾപ്പെടുത്തൽ അല്ലെങ്കിൽ ഒഴിവാക്കൽ പട്ടിക ഇല്ല, always-on പോളിസിയിൽ പങ്കാളിത്തവുമില്ല. അതിനാൽ ആപ്പുകൾ ഡിഫോൾട്ട് നെറ്റ്വർക്ക് തുടർന്നും ഉപയോഗിക്കുന്നു, ടണൽ ഷെൽ തന്നെ അയയ്ക്കുന്നത് മാത്രം കൊണ്ടുപോകുന്നു.
മറുവശത്തേക്ക് പോകുന്നതും സഹായിക്കുന്നില്ല. ഹോസ്റ്റ് namespace-ലേക്ക് റൂട്ടുകൾ തള്ളുന്നത് എല്ലാം പിടിക്കുന്നു, പ്ലാറ്റ്ഫോം ലോക്കലായി നിലനിർത്താൻ പ്രതീക്ഷിച്ച ട്രാഫിക് ഉൾപ്പെടെ, അതും പ്രതി-ആപ്പ് നിയന്ത്രണമില്ലാതെ, ഉപയോക്താവിന് കാണാനോ റദ്ദാക്കാനോ വഴിയില്ലാതെ. chroot ഡീമൺ ഒരു ആപ്പിന് മാത്രം ട്രാഫിക് റൂട്ട് ചെയ്യുന്ന ഇടത്തരം ക്രമീകരണം ഇല്ല.
ബൈനറി അനുയോജ്യത വേറൊരു മതിലാണ്
നെറ്റ്വർക്ക് വശം രസകരമാണെങ്കിലും, എക്സിക്യൂട്ടബിളിന് സ്വന്തം ആവശ്യകതകളുണ്ട്: CPU ആർക്കിടെക്ചർ, ഡൈനാമിക് ലോഡർ, C ലൈബ്രറി, അത് പ്രതീക്ഷിക്കുന്ന കേർണൽ സൗകര്യങ്ങൾ. Android glibc-ക്ക് പകരം bionic ഉപയോഗിക്കുന്നു, ഡെസ്ക്ടോപ്പ് വിതരണത്തിനായി നിർമ്മിച്ച പഴയ ബൈനറിക്ക് ഉപകരണത്തിൽ ഇല്ലാത്ത ലൈബ്രറികൾ ആവശ്യമായി വരാം.
ഒരു ലൈബ്രറി ഫയൽനാമം പുതിയ പതിപ്പിലേക്ക് സിംബോളിക് ലിങ്ക് ചെയ്യുന്നത് ABI അനുയോജ്യത സൃഷ്ടിക്കുന്നില്ല, പത്തു വർഷം പഴക്കമുള്ള ഒരു പാക്കേജിൽ നിന്നുള്ള ആർക്കൈവ് ചെയ്ത ക്രിപ്റ്റോഗ്രാഫിക് ലൈബ്രറി പരിപാലിക്കപ്പെടുന്ന ഒരു ഘടകമല്ല. പദ്ധതി അതിനെ ആശ്രയിക്കുന്നുവെങ്കിൽ, പദ്ധതി എന്നത് ഫോണിൽ നെറ്റ്വർക്ക് പ്രിവിലേജുകളോടെ പരിപാലിക്കപ്പെടാത്ത കോഡ് പ്രവർത്തിപ്പിക്കുകയാണ്.
Android സന്ദർഭത്തിൽ അത് തെളിയിക്കുക, ശേഷം വൃത്തിയാക്കുക
നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ പ്രധാനമായത്, പ്രധാനമായ വശത്തുനിന്ന് പരിശോധിക്കുക: നിർദ്ദിഷ്ട ആപ്പ് തുറക്കുക, നിർദ്ദിഷ്ട സ്വകാര്യ ലക്ഷ്യത്തിൽ എത്തുക, ഏത് റിസോൾവർ ഉത്തരം നൽകി എന്ന് സ്ഥിരീകരിക്കുക, പിന്നീട് ടണൽ വിച്ഛേദിക്കുക, രേഖപ്പെടുത്തിയ പെരുമാറ്റം സ്ഥിരീകരിക്കുക. chroot-നുള്ളിലെ ഒരു ടെർമിനലിൽ നിന്നുള്ള ഫലം ആ ടെർമിനലിന്റെ എക്സിക്യൂഷൻ സന്ദർഭത്തെക്കുറിച്ചുള്ള തെളിവ് മാത്രമാണ്, അതിൽ കൂടുതലല്ല.
പരീക്ഷിക്കുമ്പോൾ ഹോസ്റ്റ് റൂട്ടുകൾ മാറ്റിയിട്ടുണ്ടെങ്കിൽ, അവ തിരികെ വയ്ക്കുക, എന്ത് മാറ്റി എന്ന് രേഖപ്പെടുത്തുക. തുടർന്ന് ഫോണിൽ always-on VPN കോൺഫിഗർ ചെയ്തിട്ടുണ്ടോ എന്ന് പരിശോധിക്കുക, കാരണം ഒരു നിയമം ബാക്കിവച്ച പഴയ പരീക്ഷണം മാസങ്ങൾക്ക് ശേഷം പ്ലാറ്റ്ഫോം തകരാറായി തോന്നാം.
യഥാർത്ഥ റിമോട്ട്-ആക്സസ് ആവശ്യത്തിന്, സേവനത്തിന്റെ പിന്തുണയുള്ള ക്ലയന്റോ അംഗീകൃത ഗേറ്റ്വേ ഡിസൈനോ ഉപയോഗിക്കുക. ചോദിക്കേണ്ട ചോദ്യം, ഒരു rooted ഇൻസ്റ്റാളറെ പ്രവർത്തിപ്പിക്കാൻ കഴിയുമോ എന്നല്ല, മറിച്ച് പിന്തുണയുള്ള ഒരു നടപ്പാക്കൽ നിങ്ങൾ ഉദ്ദേശിച്ച അതിർത്തിയിലൂടെ ആവശ്യമായ ആപ്പുകളെ കൊണ്ടുപോകുന്നുവോ, ഉപകരണത്തിൽ ഉടമയില്ലാത്ത പ്രിവിലേജുള്ള മാറ്റങ്ങൾ ബാക്കിവയ്ക്കാതെ എന്നതാണ്.