Android VpnService ചില ട്രാഫിക് മാത്രം പിടിക്കുന്നത് എന്തുകൊണ്ട്, എല്ലാം അല്ല

VpnService-ൽ ഒന്നും സ്വയം ട്രാഫിക് തടയുന്നില്ല. അത് സിസ്റ്റത്തോട് ഒരു tun ഇന്റർഫേസ് ആവശ്യപ്പെടുന്നു, ആ ഇന്റർഫേസിന് വിലാസങ്ങളുടെയും റൂട്ടുകളുടെയും ഒരു കൂട്ടം നൽകുന്നു, ആ നിമിഷം മുതൽ കെർണൽ ആ റൂട്ടുകളുമായി പൊരുത്തപ്പെടുന്ന ഓരോ പാക്കറ്റും ആപ്പിന് വായിക്കാവുന്ന ഒരു ഫയൽ ഡിസ്ക്രിപ്റ്ററിലേക്ക് പകർത്തുന്നു. ആപ്പിന്റെ കോഡ് റൂട്ടുകൾ തിരഞ്ഞെടുക്കാത്ത പാക്കറ്റുകൾ ഒരിക്കലും കാണുന്നില്ല, അതിനാൽ ഒരു ടണലിന്റെ പരിധി പ്രോഗ്രാമിംഗ് ചോദ്യമാകുന്നതിന് മുൻപ് റൗട്ടിംഗ് പട്ടികയുടെ ചോദ്യമാണ്. അതുകൊണ്ടാണ് ഒരേ സേവന നിർവഹണം ഒരു ഫോണിൽ എല്ലാ പ്രവാഹവും വിഴുങ്ങാൻ കഴിയുന്നതും മറ്റൊന്നിൽ ഒരു ഭാഗം മാത്രം, അതുകൊണ്ടാണ് ഒരു റൂട്ട് ചേർക്കുന്നത് ചിലപ്പോൾ തകർന്നതായി തോന്നിയ ടണൽ ശരിയാക്കുന്നതും. നിങ്ങൾക്ക് ലഭിക്കുന്നത് നിങ്ങൾ പ്രഖ്യാപിച്ചത് തന്നെയാണ്, ബിൽഡർ നിശബ്ദമായി നിരസിച്ചതെല്ലാം കുറച്ച്.

ഏത് പാക്കറ്റുകൾ എത്തുമെന്ന് റൂട്ടുകൾ തീരുമാനിക്കുന്നു

Builder.addRoute(prefix, prefixLength) VPN നെറ്റ്വർക്കിന്റെ റൗട്ടിംഗ് പട്ടികയിൽ ഒരു പ്രിഫിക്സ് ഇൻസ്റ്റാൾ ചെയ്യുന്നു. സിസ്റ്റം ആ നെറ്റ്വർക്കിനെ പരിധിയിലെ ആപ്പുകൾക്ക് സ്ഥിരസ്ഥിതിയായി കണക്കാക്കുന്നു, അതിനാൽ അതിന്റെ എൻട്രികൾ ഫിസിക്കൽ നെറ്റ്വർക്കിന്റെ സ്ഥിരസ്ഥിതി റൂട്ടിന് മുൻപ് പരിശോധിക്കപ്പെടുന്നു, പൊരുത്തപ്പെടുന്ന പ്രിഫിക്സ് ഒരു പ്രവാഹം തിരിച്ചുവിടാൻ മതിയാകും. അതിനാൽ 0.0.0.0/0-നുള്ള റൂട്ട് IPv4 മുഴുവനായി എടുക്കുന്നു, പ്രിന്റർ, cast ലക്ഷ്യം, റൂട്ടറിന്റെ അഡ്മിൻ പേജ് എന്നിവയുൾപ്പെടെ.

ഫിസിക്കൽ സ്ഥിരസ്ഥിതി എൻട്രി മായ്ക്കാതെ ആ കവറേജ് ആഗ്രഹിക്കുന്ന ക്ലയന്റുകൾ പകരം 0.0.0.0/1, 128.0.0.0/1 എന്നിവയുടെ ജോടി ഉപയോഗിക്കുന്നു. രണ്ട് കൂടുതൽ നിർദ്ദിഷ്ട റൂട്ടുകൾ സ്ഥിരസ്ഥിതി റൂട്ടിനെ തോൽപ്പിക്കുന്നു, ഒരുമിച്ച് അവ മുഴുവൻ വിലാസ സ്ഥലവും ഉൾക്കൊള്ളുന്നു, ഫോണിന്റെ സ്വന്തം സ്ഥിരസ്ഥിതി എൻട്രി ഇപ്പോഴും ഫിസിക്കൽ നെറ്റ്വർക്കിൽ ബന്ധിപ്പിച്ചിരിക്കുന്ന സോക്കറ്റുകൾക്കായി പട്ടികയിൽ തുടരുന്നു.

വിലാസങ്ങളും DNS എൻട്രികളും ഒരേ ബിൽഡറിൽ നിന്ന് വരുന്നു, മറ്റൊരു ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു. addAddress ഇന്റർഫേസിന് പ്രിഫിക്സ് നീളത്തോടെ ഒരു വിലാസം നൽകുന്നു, addDnsServer പരിധിയിലെ ആപ്പുകൾ ഇന്റർഫേസിലൂടെ ചോദിക്കുന്ന ഒരു റിസോൾവർ ഇൻസ്റ്റാൾ ചെയ്യുന്നു. രണ്ട് കുടുംബങ്ങളും ഒരു ഇന്റർഫേസിൽ ഇരിക്കാം, അതിനാൽ IPv6 വിലാസത്തിന് അടുത്ത് IPv4 മാത്രം റൂട്ടുകളുടെ കൂട്ടം ശരിയായി വായിക്കപ്പെടുകയും എന്നിട്ടും ചോരുകയും ചെയ്യുന്ന ഒരു കോൺഫിഗറേഷനാണ്. ഇന്റർഫേസിന് വിലാസമില്ലാത്ത ഒരു കുടുംബം റൂട്ട് ചെയ്താൽ, ആ പാക്കറ്റുകൾക്ക് കെർണലിന് ഉറവിട വിലാസമില്ല, അവ ഡിസ്ക്രിപ്റ്ററിൽ ഒരിക്കലും പ്രത്യക്ഷപ്പെടുന്നില്ല.

establish() എന്ത് തിരികെ നൽകുന്നു

establish() ഒരു ParcelFileDescriptor തിരികെ നൽകുന്നു, അല്ലെങ്കിൽ ആപ്പിന് അനുമതിയില്ലാത്തപ്പോൾ null. null നെറ്റ്വർക്ക് പിശകല്ല, സമ്മതത്തിന്റെ അവസ്ഥയാണ്: VpnService.prepare() ഇതിനകം null തിരികെ നൽകിയിരിക്കണം, അല്ലെങ്കിൽ ഉപയോക്താവ് കോളിന് മുൻപ് സിസ്റ്റം ഡയലോഗ് അംഗീകരിച്ചിരിക്കണം. സേവനം പ്രവർത്തിക്കുമ്പോൾ സമ്മതം പിൻവലിക്കാം, ഇന്റർഫേസ് നിങ്ങളുടെ വായനാ ലൂപ്പിലേക്ക് ഒരു കോൾബാക്കും നൽകാതെ നിങ്ങളുടെ കാലടിയിൽ അടയുന്നു.

നിങ്ങൾ വേറെ പറയുന്നില്ലെങ്കിൽ ഡിസ്ക്രിപ്റ്റർ ബ്ലോക്ക് ചെയ്യുന്നില്ല, അതിനാൽ വായന ത്രെഡ് നിർത്തിവയ്ക്കുന്നതിന് പകരം ഡാറ്റയില്ലാതെ ഉടൻ മടങ്ങുന്നു. ബ്ലോക്കിംഗ് സോക്കറ്റിനായി എഴുതിയ ലൂപ്പ് ഒരു കോർ കത്തിക്കുന്നു, ശൂന്യമായ വായന മാരകമായി കണക്കാക്കുന്ന ലൂപ്പ് നിഷ്ക്രിയമായ ഒരു സെക്കൻഡിൽ ടണൽ കീറുന്നു. Builder.setBlocking(true) ആ പെരുമാറ്റം മാറ്റുന്നു, വില വായനയ്ക്കുള്ളിൽ കാത്തിരിക്കുന്ന ഒരു ത്രെഡാണ്.

