ഐതിഹ്യം ഇതാണ്: L2TP Android-ൽ shell സ്ക്രിപ്റ്റിന് ആരംഭിക്കാവുന്ന മറ്റൊരു കാര്യമാണ്: ഒരു റൂട്ട് ചേർക്കുക, പഴയ സേവനത്തെ വിളിക്കുക, കഴിഞ്ഞു. അങ്ങനെയാകാൻ കഴിയില്ല, കാരണം ടണൽ ഒരു പാക്കറ്റ് കൊണ്ടുപോകുന്നതിന് മുമ്പ് നാല് വ്യത്യസ്ത പാളികൾ യോജിക്കണം. IPsec പാളി പാത സംരക്ഷിക്കുന്നു, L2TP സെഷൻ കൊണ്ടുപോകുന്നു, PPP ലിങ്ക് ചർച്ച ചെയ്യുന്നു, Android ഫലം ഒരു VPN ആയി രജിസ്റ്റർ ചെയ്യണം, അതിനുചുറ്റും അതിന് റൂട്ട് ചെയ്യാനാകും. പകർത്തിയ കമാൻഡുകളുപയോഗിച്ച് ഇത് രണ്ടുതവണ ശ്രമിക്കുന്നത് ഞാൻ കണ്ടിട്ടുണ്ട്, രണ്ടുതവണയും റൂട്ട് നിലനിന്നിരുന്നു, പക്ഷേ ഒന്നും എൻക്രിപ്റ്റ് ചെയ്തിരുന്നില്ല.

റൂട്ട് മാറ്റം യഥാർത്ഥത്തിൽ എന്ത് സാധിക്കുന്നു

ഒരു റൂട്ട് ചേർക്കുന്നത് പാക്കറ്റ് അടുത്തതായി എവിടെ പോകുമെന്ന് തീരുമാനിക്കുന്നു. അത് ഒരു സുരക്ഷാ അസോസിയേഷൻ ചർച്ച ചെയ്യുന്നില്ല, L2TP സെഷൻ തുറക്കുന്നില്ല, വിലാസവും പിയറും DNS ക്രമീകരണങ്ങളും ഉണ്ടാക്കുന്ന PPP കൈമാറ്റം നടത്തുന്നുമില്ല. ഹാൻഡ്സെറ്റിൽ കാണുന്ന ഫലം തെറ്റായ പാതയിലൂടെ പുറത്തുപോകുന്ന ട്രാഫിക്ക്, അല്ലെങ്കിൽ പുറത്തുപോയി മരിക്കുന്ന ട്രാഫിക്ക് ആണ്, എവിടെയും ടണൽ അവസ്ഥയില്ലാതെ.

പഴയ റിലീസിൽ നിന്ന് പകർത്തിയ സേവന വിളിക്കും ഇതുതന്നെ ബാധകം. Android-ന്റെ ആന്തരിക VPN പ്ലംബിംഗ് പ്രസിദ്ധീകരിച്ച ഓട്ടോമേഷൻ API അല്ല, മറ്റൊരു പതിപ്പിലെ അക്കമിട്ട ഇടപാട് മറ്റൊരു പ്രവർത്തനത്തിൽ എത്താം അല്ലെങ്കിൽ സ്ക്രിപ്റ്റിനില്ലാത്ത അനുമതികൾ ആവശ്യപ്പെടാം. പാസ്വേഡ് കൊണ്ടുപോകുന്ന ഓട്ടോമേഷൻ ഒരിക്കലും ഊഹിച്ച ആന്തരിക ആർഗ്യുമെന്റുകളെ ആശ്രയിക്കരുത്, കാരണം പരാജയരീതി നിശ്ശബ്ദമായ no-op അല്ലെങ്കിൽ ആരും വൃത്തിയാക്കാത്ത പകുതി നിർമ്മിച്ച പ്രൊഫൈൽ ആണ്.

നാല് ഉടമകൾ, സ്ക്രിപ്റ്റ് അവരിൽ ഒന്നുമല്ല

