Android VPN: VpnService ഡിസ്ക്രിപ്റ്ററും root tun ഉപകരണവും
Android ആപ്പുകൾക്ക് tun0 സ്വയം സൃഷ്ടിക്കാനാവില്ല: establish() എന്ത് തിരികെ നൽകുന്നു, Binder എവിടെ നിർത്തുന്നു, JNI എവിടെ തുടങ്ങുന്നു, root സൃഷ്ടിച്ച ഉപകരണം എപ്പോൾ വിജയിക്കുന്നു.
രണ്ട് വഴികൾക്ക് ഒരു Android ആപ്പിന്റെ മുന്നിൽ IP ഇന്റർഫേസ് വയ്ക്കാം, രണ്ടും വളരെ വ്യത്യസ്ത ഉടമകളുള്ള ഒരേ തരം ഫയൽ ഡിസ്ക്രിപ്റ്ററിൽ അവസാനിക്കുന്നു. ഒന്ന് VpnService-ഉം അതിന്റെ builder-ഉം വഴി പോകുന്നു, മറ്റൊന്ന് root shell-ഉം /dev/net/tun-ഉം വഴി. ആ ഡിസ്ക്രിപ്റ്ററിലെ ഓരോ വായനയും പുറത്തേക്കുള്ള പാക്കറ്റാണ്, ഓരോ എഴുത്തും അകത്തേക്കുള്ളതും. നയം ആരുടെ കൈവശമാണ്, OS അപ്ഗ്രേഡിനെ ആര് അതിജീവിക്കുന്നു, റൂട്ടിംഗ് ടേബിളിൽ എത്രമാത്രം നിങ്ങൾക്ക് തൊടാം എന്നതാണ് വഴികളെ വേർതിരിക്കുന്നത്.
പ്ലാറ്റ്ഫോം വഴി സ്വീകരിക്കുക, അത് ചെയ്യാൻ വിസമ്മതിക്കുന്ന പ്രത്യേക കാര്യം നിങ്ങൾക്ക് പേരിടാൻ കഴിയുന്നില്ലെങ്കിൽ മാത്രം വേറെ വഴി തിരഞ്ഞെടുക്കുക. ആ വിസമ്മതം സാധാരണയായി TAP, നിങ്ങളുടെ സ്വന്തം ആപ്പ് സെറ്റിന് പുറത്തുള്ള ക്യാപ്ചർ, അല്ലെങ്കിൽ ഫ്രെയിംവർക്ക് ഒരിക്കലും വെളിപ്പെടുത്താത്ത ഒരു റൂട്ടിംഗ് നിയമമാണ്.
പ്ലാറ്റ്ഫോം വഴിയിൽ നിങ്ങൾ കമാൻഡുകൾക്ക് പകരം ഉദ്ദേശ്യം പ്രഖ്യാപിക്കുന്നു. കുറഞ്ഞത് ഒരു വിലാസം, ആവശ്യമായ റൂട്ടുകൾ, DNS സെർവറുകൾ, ഓപ്ഷണൽ ആപ്പ് ലിസ്റ്റ് എന്നിവ നൽകുന്നു, തുടർന്ന് Android-ന്റെ സിസ്റ്റം സേവനം സ്വന്തം ഐഡന്റിറ്റിയിൽ പ്രിവിലേജുള്ള സെറ്റപ്പ് ചെയ്യുന്നു. ഇന്റർഫേസിന്റെ പേര് മുൻകൂട്ടി അറിയുന്നില്ല, അത് സൃഷ്ടിക്കുന്ന ioctl ഒരിക്കലും പുറപ്പെടുവിക്കുന്നുമില്ല, അതാണ് കാര്യം.
IP ഇന്റർഫേസ് നേടാനുള്ള രണ്ട് വഴികൾ
root വഴി പഴയ പാചകക്കുറിപ്പാണ്. നിങ്ങൾ /dev/net/tun തുറക്കുന്നു, IFF_TUN-മായി TUNSETIFF വിളിക്കുന്നു, ip link ഉപയോഗിച്ച് ഇന്റർഫേസ് ഉയർത്തുന്നു, വിലാസങ്ങളും റൂട്ടുകളും കൈകൊണ്ട് ചേർക്കുന്നു. ഓരോ ഘട്ടവും നിങ്ങൾ തന്നെ ശരിയാക്കണം, ഫ്രെയിംവർക്ക് നിശബ്ദമായി കൈകാര്യം ചെയ്യുമായിരുന്നവയും ഉൾപ്പെടെ. ഒരു റൂട്ട് വിട്ടുപോയാൽ ഉപയോക്താവിന് ചത്ത സെർവറിന് ലഭിക്കുന്ന അതേ റിപ്പോർട്ട് ലഭിക്കുന്നു.
ഡീബഗ്ഗിംഗ് സെറ്റപ്പിനോളം തന്നെ വ്യത്യസ്തമാണ്. root വഴിയിൽ ഇന്റർഫേസ് ഉണ്ട്, അല്ലെങ്കിൽ നിങ്ങളുടെ ioctl നേരിട്ട് വായിക്കാവുന്ന ഒരു പിശക് തിരികെ നൽകി. പ്ലാറ്റ്ഫോം വഴിയിൽ establish() വിജയിച്ചതിന് ശേഷം മാത്രമേ ഇന്റർഫേസ് ഉണ്ടാകൂ, അതിനാൽ പരാജയം ഡിവൈസ് നോഡിന് പകരം എക്സെപ്ഷനോ null ഡിസ്ക്രിപ്റ്ററോ ആയി വരുന്നു, അതിൽ നിങ്ങൾക്ക് കുത്തിത്തുരക്കാം.
establish() യഥാർത്ഥത്തിൽ എന്ത് തിരികെ നൽകുന്നു
Builder.establish()-ന് മൂന്ന് ഫലങ്ങളുണ്ട്, അവയ്ക്ക് മൂന്ന് വ്യത്യസ്ത പ്രതികരണങ്ങൾ വേണം. ഡിസ്ക്രിപ്റ്റർ എന്നാൽ ഇന്റർഫേസ് കോൺഫിഗർ ചെയ്തു, ഉപയോഗത്തിന് നിങ്ങളുടേതാണ്; null എന്നാൽ അഭ്യർത്ഥന കടന്നുപോയില്ല; എറിയപ്പെട്ട എക്സെപ്ഷൻ എന്നാൽ സിസ്റ്റം സേവനം അത് നിരസിച്ചു. null-ഉം വിജയവും ഒരു boolean-ലേക്ക് ചേർക്കുന്നത് പാക്കറ്റ് ഒരിക്കലും വഹിക്കാത്ത പ്രവർത്തിക്കുന്ന ടണൽ ഒരു ആപ്പ് റിപ്പോർട്ട് ചെയ്യുന്ന ഏറ്റവും സാധാരണ മാർഗമാണ്. Builder റഫറൻസ് വിലാസ ആവശ്യകത പറയുന്നു, സെർവറിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുൻപ് അത് വായിക്കുന്നത് ഉചിതമാണ്.
ദിശകൾ ഡിസ്ക്രിപ്റ്റർ നിർണ്ണയിക്കുന്നു, നിങ്ങളുടെ പ്രോട്ടോക്കോൾ അല്ല. വായനകൾ ഇതിനകം VPN-നായി തിരഞ്ഞെടുത്ത പുറത്തേക്കുള്ള പാക്കറ്റുകൾ നൽകുന്നു, എഴുത്തുകൾ അകത്തേക്കുള്ള പാക്കറ്റുകൾ വീണ്ടും ഇന്റർഫേസിലേക്ക് കുത്തിവയ്ക്കുന്നു. ആ പാക്കറ്റുകൾ എൻക്രിപ്റ്റ് ചെയ്യാനും പ്രാമാണീകരിക്കാനും ഫ്രെയിം ചെയ്യാനും നിങ്ങളുടെ സ്വന്തം ട്രാൻസ്പോർട്ടിനാണ് ചുമതല, കാരണം പ്ലാറ്റ്ഫോം പാക്കറ്റ് അതിർത്തിയിൽ നിർത്തുന്നു.
Binder ഒരു ചുവടാണ്, JNI മറ്റൊരു അച്ചുതണ്ട്
builder അഭ്യർത്ഥന Binder വഴി സിസ്റ്റത്തിലേക്ക് കടക്കുന്നു, അതിന് താഴെ എവിടെയോ പ്ലാറ്റ്ഫോം ഉപകരണം കോൺഫിഗർ ചെയ്യാൻ നേറ്റീവ് കോഡ് വിളിക്കുന്നു. ഒരു കോളിനുള്ളിൽ അടുക്കിവച്ച രണ്ട് വ്യത്യസ്ത സംവിധാനങ്ങളാണ് ഇവ. Binder നിങ്ങളുടെ ആപ്പും സിസ്റ്റം സേവനവും തമ്മിലുള്ള ഇന്റർപ്രോസസ് ആശയവിനിമയമാണ്, JNI ഒരു പ്രോസസ്സിനുള്ളിൽ Java-യിൽ നിന്ന് നേറ്റീവിലേക്കുള്ള പാലമാണ്. Android 9 AOSP ട്രീ വായിക്കുമ്പോൾ സ്റ്റാക്ക് അക്ഷരാർത്ഥത്തിൽ കാണാം, ആന്തരിക ക്ലാസ് നാമങ്ങളും ഫയൽ പാതകളും റിലീസുകൾക്കിടയിൽ മാറുന്നു എന്നത് ഓർക്കേണ്ടതാണ്.
മാറാത്തത് നിങ്ങൾക്ക് ആശ്രയിക്കാവുന്ന കരാറാണ്: builder, അത് തിരികെ നൽകുന്ന ഡിസ്ക്രിപ്റ്റർ, അതിന് ചുറ്റുമുള്ള സേവന ജീവിതചക്രം. ഒരു ഇന്റർഫേസ് ലഭിക്കാൻ ഒരു ആപ്പും ആന്തരിക സേവന ഇടപാട് വിളിക്കുകയോ ഡിവൈസ് നോഡ് വീണ്ടും സൃഷ്ടിക്കുകയോ ചെയ്യരുത്. നിങ്ങളുടെ കോഡ് ഒരു AOSP ക്ലാസ് നാമത്തെ ആശ്രയിക്കുന്നുവെങ്കിൽ, നിങ്ങൾ പരീക്ഷിക്കാത്ത ഒരു റിലീസിൽ അത് തകരും.
TUN IP വഹിക്കുന്നു, TAP Ethernet
TUN ഒരു IP ഇന്റർഫേസാണ്. TAP ഒരു Ethernet ഇന്റർഫേസാണ്, ആ വ്യത്യാസമാണ് ബ്രിഡ്ജിംഗ് സാധ്യമാണോ എന്ന് തീരുമാനിക്കുന്നത്. TUN ഉപകരണത്തിന് MAC വിലാസമില്ല, കൈമാറാനുള്ള Ethernet ഹെഡറുമില്ല, അതിനാൽ റൂട്ടുകൾ എങ്ങനെ എഴുതിയാലും TUN ക്ലയന്റിന് layer-2 ബ്രിഡ്ജിൽ ചേരാനാവില്ല.
VpnService നിങ്ങൾക്ക് IP വകഭേദം നൽകുന്നു, അതാണ് ആപ്പ് തലത്തിലുള്ള VPN-ന് വേണ്ടതും അസംസ്കൃത Ethernet സ്റ്റാക്ക് ഇല്ലാതെ പിന്തുണയ്ക്കാവുന്നതും. നിങ്ങളുടെ ഡിസൈനിന് ബ്രിഡ്ജിംഗ് വേണമെങ്കിൽ, പ്ലാറ്റ്ഫോം വഴി നിങ്ങളെ അവിടെ എത്തിക്കില്ല, കേർണലും ഉപകരണ അനുമതികളും സഹകരിച്ചാൽ മാത്രമേ root വഴി എത്തിക്കൂ.
root വഴി ഇപ്പോഴും വിജയിക്കുന്നിടത്ത്
മൂന്ന് ജോലികൾ ആളുകളെ പ്ലാറ്റ്ഫോം വഴിയിൽ നിന്ന് അകറ്റുന്നു. layer-2 ബ്രിഡ്ജിംഗിന് TAP വേണം. നിങ്ങളുടെ VPN പരിധിക്ക് പുറത്തുള്ള ആപ്പുകളിൽ നിന്നുള്ള ട്രാഫിക് പിടിക്കാൻ ഫ്രെയിംവർക്ക് നൽകാത്ത ദൃശ്യത വേണം. builder ഒരിക്കലും വെളിപ്പെടുത്താത്ത നയ റൂട്ടിംഗ്, ഉദാഹരണത്തിന് ഒരു ലക്ഷ്യത്തിന് പ്രത്യേക ടേബിൾ, നിങ്ങൾ തന്നെ ഇൻസ്റ്റാൾ ചെയ്യുന്ന നിയമങ്ങൾ ആവശ്യപ്പെടുന്നു.
ചെലവുകൾ പിന്നീട് വരുന്നു: അൺലോക്ക് ചെയ്ത bootloader അല്ലെങ്കിൽ root ചെയ്ത ഇമേജ്, നിങ്ങളുടെ കാലിനടിയിൽ നീങ്ങുന്ന SELinux നയം, OTA-യ്ക്ക് ശേഷം ശരിയായി പെരുമാറ്റം നിർത്തുന്ന ഉപകരണം. root ചെയ്ത പാചകക്കുറിപ്പ് സാധാരണ ആപ്പ് വിതരണത്തിലൂടെ അയയ്ക്കാനും കഴിയില്ല, അതിനാൽ മിക്ക ടീമുകളും അത് ഉൽപ്പന്നത്തിന് പകരം ആന്തരിക ഡയഗ്നോസ്റ്റിക് വഴിയായി സൂക്ഷിക്കുന്നു.
ഇവയ്ക്കിടയിൽ തിരഞ്ഞെടുക്കൽ
നിങ്ങളുടെ കൈവശമുള്ള കോഡിൽ നിന്നല്ല, നിങ്ങൾക്ക് ആവശ്യമായ ഇന്റർഫേസിൽ നിന്ന് തുടങ്ങുക. ഉത്തരം ആപ്പ്-പരിമിത റൂട്ടുകളുള്ള TUN ഉപകരണമാണെങ്കിൽ, പ്ലാറ്റ്ഫോം വഴി ചെറുതാണ്, അപ്ഗ്രേഡുകളെ അതിജീവിക്കുന്നു. ഉത്തരത്തിൽ Ethernet ഫ്രെയിമുകൾ, മറ്റ് ആപ്പുകളുടെ ക്യാപ്ചർ, അല്ലെങ്കിൽ builder നിരസിക്കുന്ന റൂട്ടിംഗ് നിയമങ്ങൾ ഉൾപ്പെടുന്നുവെങ്കിൽ, നിങ്ങൾ root പ്രദേശത്താണ്, അത് പ്രവർത്തന ചെലവായി ബജറ്റ് ചെയ്യണം.
മിക്ക തർക്കങ്ങളും തീർക്കുന്ന ഒരു പരിശോധന: ആദ്യം പ്ലാറ്റ്ഫോം വഴി നിർമ്മിക്കുക, establish()-ന്റെ ഫലം ദൂര സെഷന്റെ അവസ്ഥയിൽ നിന്ന് വേർതിരിച്ച് രേഖപ്പെടുത്തുക, ഓരോ ദിശയിലും ഒരു പാക്കറ്റ് സ്ഥിരീകരിക്കുക. അതിന് ശേഷം മാത്രം, കാണാതായ കഴിവ് പിന്തുണയുള്ള വഴി വിടുന്നത് ന്യായീകരിക്കുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുക.