രണ്ട് പേർ ഒരേ ചോദ്യം ചോദിക്കുന്നു, പരസ്പരം പൊരുത്തപ്പെടാത്ത ഉത്തരങ്ങൾ കിട്ടുന്നു, കാരണം അവർ വ്യത്യസ്ത സ്ഥലങ്ങളിൽ നിൽക്കുന്നു. ഒരാളുടെ മുന്നിൽ സിസ്റ്റത്തിന്റെ VPN ക്രമീകരണ സ്ക്രീൻ തുറന്നിരിക്കുന്നു, അയാൾ ആപ്പുകളുടെ പട്ടിക തിരുത്തുന്നു. മറ്റൊരാൾ എഡിറ്ററിൽ VpnService.Builder.addDisallowedApplication() എഴുതുന്നു. ഇരുവരും അതിനെ ആപ്പ് അനുസരിച്ചുള്ള VPN ഫിൽട്ടർ എന്ന് വിളിക്കുന്നു. അവർ വിവരിക്കുന്ന നിയന്ത്രണം ഉള്ളത് അവരിൽ ഒരാൾക്ക് മാത്രമാണ്, ഇരുവരും ഒന്നും ബ്ലോക്ക് ചെയ്യുന്നുമില്ല.

ഉപയോക്താവ് കാണുന്ന സ്ക്രീനിൽ നിന്ന് തുടങ്ങുക

ക്രമീകരണങ്ങൾ തുറക്കുക, VPN എൻട്രി കണ്ടെത്തുക, യഥാർത്ഥത്തിൽ സജീവമായ കണക്ഷൻ നോക്കുക. ക്ലയന്റ് ആപ്പ് അനുസരിച്ചുള്ള പട്ടിക വാഗ്ദാനം ചെയ്താൽ, ആ പട്ടിക ക്ലയന്റിന്റെ സ്വന്തം ടണലിന്റേതാണ്. ബന്ധമില്ലാത്ത ഒരു ആപ്പിന് മറ്റൊരു VPN-ന്റെ ആപ്പ് തിരഞ്ഞെടുപ്പ് വായിക്കാനോ മാറ്റാനോ കഴിയുന്ന പൊതു API പ്ലാറ്റ്ഫോം പ്രസിദ്ധീകരിക്കുന്നില്ല, അതിനാൽ രണ്ടാമത്തെ ആപ്പിന് ഉപയോക്താവിനുവേണ്ടി ആ പട്ടിക ശരിയാക്കാനാകില്ല.

ഇതാണ് ഈ യാത്രയിലെ ആദ്യ കവല. ഇൻസ്റ്റാൾ ചെയ്ത VPN-ന് അത്തരം ക്രമീകരണം ഇല്ലെങ്കിൽ, കോഡ് കൊണ്ട് ഒഴിവാക്കാൻ ഒന്നുമില്ല: ടണൽ ഉള്ള ഉൽപ്പന്നത്തിൽ ആ സവിശേഷതയില്ല. ഉണ്ടെങ്കിൽ, ശരിയായ പരിഹാരം ആ സ്ക്രീനിൽ തന്നെ, അത് തുറക്കാൻ കഴിയുന്ന വ്യക്തിയാൽ.

പാക്കറ്റിനെ ടണലിലേക്ക് പിന്തുടരുക

നിങ്ങളുടെ സ്വന്തം ആപ്പ് ഒരു ടണൽ നിർമ്മിക്കുമ്പോൾ അത് ഒരു TUN ഇന്റർഫേസ് സൃഷ്ടിക്കുകയും ഏത് ആപ്പുകളുടെ ട്രാഫിക് അതിലേക്ക് കയറുന്നു എന്ന് പ്രഖ്യാപിക്കുകയും ചെയ്യുന്നു. അംഗത്വ കോളുകൾ ഇന്റർഫേസ് സ്ഥാപിക്കുന്നതിന് മുമ്പ് സംഭവിക്കുന്നു, അതിനുശേഷം ആ സെഷനിൽ നിയമക്കൂട്ടം സ്ഥിരമാണ്:

