ബ്ലോക്ക് ചെയ്ത Android ആപ്പ് ഇപ്പോഴും നെറ്റ്‌വർക്ക് ഉപയോഗം കാണിക്കുന്നത് എന്തുകൊണ്ട്

നിങ്ങളുടെ Android VPN ഫയർവാളിൽ ഒരു ആപ്പ് ബ്ലോക്ക് ചെയ്യുന്നു, ആപ്പ് പ്രവർത്തിക്കുന്നത് നിർത്തുന്നു, അതിന്റെ ഉപയോഗ വരി ഉയർന്നുകൊണ്ടിരിക്കുന്നു. പ്രലോഭനീയമായ നിഗമനം ബ്ലോക്ക് ചോർന്നു എന്നോ കൗണ്ടർ കേടായി എന്നോ ആണ്. രണ്ടും അനുസരിക്കുന്നില്ല. ഏതെങ്കിലും നിരീക്ഷണ പോയിന്റിൽ ആ ഐഡന്റിറ്റിക്ക് ബൈറ്റുകൾ ആരോപിച്ചു എന്ന് ഉപയോഗ രേഖ പറയുന്നു; ഒരു ദൂര സേവനം അഭ്യർത്ഥന സ്വീകരിച്ചോ എന്നതിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല. ഏത് അതിർത്തിയാണ് അളന്നതെന്നും ഏത് ഐഡന്റിറ്റിക്കാണ് അത് ചുമത്തിയതെന്നും അറിഞ്ഞാൽ, രണ്ട് നിരീക്ഷണങ്ങളും പരസ്പരം വിരുദ്ധമാകുന്നത് നിർത്തുന്നു.

കൗണ്ടർ ബൈറ്റുകൾ അളക്കുന്നു, ഡെലിവറി അല്ല

Android ട്രാഫിക് ഒരു UID യ്ക്ക് ആരോപിക്കുകയും ഇരു ദിശകളിലും എണ്ണുകയും ചെയ്യുന്നു, ഇത് ഇന്റർഫേസ് അതിർത്തിയിൽ ചെയ്യുന്നു, ആപ്പിന്റെ അഭ്യർത്ഥന വിജയിക്കുന്ന നിമിഷത്തിൽ അല്ല.

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

അതുകൊണ്ടാണ് ഓരോ അഭ്യർത്ഥനയും പരാജയപ്പെടുമ്പോഴും ബ്ലോക്ക് ചെയ്ത ആപ്പിന്റെ വരി വളരാം. കൗണ്ടർ ഉത്തരം നൽകുന്നത് «ഈ ഐഡന്റിറ്റിക്ക് എത്ര ബൈറ്റുകൾ ആരോപിച്ചു» എന്നതിനാണ്, «ഈ ഐഡന്റിറ്റി ഇന്റർനെറ്റിൽ എത്തിയോ» എന്നതിനല്ല. ഒരു ചാർട്ടിന് സ്വീകരിച്ച സ്ട്രീമിനെ മാന്യമായി നിരസിച്ച ഹാൻഡ്ഷേക്കിൽ നിന്ന് വേർതിരിക്കാനാവില്ല, രണ്ട് ദിശകളും കൂട്ടുന്ന ആകെത്തുകയ്ക്കും കഴിയില്ല.

ആരോപണം ഐക്കണിനെയല്ല, UID യെ പിന്തുടരുന്നു

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

സംഖ്യകൾ തെറ്റായി തോന്നുമ്പോൾ, ലേബലല്ല, UID താരതമ്യം ചെയ്യുക. ഉപയോഗ API UID വഴി ചോദിക്കുന്നു, താരതമ്യം ചെയ്യേണ്ട സംഖ്യ adb shell dumpsys package <package> | grep userId= പ്രിന്റ് ചെയ്യുന്നു, അതിനാൽ ഒരേ UID ഉള്ള രണ്ട് എൻട്രികൾ കൗണ്ടറിന്റെ കാഴ്ചപ്പാടിൽ ഒരേ ഐഡന്റിറ്റിയാണ്.

