റൂട്ട് ഇല്ലാതെ Android VPN: സമ്മതം, റൂട്ടുകൾ, തടയൽ ആരുടേത്
സമ്മതം, TUN ഇന്റർഫേസ്, സിസ്റ്റത്തിന്റെ തടയൽ നയം എന്നിവ മൂന്ന് വ്യത്യസ്ത അനുമതികളാണ്. Android VPN ആപ്പ് പരിശോധിക്കുന്നതിന് മുൻപ് ഓരോന്നും ഏത് ഘടകത്തിന്റേതാണെന്ന് കണ്ടെത്തുക.
Android VPN ആപ്പിന് ട്രാഫിക് കൊണ്ടുപോകാനും ചോർച്ച തടയാനും റീബൂട്ടിന് ശേഷം നിലനിൽക്കാനും സഹായിക്കുന്നത് റൂട്ട് അല്ല. ഇതെല്ലാം ആളുകൾ „ആപ്പിന് VPN അനുമതിയുണ്ട്“ എന്ന് ചുരുക്കുന്നു, ഇത് മൂന്ന് വേറിട്ട സംവിധാനങ്ങളെ മറയ്ക്കുന്നു: ഉപയോക്താവിന്റെ സമ്മതം, സിസ്റ്റം സൃഷ്ടിക്കുന്ന പാക്കറ്റ് ഇന്റർഫേസ്, ആപ്പ് നിർവചിക്കേണ്ടതല്ലാത്ത പ്ലാറ്റ്ഫോം തടയൽ നയം. Android VPN ഡിസൈൻ പരിശോധിക്കുക എന്നാൽ ഒരു വാദം യഥാർത്ഥത്തിൽ ഈ മൂന്നിൽ ഏതിൽ ആണ് നിൽക്കുന്നത് എന്ന് ചോദിക്കുകയാണ്, കാരണം ഓരോന്നിനും വേറെ ഉടമയും വേറെ പരാജയ രീതിയും ഉണ്ട്.
സമ്മതം ഒരു സിസ്റ്റം ആക്ടിവിറ്റിയിലൂടെ വരുന്നു
VpnService.prepare() ഒന്നും നൽകുന്നില്ല. സമ്മതം ഇല്ലാത്തപ്പോൾ അത് സിസ്റ്റം സമ്മത ആക്ടിവിറ്റിയിലേക്ക് intent തിരികെ നൽകുന്നു, ഉപയോക്താവിന് സേവനം അനുവദിക്കാൻ ആപ്പ് ആ ഡയലോഗ് തുറക്കുന്നു. ആപ്പിന്റെ സ്വന്തം പ്രോസസ് ആരംഭിക്കുകയോ, മാനിഫെസ്റ്റിൽ അനുമതി ചേർക്കുകയോ, ഇച്ഛാനുസൃത „VPN പ്രവർത്തനക്ഷമമാക്കുക“ സ്ക്രീൻ കാണിക്കുകയോ ചെയ്യുന്നത് അനുമതി സൃഷ്ടിക്കുന്നില്ല.
അനുമതിക്ക് പരിധിയുമുണ്ട്. അത് ഉപയോക്തൃ പ്രൊഫൈലിലെ ഒരു പാക്കേജിനുള്ളതാണ്, അതിനാൽ വ്യക്തിഗത പകർപ്പും ജോലി പകർപ്പും വേറിട്ട തീരുമാനങ്ങളാണ്, ഉപകരണ ഉടമയ്ക്ക് മാനേജ് ചെയ്ത പ്രൊഫൈൽ വ്യക്തിഗതത്തിൽ നിന്ന് വ്യത്യസ്തമായി തയ്യാറാക്കാം. ഡയലോഗ് ഒരിക്കലും കാണുന്നില്ലെങ്കിൽ prepare() null നൽകിയാൽ, ആ പ്രൊഫൈലിലെ ആ പാക്കേജിന് സമ്മതം ഇതിനകം ഉണ്ട്; അത് ആപ്പ് വിശ്വസനീയമാണെന്ന തെളിവല്ല, അനുമതി ഉണ്ടെന്ന് മാത്രം.
ഇന്റർഫേസ് സിസ്റ്റം നിറവേറ്റുന്ന അഭ്യർത്ഥനയാണ്
സമ്മതത്തിന് ശേഷം ആപ്പ് VpnService.Builder ഉപയോഗിച്ച് തനിക്ക് വേണ്ടത് വിവരിക്കുന്നു: വിലാസങ്ങൾ, റൂട്ടുകൾ, DNS സർവറുകൾ, MTU, പിന്തുണയുള്ളിടത്ത് ഉൾപ്പെടുത്തേണ്ടതോ ഒഴിവാക്കേണ്ടതോ ആയ ആപ്പുകൾ. establish() സിസ്റ്റത്തോട് ടണൽ ഇന്റർഫേസ് സൃഷ്ടിച്ച് പൊരുത്തപ്പെടുന്ന ട്രാഫിക് അതിലേക്ക് അയക്കാൻ ആവശ്യപ്പെടുന്നു. റൂട്ടിംഗ് തീരുമാനം സിസ്റ്റത്തിന്റേതാണ്; ആപ്പ് ഫയൽ ഡിസ്ക്രിപ്റ്റർ സ്വീകരിച്ച് പിന്നീട് പാക്കറ്റുകളിൽ എന്തെങ്കിലും ഉപയോഗപ്രദമായി ചെയ്യണം.
| What you observe | Who actually owns it |
|---|---|
| VPN consent dialog | The system, triggered by prepare() |
| Routes, DNS and app lists | The app requests them; the system applies them |
| One active VPN per profile | The platform; a new service replaces the old one |
| Always-on and block-without-VPN | Device policy enforced by the platform |
ആ പട്ടിക ഒരിടത്ത് നിൽക്കുന്ന വാസ്തുവിദ്യയാണ്. ആപ്പ് പാക്കറ്റ് കൈകാര്യം ചെയ്യുന്നതിൽ പങ്കെടുക്കുന്നു; ഇന്റർഫേസോ റൂട്ടിംഗ് പട്ടികയോ പ്രവർത്തിപ്പിക്കാവുന്ന സേവനങ്ങളുടെ എണ്ണമോ അതിന്റേതല്ല.
ടണൽ സോക്കറ്റ് അതിന്റെ സ്വന്തം ടണലിൽ നിന്ന് രക്ഷപ്പെടണം
എൻക്രിപ്റ്റ് ചെയ്ത ട്രാഫിക് കൊണ്ടുപോകുന്ന കണക്ഷൻ തന്നെ ഒരു സോക്കറ്റാണ്. ആപ്പ് ഇപ്പോൾ സൃഷ്ടിച്ച ഇന്റർഫേസിലേക്ക് അത് തിരികെ റൂട്ട് ചെയ്യപ്പെട്ടാൽ, ടണൽ ടണലിനെ ആശ്രയിച്ച് നിലയ്ക്കും. VpnService.protect() ആ സോക്കറ്റിനെ അടിസ്ഥാന നെറ്റ്വർക്കിലേക്ക് ബന്ധിക്കുന്നു, അതുവഴി അത് പിടിച്ചെടുക്കൽ ഒഴിവാക്കുന്നു, അതുകൊണ്ടാണ് ശരിയായ ക്ലൈന്റ് ആദ്യ ഹാൻഡ്ഷേക്കിന് മുൻപ് അതിന്റെ പുറം സോക്കറ്റ് സംരക്ഷിക്കുന്നത്.
adb shell dumpsys connectivity | grep -i -A5 vpn
adb shell settings get global always_on_vpn_app
adb shell settings get global always_on_vpn_lockdownഈ കമാൻഡുകൾ ഇൻസ്റ്റാൾ ചെയ്ത VPN നെറ്റ്വർക്ക്, എല്ലായ്പ്പോഴും ഓണായ പാക്കേജ്, ലോക്ക്‌ഡൗൺ സജ്ജീകരിച്ചിട്ടുണ്ടോ എന്നിവ കാണിക്കുന്നു. ഇവ വായന മാത്രമുള്ള നിരീക്ഷണങ്ങളാണ്: മൂല്യങ്ങൾ ഡിസൈന്റെ വാദവുമായി പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ, വാദം സിസ്റ്റത്തിന്റെ അവസ്ഥയെക്കുറിച്ചല്ല, ആപ്പിന്റെ ഇന്റർഫേസിനെക്കുറിച്ചാണ്.
തടയൽ പ്ലാറ്റ്ഫോമിന്റേതായിരിക്കാം
VPN ഉപയോഗിക്കാത്ത കണക്ഷനുകൾ തടയുന്ന ഒരു നയം Android രേഖപ്പെടുത്തുന്നു. ആ നിർവഹണം പ്ലാറ്റ്ഫോം കരാറാണ്, ആപ്പ് ലൂപ്പിൽ കണക്ഷൻ വീണ്ടും ശ്രമിക്കുന്നതല്ല. സ്വിച്ച് ഉപകരണത്തിന്റെ VPN ക്രമീകരണങ്ങളിൽ „VPN ഇല്ലാതെ കണക്ഷനുകൾ തടയുക“ എന്നാണ്, മാനേജ് ചെയ്ത ഉപകരണത്തിൽ ഉടമ മുഴുവൻ പ്രൊഫൈലിനും അത് ഓണാക്കാം. മാർക്കറ്റിംഗ് വാദം വിലയിരുത്തുമ്പോൾ ഈ വ്യത്യാസം പ്രധാനമാണ്: ക്ലൈന്റ് താഴിട്ട ഐക്കൺ കാണിച്ച് ആക്രമണാത്മകമായി വീണ്ടും കണക്ട് ചെയ്യാം, അതേസമയം നേരിട്ടുള്ള ട്രാഫിക് ഇപ്പോഴും സാധ്യമാണ്; അല്ലെങ്കിൽ ഉൾക്കൊള്ളുന്ന ആപ്പുകൾ സിസ്റ്റം ലോക്ക്‌ഡൗൺ നടപ്പാക്കുന്നതിനാൽ ഓഫ്‌ലൈനായി തുടരാം.
താഴിട്ട ഐക്കൺ ആപ്പ് വരയ്ക്കുന്നതാണ്, അതിനാൽ ആപ്പ് കണക്ട് ചെയ്തിട്ടുണ്ടെന്ന് വിശ്വസിക്കുന്നു എന്ന് മാത്രമേ അത് തെളിയിക്കുന്നുള്ളൂ. മറ്റൊരു ആപ്പ് നെറ്റ്വർക്ക് ആക്സസ് നഷ്ടപ്പെടുമോ എന്ന് പ്ലാറ്റ്ഫോം തീരുമാനിക്കുന്നു, അതിനാൽ ഉപയോഗപ്രദമായ പരിശോധന ടണൽ ഓണായിരിക്കുമ്പോൾ ആ ആപ്പ് പരാജയപ്പെടുന്നത് കാണുകയാണ്.
ആപ്പ് സ്റ്റോറിലെ „എപ്പോഴും ഓൺ“ ലേബലും ആ കരാർ പകരുന്നില്ല. എപ്പോഴും ഓൺ, ലോക്ക്‌ഡൗൺ എന്നിവ ഉപകരണ ക്രമീകരണങ്ങളാണ്, പലപ്പോഴും ഉപകരണ ഉടമ പ്രയോഗിക്കുന്നു, ഒഴിവാക്കിയ ആപ്പുകൾക്കുള്ള അവയുടെ സ്വഭാവം പ്ലാറ്റ്ഫോം നിർവചിക്കുന്നു. ബാഡ്ജല്ല, ക്രമീകരണം വായിക്കുക.
ഡിസൈൻ അവലോകനത്തിനുള്ള നാല് ചോദ്യങ്ങൾ
ഒന്ന്, ആരാണ് സമ്മതിച്ചത്: ഏത് പാക്കേജ്, ഏത് പ്രൊഫൈൽ, ഉപയോക്താവോ മാനേജ് ചെയ്ത ഉപകരണ നയമോ? രണ്ട്, ആപ്പ് എന്താണ് അഭ്യർത്ഥിച്ചത്: ഏത് റൂട്ടുകൾ, ഏത് വിലാസ കുടുംബങ്ങൾ, ഏത് ആപ്പുകൾ ഉൾപ്പെടുത്തി അല്ലെങ്കിൽ ഒഴിവാക്കി? മൂന്ന്, ടണൽ ലഭ്യമല്ലാത്തപ്പോൾ എന്ത് സംഭവിക്കുന്നു: സിസ്റ്റം തടയുന്നുവോ അതോ ട്രാഫിക് അടിസ്ഥാന നെറ്റ്വർക്കിലേക്ക് തിരിച്ചുപോകുന്നുവോ? നാല്, ആപ്പ് സ്വീകരിക്കുന്ന പാക്കറ്റുകളിൽ എന്ത് ചെയ്യുന്നു?
നാലാമത്തെ ചോദ്യം അനുമതി മാതൃകയ്ക്ക് ഉത്തരം നൽകാനാകാത്തതാണ്. സമ്മതവും TUN ഇന്റർഫേസും ആപ്പിന് ട്രാഫിക് സ്വീകരിക്കാമെന്ന് തെളിയിക്കുന്നു, അത് എൻക്രിപ്റ്റ് ചെയ്യുന്നു, പങ്കാളിയെ പ്രാമാണീകരിക്കുന്നു അല്ലെങ്കിൽ ശുദ്ധമായി വീണ്ടെടുക്കുന്നു എന്നല്ല. ഇവ നടപ്പാക്കൽ സവിശേഷതകളാണ്, സത്യസന്ധമായ അവലോകനം സമയം ചെലവഴിക്കുന്നത് അവിടെയാണ്.
അനാവശ്യമായ റൂട്ട് അഭ്യർത്ഥന ഫലത്തെ കിൽ സ്വിച്ച് എന്ന് വിളിക്കുന്നതുകൊണ്ട് സാധുവാകുന്നില്ല, സമ്മത ഡയലോഗ് സുരക്ഷാ ഓഡിറ്റുമല്ല. മൂന്ന് അനുമതികളും വേർതിരിച്ച് സൂക്ഷിക്കുക, ഓരോ വാദവും പരിശോധനായോഗ്യമാകും.