ക്രമത്തിൽ എടുക്കുക. IPsec സംരക്ഷിത പാത സ്ഥാപിച്ച് നിലനിർത്തുന്നു, പിയറുകളെ പ്രാമാണീകരിക്കുന്നു. L2TP അതിനുമേലെ സെഷൻ കൊണ്ടുപോകുന്നു, ഈ പാളിവിഭജനമാണ് സ്റ്റാൻഡേർഡ് അവയെ ഒരു പ്രോട്ടോക്കോളല്ല, വേർതിരിച്ച സംവിധാനങ്ങളായി കാണാൻ കാരണം. അതിനുള്ളിൽ PPP ക്ലൈന്റ് ഉപയോഗിക്കുന്ന ലിങ്ക് പാരാമീറ്ററുകൾ ചർച്ച ചെയ്യുന്നു. തുടർന്ന് Android പ്ലാറ്റ്ഫോം വശം കൈവശം വയ്ക്കുന്നു: രജിസ്റ്റർ ചെയ്ത VPN ഇന്റർഫേസ്, ആപ്പിന് അനുസരിച്ചുള്ള പരിധി, always-on അവസ്ഥ, ആപ്പ് കൊല്ലപ്പെടുമ്പോൾ എന്ത് സംഭവിക്കുമെന്ന് തീരുമാനിക്കുന്ന ജീവിതചക്രം.

സ്ക്രിപ്റ്റിന് ആ പാളികളിൽ അവസാനത്തേത് മാത്രമേ കാണാനാകൂ, സാധാരണയായി പരോക്ഷമായി. ആ ക്ലൈന്റ് രേഖപ്പെടുത്തിയ നിയന്ത്രണം വെളിപ്പെടുത്തുന്നുവെങ്കിൽ അതിന് ക്ലൈന്റിനോട് കണക്ട് ചെയ്യാൻ ആവശ്യപ്പെടാം, പിന്നീട് ഇന്റർഫേസ് അവസ്ഥ നിരീക്ഷിക്കാം. താഴെയുള്ള മൂന്ന് പാളികളെ അതിന് മാറ്റാനാകില്ല, രജിസ്റ്റർ ചെയ്യാത്ത ഇന്റർഫേസിനെ VPN ആയി കാണാൻ പ്ലാറ്റ്ഫോമിനെ നിർബന്ധിക്കാനും കഴിയില്ല.

ഡീമണും ചെറുകുത്തുവഴിയല്ലാത്തത് എന്തുകൊണ്ട്

ഉപകരണത്തിൽ പ്രത്യേകാവകാശമുള്ള Linux ഡീമൺ ആരംഭിക്കുന്നത് കാണാത്ത കഷണം പോലെ തോന്നുന്നു, പലപ്പോഴും അത് ശരിക്കും ഒരു ടണൽ ഉയർത്തുന്നു. അത് ചെയ്യാത്തത് ആ ടണൽ Android-ൽ രജിസ്റ്റർ ചെയ്യുന്നതാണ്. ഇന്റർഫേസ് കേണലിനുള്ളിൽ നിലനിൽക്കുന്നു, പക്ഷേ പ്ലാറ്റ്ഫോമിന്റെ VPN തിരഞ്ഞെടുപ്പ്, ആപ്പിന് അനുസരിച്ചുള്ള റൂട്ടിംഗ്, always-on നയം, ജീവിതചക്രം എന്നിവ അതിനെ അറിയുന്നില്ല, ഡീമണിന്റെ സ്വന്തം റൂട്ട്, DNS മാറ്റങ്ങൾ അതേ പട്ടികകൾക്കായി നെറ്റ്വർക്ക് മാനേജറുമായി മത്സരിക്കുന്നു.

ഫലം ഡീമണിന്റെ ട്രാഫിക്കിന് പ്രവർത്തിക്കുകയും നിങ്ങൾക്ക് പ്രധാനമായിരുന്ന ആപ്പിന് അദ്ഭുതകരമായി പ്രവർത്തിക്കാതിരിക്കുകയും ചെയ്യുന്ന ഒരു കണക്ഷൻ, അല്ലെങ്കിൽ സിസ്റ്റം അതിന്റെ നെറ്റ്വർക്കുകൾ വീണ്ടും വിലയിരുത്തുന്നതുവരെ നിലനിൽക്കുന്ന ഒന്ന്. രണ്ട് ഫലങ്ങളും പ്ലാറ്റ്ഫോം ബഗ്ഗല്ല; സോക്കറ്റ് കൈവശം വയ്ക്കുന്നതും VPN സൗകര്യം കൈവശം വയ്ക്കുന്നതും തമ്മിലുള്ള അതിർത്തിയാണ്.

പിന്തുണയ്ക്കുന്ന പാതകൾ എങ്ങനെയിരിക്കും