സമയ വിൻഡോ നിങ്ങളുടെ നിയമത്തിന് മുൻപുള്ളതാകാം

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

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

VPN സേവനം നിങ്ങൾ കോൺഫിഗർ ചെയ്തതല്ലായിരിക്കാം

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

IPv4, IPv6, DNS എന്നിവയും വ്യത്യാസപ്പെടാം. IPv4 കൈകാര്യം ചെയ്യുന്ന ഫിൽട്ടർ IPv6 അല്ലെങ്കിൽ ഒരു സ്വകാര്യ DNS റിസോൾവർ പുറത്ത് വിട്ടേക്കാം, അതിനാൽ ആപ്പിന്റെ ട്രാഫിക്കിന്റെ ഒരു ഭാഗം നിങ്ങളുടെ നിയമങ്ങൾ ഒരിക്കലും വിവരിക്കാത്ത പാതയിലൂടെ പോകുന്നു. എന്തെങ്കിലും വീണ്ടും എഴുതുന്നതിന് മുൻപ് ഇപ്പോൾ ഏത് ആപ്പാണ് VPN സ്വന്തമാക്കുന്നതെന്നും ഒഴിവാക്കൽ പട്ടിക എന്ത് പറയുന്നുവെന്നും പരിശോധിക്കുക:

adb shell settings get secure always_on_vpn_app
adb shell dumpsys connectivity
adb shell dumpsys netstats detail

ഒരു പുതിയ അഭ്യർത്ഥന പരിശോധിച്ച് നാല് വസ്തുതകൾ രേഖപ്പെടുത്തുക

നിരുപദ്രവകരമായ ഒരു അഭ്യർത്ഥന തിരഞ്ഞെടുക്കുക, ഒരിക്കൽ ചെയ്യുക, നാല് വസ്തുതകൾ എഴുതുക: നിലവിലുള്ള നിയമം, ആപ്പിന്റെ UID, നെറ്റ്‌വർക്ക് അവസ്ഥ, സമയം. പിന്നീട് നിങ്ങളുടെ ഫിൽട്ടർ ഒഴുക്ക് രേഖപ്പെടുത്തിയോ, ലക്ഷ്യമോ ഗേറ്റ്‌വേയോ അതേ കണക്ഷൻ കണ്ടോ എന്ന് പരിശോധിക്കുക. ഇരു വശത്തും തിരിച്ചറിഞ്ഞ ഒരു ഒഴുക്ക് തെളിവാണ്; ആകെത്തുക തെളിവല്ല.

പ്രതിരോധിക്കാവുന്ന നിഗമനം എന്താണ് നിരസിക്കപ്പെട്ടതെന്നും ഏത് നിരീക്ഷണമാണ് അത് സ്ഥിരീകരിച്ചതെന്നും പേരിടുന്നു. «കൗണ്ടർ ഉയർന്നു» ഒരു കണ്ടെത്തലല്ല, «എല്ലാ ഉപയോഗ കൗണ്ടറുകളും വ്യാജമാണ്» എന്നതും അല്ല. OSI പാളിയുടെ മുദ്രാവാക്യം ഇത് തീർപ്പാക്കുന്നില്ല: സത്യസന്ധമായ ഉത്തരം, കൗണ്ടറും ബ്ലോക്കും വ്യത്യസ്ത കാര്യങ്ങൾ വിവരിച്ചുകൊണ്ട് രണ്ടും ശരിയാകാം എന്നതാണ്. Android ന്റെ NetworkStatsManager റഫറൻസ് ആ ബക്കറ്റുകൾ എങ്ങനെ ചോദിക്കുകയും ആരോപിക്കുകയും ചെയ്യുന്നു എന്ന് രേഖപ്പെടുത്തുന്നു.