val builder = VpnService.Builder()
builder.addAddress("10.8.0.2", 32)
builder.addRoute("0.0.0.0", 0)
builder.addDisallowedApplication("com.example.bypass")
val tun = builder.establish()   // membership decided here

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

ഒഴിവാക്കൽ ബ്ലോക്ക് പോലെ തോന്നിയത് എന്തുകൊണ്ട്

ഒഴിവാക്കിയ ആപ്പ് നിങ്ങളുടെ ടണലിനു ചുറ്റും താഴെയുള്ള നെറ്റ്വർക്കിലേക്ക് അയയ്ക്കപ്പെടുന്നു. അത് അതിനെ ബ്ലോക്ക് ചെയ്യുന്നതിന്റെ വിപരീതമാണ്: ട്രാഫിക് ഇപ്പോഴും ഉപകരണത്തിൽ നിന്ന് പുറത്തുപോകുന്നു, നിങ്ങൾ നിയന്ത്രിക്കുന്ന ഇന്റർഫേസിന് പുറത്ത് മാത്രം. ഫയർവാൾ ശൈലിയിലുള്ള ആപ്പ് ഇതിന് വിപരീതമായി ചെയ്യുന്നു. അത് ആപ്പിന്റെ ട്രാഫിക് സ്വന്തം ടണലിലേക്ക് സ്വീകരിച്ച് പിന്നീട് പാക്കറ്റുകൾ ഉപേക്ഷിക്കുകയോ കൈമാറ്റം ചെയ്യാൻ വിസമ്മതിക്കുകയോ ചെയ്യുന്നു, അതിനാൽ ഇന്റർഫേസ് അതേതാണ്, നയത്തിന്റെ ദിശ മാത്രം തലകീഴായി.

ആ തലകീഴാക്കലിന് പിന്നിലെ ജോലി ഒരു കോൺഫിഗറേഷൻ ഫ്ലാഗല്ല. ടണൽ ഡിസ്ക്രിപ്റ്ററിൽ നിന്ന് നിങ്ങൾ IP പാക്കറ്റുകൾ വായിക്കുന്നു, ഫ്ലോ അനുസരിച്ച് തീരുമാനിക്കുന്നു, എന്നിട്ട് അവ സംരക്ഷിത സോക്കറ്റിലൂടെ കൈമാറുന്നു അല്ലെങ്കിൽ ഉപേക്ഷിക്കുന്നു. നിങ്ങൾ കൈകാര്യം ചെയ്യാത്തതെല്ലാം നിന്നുപോകുന്നു, അതുകൊണ്ടാണ് പകുതി തയ്യാറായ ടണൽ പ്രവർത്തിക്കുന്ന ഫിൽട്ടറല്ല, കേടായ നെറ്റ്വർക്ക് പോലെ തോന്നുന്നത്. ലക്ഷ്യം ബ്ലോക്ക് ആണെങ്കിൽ, പാക്കറ്റ് കൈകാര്യം ചെയ്യൽ, ഫോർഗ്രൗണ്ട് സേവനം, വർഗ്ഗീകരിക്കാൻ കഴിയാത്ത ട്രാഫിക്കിനുള്ള രേഖാമൂലമുള്ള നയം എന്നിവയ്ക്ക് സ്ഥലം കരുതുക.

നിങ്ങൾ തന്നെ നിർമ്മിക്കുമ്പോൾ എന്ത് തകരുന്നു

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

പാക്കറ്റ് ദൃശ്യതയാണ് രണ്ടാം കെണി. ഒരു ആപ്പിന്റെ പാക്കേജ് നാമം പരിഹരിക്കുന്നത് NameNotFoundException ഉപയോഗിച്ച് പരാജയപ്പെടാം, പുതിയ Android പതിപ്പുകളിൽ നിങ്ങൾക്ക് കാണാൻ കഴിയുന്ന പാക്കേജുകളുടെ കൂട്ടം നിങ്ങൾ പ്രഖ്യാപിച്ച ക്വറികളെ ആശ്രയിച്ചിരിക്കുന്നു. എല്ലാ പേരുകളും പരിഹരിക്കുമെന്ന് കരുതുന്നതിനു പകരം എക്സെപ്ഷൻ കൈകാര്യം ചെയ്യുക, ആപ്പുകൾ ഇൻസ്റ്റാൾ ചെയ്യുകയോ നീക്കം ചെയ്യുകയോ ചെയ്യുമ്പോൾ പട്ടിക വീണ്ടും വായിക്കുക, എന്നെന്നും കാഷെ ചെയ്യുന്നതിനു പകരം.

