Android VPN സെർവർ: root ഫോണിനെ എത്തിപ്പെടാവുന്നതാക്കുന്നില്ല
ഫോണിന് VPN ക്ലയന്റുകൾക്ക് സേവനം നൽകാനാകുമോ എന്ന് മൂന്ന് വ്യത്യസ്ത പ്രശ്നങ്ങൾ തീരുമാനിക്കുന്നു: ഇൻബൗണ്ട് പാത, അനുമതി മാതൃക, ഫോർവേഡിംഗ്. root നടുക്കുള്ളതിനെ മാത്രം തൊടുന്നു.
root ഒരു പ്രോസസിന് ഏത് നെറ്റ്വർക്കിംഗ് പ്രവർത്തനങ്ങൾ പരീക്ഷിക്കാം എന്ന് മാറ്റുന്നു. ഇത് ഫോണിന് പൊതുവിൽ എത്തിപ്പെടാവുന്ന വിലാസം നൽകുന്നില്ല, ഓപ്പറേറ്ററിൽ ഇൻബൗണ്ട് മാപ്പിംഗ് റിസർവ് ചെയ്യുന്നില്ല, റീബൂട്ടിന് ശേഷം ഡീമണെ ജീവനോടെ നിലനിർത്തുന്നുമില്ല. Android ഫോണിന് VPN സെർവർ ആകാമോ എന്ന് തീരുമാനിക്കുകയാണെങ്കിൽ മൂന്ന് ചോദ്യങ്ങൾ വേർതിരിക്കുക: ഉദ്ദേശിച്ച ക്ലയന്റിന് ലിസണറിൽ എത്താനാകുമോ, സെർവർ നടപ്പാക്കലിന് ഏത് അനുമതി മാതൃക വേണം, ടണൽ ഉയർന്നു കഴിഞ്ഞാൽ എന്ത് ഫോർവേഡ് ചെയ്യണം.
ആര്, എവിടെ നിന്ന് ഫോണിൽ എത്തണം
അതേ അനുവദിച്ച LAN-ലുള്ള ക്ലയന്റും മൊബൈൽ ഡാറ്റയിലുള്ള ക്ലയന്റും രണ്ട് വ്യത്യസ്ത നെറ്റ്വർക്കുകൾ പരീക്ഷിക്കുന്നു. ആദ്യം ഉദ്ദേശിച്ചത് തീരുമാനിക്കുക, കാരണം ഉത്തരങ്ങൾ പരസ്പരം കൈമാറില്ല. Wi-Fi-യിൽ ആവശ്യപ്പെടാത്ത ഇൻബൗണ്ട് ട്രാഫിക്കിന് സാധാരണയായി അപ്സ്ട്രീം റൗട്ടറിൽ മാപ്പിംഗും അതിനപ്പുറം ഉപയോഗയോഗ്യമായ പൊതു പാതയും വേണം. സെല്ലുലാറിൽ ഓപ്പറേറ്റർ തലത്തിലുള്ള NAT അർത്ഥമാക്കുന്നത് ഇൻബൗണ്ട് IPv4 പലപ്പോഴും ലഭ്യമല്ല എന്നാണ്, ഫോൺ എന്ത് അനുവദിച്ചാലും.
ആ അവസാന പോയിന്റിലാണ് root തൊടാനാകാത്തത്. ഫോണിന്റെ ലോക്കൽ ഫയർവാളും ഓപ്പറേറ്ററുടെ NAT-ഉം വ്യത്യസ്ത സംവിധാനങ്ങളാണ്, ആദ്യത്തേത് മാറ്റുന്നത് രണ്ടാമത്തേതിൽ യാതൊരു ഫലവും ചെലുത്തുന്നില്ല. സ്വകാര്യ ഇന്റർഫേസ് വിലാസം, മൊബൈൽ-ഡാറ്റ ഐക്കൺ, അല്ലെങ്കിൽ കേൾക്കുന്ന സോക്കറ്റ് എന്നിവ എത്തിപ്പെടാനുള്ള തെളിവല്ല. ഓപ്പറേറ്റർ പാത ആഗോളമായി റൂട്ട് ചെയ്യാവുന്ന IPv6 വാഗ്ദാനം ചെയ്താലും അതിന് ബോധപൂർവമായ ലിസണർ, ഫയർവാൾ നയം എന്നിവ ഇപ്പോഴും വേണം; വിലാസം ഉണ്ടായിരിക്കുന്നത് കണക്ഷനുകൾ സ്വീകരിക്കുന്നതിന് തുല്യമല്ല.
| Client path | What actually decides reachability |
|---|---|
| Same LAN | The phone's listener and its local firewall |
| Wi-Fi, from the internet | A mapping on the upstream router plus a usable public path beyond it |
| Cellular IPv4 | The carrier's NAT, which the handset does not control |
| Cellular IPv6 | Address, listener and firewall policy together |
സേവനം നൽകലും ഫോർവേഡിംഗും രണ്ട് വ്യത്യസ്ത വിജയങ്ങളാണ്
പൂർത്തിയായ VPN ഹാൻഡ്ഷേക്ക് ടണൽ നിലവിലുണ്ടെന്ന് തെളിയിക്കുന്നു. ക്ലയന്റിന് ഫോണിന് പിന്നിലുള്ള LAN-ൽ എത്താമെന്നോ ഫോണിന് ഇന്റർനെറ്റ് എക്സിറ്റ് ആകാമെന്നോ അത് തെളിയിക്കുന്നില്ല. അവ ഒറ്റപ്പെട്ട കോൺഫിഗറേഷനുകളാണ്; ആന്തരിക വിലാസ പ്ലാൻ, റൂട്ടുകൾ, തിരിച്ചുവരവ് സ്വഭാവം, നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ വേണ്ട ജോലിക്കായുള്ള ഇടുങ്ങിയ ഫോർവേഡിംഗ് നയം എന്നിവയിൽ അവ നിർമ്മിക്കുന്നു.
പരാജയ മാതൃക പ്രവചനീയമാണ്: ഹാൻഡ്ഷേക്ക് വിജയിക്കുന്നു, ക്ലയന്റ് കണക്റ്റുചെയ്തതായി കാണിക്കുന്നു, ഒന്നും ലോഡ് ചെയ്യുന്നില്ല. ക്ലയന്റ് ഡീബഗ് ചെയ്യുന്നതിന് മുൻപ് രണ്ട് റോളുകളിൽ ഏതാണ് നിർമ്മിക്കുന്നതെന്ന് തീരുമാനിക്കുക. ഫോണിന്റെ നെറ്റ്വർക്കിലെ ഒരു ഉപകരണത്തിലേക്കുള്ള റിമോട്ട് ആക്സസും പൂർണ്ണ-ടണൽ ഇന്റർനെറ്റ് എക്സിറ്റും വ്യത്യസ്ത ഫോർവേഡിംഗ് നിയമങ്ങൾ ആവശ്യപ്പെടുന്നു, ഒന്ന് വേണ്ടിടത്തോൾ രണ്ടും നൽകുന്നത് നിങ്ങൾ ആവശ്യപ്പെട്ട കഴിവ് ചേർക്കാതെ എക്സ്പോഷർ വിപുലീകരിക്കുന്നു.
അനുമതി മാതൃക ഒരു തിരഞ്ഞെടുപ്പാണ്, root അല്ലെങ്കിൽ ഒന്നുമില്ല എന്നല്ല
കേർണൽ TUN ഉപകരണം ഉപയോഗിക്കുന്ന സാധാരണ OpenVPN ഡീമണിന് അനുബന്ധ കഴിവുകളും ഉപകരണ നോഡിലേക്കുള്ള ആക്സസും Android-ന്റെ സുരക്ഷാ നയത്തിന്റെ സഹകരണവും വേണം. root SELinux-ൽ നിന്നുള്ള സമഗ്ര ഒഴിവാക്കലല്ല; പ്രത്യേകാവകാശമുള്ള പ്രോസസും പ്ലാറ്റ്ഫോം നയത്താൽ പരിമിതമാണ്. അതുകൊണ്ടാണ് Linux സെർവറിൽ സുഖമായി പ്രവർത്തിക്കുന്ന ബൈനറി ഫോണിൽ അനുമതികളെക്കുറിച്ച് വ്യക്തമായ പിശകില്ലാതെ പരാജയപ്പെടാവുന്നത്.
യൂസർസ്പേസ് ഗേറ്റ്‌വേ നടപ്പാക്കലിന് തികച്ചും വ്യത്യസ്തമായ അനുമതി മാതൃക ആകാം, അതിനാൽ Android-ലെ എല്ലാ VPN സെർവറിനും root വേണമെന്ന സാധാരണ അവകാശവാദം വളരെ വിശാലമാണ്. root നിങ്ങൾക്ക് നൽകുന്നത് കൂടുതൽ പ്രവർത്തനങ്ങൾ പരീക്ഷിക്കാനുള്ള കഴിവാണ്, അവ അനുവദിക്കപ്പെടുമെന്നോ ഫലം എത്തിപ്പെടാവുന്നതാകുമെന്നോ ഉള്ള ഉറപ്പല്ല.
Android-ന്റെ സ്വന്തം VPN സേവന രജിസ്ട്രേഷൻ വീണ്ടും വേറൊരു സംവിധാനമാണ്. അത് ആപ്പിന് നിർവചിക്കപ്പെട്ട ജീവിതചക്രമുള്ള മാനേജുചെയ്ത ക്ലയന്റ് ഇന്റർഫേസ് നൽകുന്നു; അത് പൊതുവായ സെർവർ ഇൻസ്റ്റാളർ അല്ല, ടെർമിനലിൽ നിന്ന് ഡീമൺ ആരംഭിക്കുന്നത് അതിന് സ്ഥിരമായ മാനേജ്മെന്റോ പ്രതി-ആപ്പ് നയമോ സ്വന്തം വീണ്ടെടുപ്പ് പാതയോ നൽകുന്നില്ല.
നിങ്ങൾക്ക് എക്സിറ്റ് പോയിന്റ് വേണമെങ്കിൽ ആർക്കിടെക്ചർ മാറ്റുക
നിലവിലുള്ള OpenVPN പ്രൊഫൈലുമായുള്ള പൊരുത്തമല്ല, മറിച്ച് ഫോണിലൂടെയുള്ള റിമോട്ട് ഇന്റർനെറ്റ് എക്സിറ്റ് മാത്രമാണ് ലക്ഷ്യമെങ്കിൽ, ഓവർലേ നെറ്റ്വർക്കിലെ പിന്തുണയുള്ള എക്സിറ്റ് നോഡാണ് കൂടുതൽ അനുയോജ്യമായ രൂപകൽപ്പന. Tailscale തന്റെ രജിസ്ട്രേഷൻ, അംഗീകാരം, ക്ലയന്റ്-തിരഞ്ഞെടുപ്പ് ഘട്ടങ്ങളോടെ Android എക്സിറ്റ്-നോഡ് റോൾ രേഖപ്പെടുത്തുന്നു.
ഈ കൈമാറ്റം യാഥാർത്ഥ്യമാണ്, വ്യക്തമായി പറയാനർഹമാണ്: നിങ്ങൾ വ്യത്യസ്ത പ്രോട്ടോക്കോളും വ്യത്യസ്ത വിശ്വാസ മാതൃകയും ആ അക്കൗണ്ടിലും ഏകോപന സേവനത്തിലുമുള്ള ആശ്രിതത്വവും സ്വീകരിക്കുന്നു. അത് മാറ്റമില്ലാത്ത OpenVPN ക്ലയന്റിനെ ഓവർലേയിൽ ചേരാൻ പ്രേരിപ്പിക്കുന്നില്ല, പൊതു വിലാസത്തിൽ OpenVPN ലിസണറും നൽകുന്നില്ല.
വിന്യാസത്തിന് ഇനിയും എന്ത് വേണം
ഏത് പാത സ്വീകരിച്ചാലും, പ്രവർത്തന അടിത്തറയാണ് അത് ഒരാഴ്ച നിലനിൽക്കുമോ എന്ന് തീരുമാനിക്കുന്നത്. സെർവർ ക്രെഡൻഷ്യലുകൾ സ്വകാര്യമായി സൂക്ഷിക്കുക, വ്യത്യസ്ത ക്ലയന്റ് ഐഡന്റിറ്റികൾ നൽകുക, ആവശ്യമാകുന്നതിന് മുൻപ് റദ്ദാക്കൽ ആസൂത്രണം ചെയ്യുക. അപ്‌ഡേറ്റുകൾ എങ്ങനെ വരുന്നു, പശ്ചാത്തലത്തിൽ സേവനം എന്ത് സജീവമായി നിർത്തുന്നു, റീബൂട്ടിനോ നെറ്റ്വർക്ക് മാറ്റത്തിനോ ശേഷം അത് എങ്ങനെ കരകയറുന്നു എന്നിവ തീരുമാനിക്കുക.
സൗകര്യപ്രദമെന്ന് തോന്നുന്ന ഷോർട്ട്കട്ടുകൾ ഒഴിവാക്കുക: കാലഹരണപ്പെട്ട സ്റ്റാറ്റിക് ബൈനറി, ഹാർഡ്കോഡ് ചെയ്ത ഇന്റർഫേസ് പേരുകൾ, നിലവിലുള്ള ഫയർവാൾ നയം മായ്ക്കുന്ന സ്റ്റാർട്ടപ്പ് സ്ക്രിപ്റ്റ്. തുടർന്ന് ഫലം ഒരു വ്യക്തമായ പരീക്ഷണത്തിൽ മാത്രം സ്വീകരിക്കുക: അധികാരമുള്ള റിമോട്ട് ക്ലയന്റ് ഉദ്ദേശിച്ച ഉറവിടത്തിൽ എത്തുന്നു, നിരോധിത ലക്ഷ്യങ്ങൾ ലഭ്യമല്ലാതെ തുടരുന്നു, പിന്തുണയുള്ള ജീവിതചക്ര സംഭവത്തിന് ശേഷം ഉപകരണം സ്വയം മടങ്ങിവരുന്നു. root ആക്സസ് ആ ഫലത്തിലെ ഒരു സാധ്യമായ ഘടകമാണ്, അപൂർവ്വമായി മാത്രം നിർണ്ണായകം.