റൂട്ട്, വിലാസ ആർഗ്യുമെന്റുകൾ LinkAddress മൂല്യങ്ങളായി സാധുതയുള്ളതാക്കുന്നു, 224.0.0.0/4 പോലുള്ള മൾട്ടികാസ്റ്റ് ലക്ഷ്യങ്ങൾ നേരിട്ട് നിരസിക്കുന്നു. പോയിന്റ്-ടു-പോയിന്റ് tun ഇന്റർഫേസിനും ബ്രോഡ്കാസ്റ്റ് ഡൊമെയ്ൻ ഇല്ല, അതിനാൽ അതിലൂടെയുള്ള മൾട്ടികാസ്റ്റ് കണ്ടെത്തലിന് മറ്റൊരു റൂട്ടല്ല, വ്യത്യസ്തമായ രൂപകൽപ്പന വേണം. പരിശോധിക്കേണ്ട പട്ടിക VpnService.Builder ആണ്, ഒരു കോൾ അവഗണിക്കപ്പെട്ടു എന്ന് തീരുമാനിക്കുന്നതിന് മുൻപ്.

ഓരോ ആപ്പിലെയും പരിധി കൂട്ടം ചുരുക്കുന്നു, ടണൽ അല്ല

API 21 മുതൽ ബിൽഡർ addAllowedApplication, addDisallowedApplication സ്വീകരിക്കുന്നു, രണ്ട് പട്ടികകളും ഒരു ബിൽഡറിൽ പരസ്പരം ഒഴിവാക്കുന്നവയാണ്. അനുമതി പട്ടിക ആ പാക്കറ്റുകൾക്ക് ടണൽ നിലനിർത്തുന്നു, ബാക്കിയെല്ലാം ഫിസിക്കൽ നെറ്റ്വർക്ക് സൂക്ഷിക്കുന്നു; നിരോധന പട്ടിക പേരിട്ട പാക്കറ്റുകൾ ഒഴികെ എല്ലാം പിടിക്കുന്നു, അതാണ് ഒരു ക്ലയന്റ് വിഭജിത ടണലിംഗായി നൽകുന്നത്. API 21-ന് മുൻപ് പ്ലാറ്റ്ഫോം സംവിധാനമേയില്ല, ഓരോ ആപ്പിലെയും പെരുമാറ്റം സ്വന്തം ഫോർവേർഡറിൽ UID പ്രകാരം ഫിൽട്ടർ ചെയ്യുന്ന മൂന്നാം കക്ഷി ക്ലയന്റുകളിൽ നിന്ന് വന്നു. ഡീബഗ് ചെയ്യുമ്പോൾ ഈ വ്യത്യാസം പ്രധാനമാണ്, കാരണം ഒരു പാക്കറ്റിന്റെ അനുമതി പട്ടികയുള്ള ഓരോ ആപ്പിലെയും ടണൽ ഏതാണ്ട് ട്രാഫിക് ഉത്പാദിപ്പിക്കുന്നില്ല, അത് ശരിയായ പെരുമാറ്റമാണ്, തകർന്ന റൂട്ടല്ല.

പരിധി എന്തായാലും, നിങ്ങളുടെ ആപ്പ് VPN സെർവറിലേക്ക് തുറക്കുന്ന സോക്കറ്റ് അത് നിർമ്മിക്കുന്ന ടണലിലൂടെ സഞ്ചരിക്കരുത്. VpnService.protect(socket) ആ സോക്കറ്റിനെ അടിസ്ഥാന നെറ്റ്വർക്കിലേക്ക് ബന്ധിപ്പിക്കുന്നു, അതിന്റെ പാക്കറ്റുകൾ tun ഉപകരണം ഒഴിവാക്കാൻ. കോൾ ഒഴിവാക്കിയാൽ, ഹാൻഡ്ഷേക്ക് ഉയർത്തേണ്ടിയിരുന്ന ഇന്റർഫേസ് അതിനെ വിഴുങ്ങുന്നു.

VpnService.setUnderlyingNetworks ഏത് ഫിസിക്കൽ നെറ്റ്വർക്കാണ് ടണൽ വഹിക്കുന്നത് എന്ന് സിസ്റ്റത്തോട് പറഞ്ഞ് വൃത്തം അടയ്ക്കുന്നു. ആ മൂല്യം VPN മറ്റ് ആപ്പുകൾക്ക് കണക്റ്റിവിറ്റി എങ്ങനെ റിപ്പോർട്ട് ചെയ്യും എന്ന് നിർണ്ണയിക്കുന്നു, null അല്ലെങ്കിൽ പഴയ മൂല്യം ഫോണിന്റെ ബാക്കി ഭാഗം ഓഫ്ലൈൻ ആയി കണക്കാക്കുന്ന ഒരു കണക്റ്റഡ് ടണലിന്റെ സാധാരണ കാരണമാണ്. അടിസ്ഥാന നെറ്റ്വർക്ക് മാറുമ്പോൾ അത് അപ്ഡേറ്റ് ചെയ്യുക, തുടക്കത്തിൽ മാത്രമല്ല.