നിയന്ത്രിത ഉപകരണങ്ങൾ മൂന്നാമതൊരു ഉടമയെ ചേർക്കുന്നു. എന്റർപ്രൈസ് മൊബിലിറ്റി നയത്തിന് ആപ്പ് അനുസരിച്ചുള്ള VPN-ഉം എപ്പോഴും-ഓൺ പ്രൊഫൈലും സജ്ജീകരിക്കാം, സാധാരണ ആപ്പിന് അത് അസാധുവാക്കാനാകില്ല. നിങ്ങളുടെ സ്വന്തം കോഡ് ഡീബഗ്ഗ് ചെയ്യുന്നതിന് മുമ്പ് ഉപകരണം നിയന്ത്രിതമാണോ എന്ന് പരിശോധിക്കുക, കാരണം ആ സാഹചര്യത്തിൽ നിങ്ങൾ മാറ്റാൻ ശ്രമിക്കുന്ന പട്ടിക ഫോൺ കൈയിൽ പിടിക്കുന്ന ആർക്കും തിരുത്താൻ കഴിയാത്തതായിരിക്കാം.

നിങ്ങൾ നിയന്ത്രിക്കുന്ന ഒരു ആപ്പ് ഉപയോഗിച്ച് പരീക്ഷിക്കുക

നിങ്ങൾ ഫിൽട്ടർ ചെയ്യാൻ ശ്രമിക്കുന്ന ആപ്പ് ഉപയോഗിച്ച് പരീക്ഷിക്കരുത്. നിങ്ങൾക്ക് നിരീക്ഷിക്കാൻ കഴിയുന്ന നെറ്റ്വർക്ക് സ്വഭാവമുള്ള രണ്ടാമതൊരു ആപ്പ് ഉപയോഗിക്കുക, അതിന്റെ ട്രാഫിക് നിങ്ങളുടെ ടണലിലൂടെ പുറത്തുപോകുന്നുണ്ടോ, ലക്ഷ്യത്തിന്റേത് പോകുന്നില്ലേ എന്ന് പരിശോധിക്കുക. രണ്ടും അകത്ത് നിൽക്കുന്നുവെങ്കിൽ നയം പ്രവർത്തിക്കുന്നു, ലക്ഷ്യം ഒഴിവാക്കപ്പെട്ടിരിക്കുന്നു; ഒന്നും പുറത്തുപോകുന്നില്ലെങ്കിൽ ടണൽ തന്നെ തെറ്റാണ്, ആപ്പ് പട്ടിക പ്രശ്നമല്ല.

എന്നിട്ട് മൂന്നിൽ ഏതാണ് നിങ്ങൾ യഥാർത്ഥത്തിൽ നിർമ്മിക്കുന്നതെന്ന് തീരുമാനിക്കുക. ആപ്പ് അനുസരിച്ചുള്ള ടണൽ ബിൽഡർ API ആണ്, പട്ടിക നിങ്ങളുടെ പ്രൊഫൈലിന്റെ ഭാഗമാണ്. ഉപകരണ ഫയർവാൾ പാക്കറ്റ് കൈകാര്യം ചെയ്യലും സമർത്ഥിക്കാനാകുന്ന ഒരു ജീവിതചക്രവുമാണ്. മറ്റൊരാളുടെ VPN മാറ്റുന്നത് പിന്തുണയ്ക്കുന്ന ഒരു വഴിയേ അല്ല, അവിടെ സത്യസന്ധമായ ഉത്തരം ആ ക്രമീകരണം ആ ഉൽപ്പന്നത്തിന്റേതാണ് എന്നതാണ്.

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