സംഘടന Android തന്നെ നൽകുന്ന ഒരു പ്രൊഫൈലിലേക്ക് മാറാനാകുമെങ്കിൽ, പ്ലാറ്റ്ഫോം പാതയാണ് സത്യസന്ധമായത്. API 30 മുതൽ, VpnManager ആപ്പുകൾക്ക് പ്ലാറ്റ്ഫോം VPN പ്രൊഫൈലുകളുടെ വിതരണവും നിയന്ത്രണവും പിന്തുണയ്ക്കുന്നു, വിളിക്കുന്ന ആപ്പുമായി ബന്ധിപ്പിച്ച അംഗീകാര പ്രവാഹത്തോടെ. ഇത് L2TP പരിവർത്തകമല്ല: IKEv2-നായി അത് നൽകുന്ന പ്രൊഫൈൽ മാതൃക നിലവിലുള്ള L2TP കോൺഫിഗറേഷൻ വിവർത്തനം ചെയ്യുന്നില്ല, പ്രോട്ടോക്കോൾ മാറ്റുന്നത് കുടിയേറ്റമാണ്, പേരുമാറ്റമല്ല. ഐഡന്റിറ്റികൾ, റൂട്ടുകൾ, സ്വകാര്യ DNS, ആക്സസ് അനുമതികൾ എന്നിവ ബോധപൂർവം കൈമാറണം.

സേവനം L2TP/IPsec ആയി തുടരേണ്ടതുണ്ടെങ്കിൽ, പിന്തുണയ്ക്കുന്ന സംയോജനം ഓപ്പറേറ്റർ യഥാർത്ഥത്തിൽ രേഖപ്പെടുത്തുന്ന ക്ലൈന്റും OS റിലീസും, അതിന്റെ ഓട്ടോമേഷൻ കരാർ ഉണ്ടെങ്കിൽ അതുമാണ്. രേഖപ്പെടുത്തിയ മേൽനോട്ടമില്ലാത്ത നിയന്ത്രണം ഇല്ലാത്തപ്പോൾ ശരിയായ ഉത്തരം പിന്തുണയ്ക്കുന്ന മാനുവൽ കണക്ഷനാണ്, ഒരു ബിൽഡിൽ യാദൃച്ഛികമായി പ്രവർത്തിക്കുന്ന ദുർബലമായ പ്രത്യേകാവകാശ സ്ക്രിപ്റ്റല്ല.

ശരിയായ ഓട്ടോമേഷൻ എന്ത് ചെയ്യുന്നു

രേഖപ്പെടുത്തിയ നിയന്ത്രണം ലഭ്യമായാൽ, ഓട്ടോമേഷന് ചെറുതും പ്രതിരോധിക്കാവുന്നതുമായ ജോലിയുണ്ട്: പേരിട്ട കണക്ഷൻ അഭ്യർത്ഥിക്കുക, തയ്യാറാകുന്നതുവരെ കാത്തിരിക്കുക, പ്രാമാണീകരണമോ സെറ്റപ്പോ പരാജയപ്പെട്ടാൽ നിർത്തുക, ഉദ്ദേശിച്ച ജോലിഭാരം പ്രവർത്തിപ്പിക്കുക, വൃത്തിയാക്കൽ കണക്ഷൻ കൈവശം വയ്ക്കുന്ന ഘടകത്തിന് വിടുക. ക്രെഡൻഷ്യലുകൾ അവ സൂക്ഷിക്കാനും കറക്കാനും അറിയുന്ന ക്ലൈന്റിന്റെ പക്കൽ തുടരുന്നു.

ആദ്യ വരി എഴുതുന്നതിന് മുമ്പ് ഏത് ഘടകം ഏത് പാളി കൈവശം വയ്ക്കുന്നുവെന്ന് എഴുതുക, ഫലം അതിനെതിരെ പരിശോധിക്കുക:

  • IPsec-ഉം PPP-യും ക്ലൈന്റാണ് കൈകാര്യം ചെയ്യുന്നത്, സ്ക്രിപ്റ്റിന്റെ റൂട്ടുകളല്ല.
  • കണക്ഷൻ പ്ലാറ്റ്ഫോമിന്റെ VPN അവസ്ഥയിൽ പ്രത്യക്ഷപ്പെടുന്നു, അതിനാൽ ആപ്പിന് അനുസരിച്ചുള്ള പരിധിയും always-on-ഉം അതിന് ബാധകമാണ്.
  • ഒരു ആന്തരിക സേവന വിളിയോ ഇടപാട് നമ്പറോ ഊഹിച്ച ആർഗ്യുമെന്റോ ക്രെഡൻഷ്യൽ കൊണ്ടുപോകുന്നില്ല.
  • ഏതെങ്കിലും ഘട്ടത്തിലെ പരാജയം പകുതി രജിസ്റ്റർ ചെയ്ത പ്രൊഫൈൽ അവശേഷിപ്പിക്കുന്നില്ല.

അനുബന്ധ ലേഖനങ്ങൾ