ചെക്ക്സമ്മുകളും MTU-യും: ശരിയായ റൂട്ടും പരാജയപ്പെടുന്നിടം

പാക്കറ്റുകൾ എത്തിയാൽ, പാക്കറ്റ് തലത്തിലെ രണ്ട് വിശദാംശങ്ങൾ എന്തെങ്കിലും അറ്റം മുതൽ അറ്റം വരെ പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുന്നു. ആദ്യത്തേത് ഉറവിട വിലാസമാണ്: നിരവധി ഇന്റർഫേസ് വിലാസങ്ങളുണ്ടെങ്കിൽ കെർണൽ ആദ്യത്തേത് വഹിക്കുന്ന പാക്കറ്റുകൾ അയച്ചേക്കാം, അതിനാൽ തലക്കെട്ടുകൾ വീണ്ടും എഴുതുന്ന ഫോർവേർഡർ വിലാസവും അതിനെ മൂടുന്ന ചെക്ക്സവും ശരിയാക്കണം.

രണ്ടാമത്തേത് ചെക്ക്സത്തിന്റെ പരിധിയാണ്. ആപ്പ് സ്വയം TCP അല്ലെങ്കിൽ UDP പാക്കറ്റുകൾ നിർമ്മിക്കുമ്പോൾ, ചെക്ക്സം ഉറവിട വിലാസം, ലക്ഷ്യ വിലാസം, പ്രോട്ടോക്കോൾ നമ്പർ, ഗതാഗത ദൈർഘ്യം എന്നിവ ഉള്ള ഒരു സ്യൂഡോ-തലക്കെട്ട് മൂടുന്നു, അവയിൽ ഏതെങ്കിലും ഒഴിവാക്കിയാൽ എത്തി വലിച്ചെറിയപ്പെടുന്ന പാക്കറ്റുകൾ ലഭിക്കും. ആ പരാജയം ഒരിക്കലും വരാത്ത ഉത്തരത്തിന് ശേഷമുള്ള സമയപരിധി പോലെ തോന്നുന്നു, അത് മിക്കവരെയും റൂട്ടുകളിലേക്ക് തിരികെ അയയ്ക്കുന്നു. setMtu ഇന്റർഫേസിന്റെ MTU സ്ഥിരപ്പെടുത്തുന്നു, ഓരോ വായനയും കൃത്യം ഒരു പൂർണ്ണ IP പാക്കറ്റ് തിരികെ നൽകുന്നു, അതിനാൽ ബൈറ്റ് പ്രവാഹത്തിനായി എഴുതിയ ബഫർ പാക്കറ്റിനെയല്ല, നിങ്ങളുടെ പാഴ്സിംഗിനെ ഖണ്ഡിക്കും.

പാളികളെ വേർതിരിക്കുന്ന ഒരു പരിശോധനാ ഘട്ടം

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

ഡിസ്ക്രിപ്റ്ററിൽ ഒന്നും എത്തുന്നില്ലെങ്കിൽ, സംശയിക്കേണ്ടത് വായനക്കാരനല്ല, റൂട്ടുകളുടെ കൂട്ടമാണ്: പ്രിഫിക്സുകൾ സ്ഥിരീകരിക്കുക, അതേ കുടുംബത്തിൽ ഒരു വിലാസമുണ്ടെന്ന് സ്ഥിരീകരിക്കുക, ആപ്പ് നിങ്ങൾ നിശ്ചയിച്ച പരിധിക്കുള്ളിലാണെന്ന് സ്ഥിരീകരിക്കുക. പാക്കറ്റുകൾ ഡിസ്ക്രിപ്റ്ററിൽ എത്തുന്നുവെങ്കിലും ഒന്നും തിരികെ വരുന്നില്ലെങ്കിൽ, വീണ്ടും ഒരു റൂട്ട് തൊടുന്നതിന് മുൻപ് protect(), അടിസ്ഥാന നെറ്റ്വർക്ക് മൂല്യം എന്നിവ പരിശോധിക്കുക. വിദൂര വശം വികൃത പാക്കറ്റുകൾ റിപ്പോർട്ട് ചെയ്യുന്നുവെങ്കിൽ, ചെക്ക്സവും MTU-യും നോക്കേണ്ട സ്ഥലങ്ങളാണ്. ഓരോ പാളിക്കും ഒരു പരിശോധന പകുതി ദിവസത്തെ ഊഹം ലാഭിക്കുന്നു.