ഉപകരണത്തിലെ VPN മാർക്കർ അല്ലെങ്കിൽ എക്സിറ്റ് വിലാസം: ഏത് എന്ത് തെളിയിക്കുന്നു?

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

രണ്ട് നിരീക്ഷണ കേന്ദ്രങ്ങൾ, രണ്ട് തരം തെളിവുകൾ

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

രണ്ടും കലർത്തുമ്പോൾ കൃത്യമായി തോന്നുന്നതും പരിശോധിക്കാനാവാത്തതുമായ വാദങ്ങൾ ഉണ്ടാകുന്നു. മാർക്കർ ഉപകരണത്തിലെ നെറ്റ്വർക്ക് ഒബ്ജക്റ്റിനെക്കുറിച്ച് എന്തോ തെളിയിക്കുന്നു, വിദൂര സേവനം അഭ്യർത്ഥന എങ്ങനെ വർഗ്ഗീകരിക്കുന്നു എന്നതിനെക്കുറിച്ചല്ല.

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

പ്രാദേശിക പ്ലാറ്റ്ഫോം ഇന്റർഫേസിന് എന്ത് റിപ്പോർട്ട് ചെയ്യാനാവും

Android ഒരു നിർദ്ദിഷ്ട മാർക്കർ നൽകുന്നു. NetworkCapabilities ഒബ്ജക്റ്റിന് TRANSPORT_VPN റിപ്പോർട്ട് ചെയ്യാനാവും, കൂടാതെ hasTransport ആ ട്രാൻസ്പോർട്ട് ഒബ്ജക്റ്റിൽ ഉണ്ടോ എന്ന് പരിശോധിക്കുന്നു. ആപ്പ് കണക്റ്റിവിറ്റി സേവനത്തിൽ നിന്ന് ഒബ്ജക്റ്റ് വാങ്ങി വായിക്കുന്നു, നെറ്റ്വർക്ക് അവസ്ഥയുടെ അനുമതിക്ക് വിധേയമായി.

ഫലം പ്രാദേശിക പ്ലാറ്റ്ഫോം വിവരമാണ്, ഒരു ദാതാവിന്റെ വിലാസ ശ്രേണികളിൽ തിരയലല്ല. വിളിക്കുന്ന ആപ്പ് ഉപയോഗിക്കുന്ന നെറ്റ്വർക്കിനെ ഇത് വിവരിക്കുന്നു.

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

adb shell dumpsys connectivity | grep -i -m5 vpn

വിദൂര സേവനത്തിന് എന്ത് കാണാനാവും

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

ഒരു ഹോസ്റ്റിംഗ് ദാതാവിൽ രജിസ്റ്റർ ചെയ്ത വിലാസം ടണലിനെ സൂചിപ്പിക്കുന്നു, അതേസമയം ഒരു വാസസ്ഥല നെറ്റ്വർക്കിൽ രജിസ്റ്റർ ചെയ്ത വിലാസം വീട്ടിലെ കണക്ഷനെ സൂചിപ്പിക്കുന്നു. രണ്ടും സ്ഥിതിവിവര സൂചനകളാണ്, ഉപകരണത്തെക്കുറിച്ചുള്ള വസ്തുതകളല്ല.

വാസസ്ഥല വിലാസം വ്യക്തിയെ ആ വിലാസത്തിൽ ഇരുത്തുന്നില്ല, ഹോസ്റ്റിംഗ് വിലാസം ഓപ്പറേറ്ററെയോ രാജ്യത്തെയോ പേരെടുത്ത് പറയുന്നുമില്ല. അനുമാനത്തെ ഉറപ്പായി കാണുന്ന സേവനം ചിലപ്പോൾ തെറ്റും, അത് കണ്ടെത്താനാകാതെ. ആവശ്യം റൂൾ ഓഫ് തംബ് അല്ലാതെ വിശ്വാസ്യതയാണെങ്കിൽ, വിലാസ ഡാറ്റ അത് നൽകാനാവില്ല, അത് പറയുന്ന രൂപകൽപ്പന അനുമാനം മറയ്ക്കുന്നതിനെക്കാൾ സത്യസന്ധമാണ്.

സ്വയം ഹോസ്റ്റ് ചെയ്ത എക്സിറ്റ് ഒരു വശത്തെ മാത്രം മാറ്റുന്നത് എന്തുകൊണ്ട്

സ്വന്തം എൻഡ്പോയിന്റ് പ്രവർത്തിപ്പിക്കുമ്പോൾ വിദൂര സേവനം കാണുന്ന ഉറവിട വിലാസം മാറുന്നു, അത് സേവനം വാണിജ്യ ദാതാക്കളുമായി ബന്ധിപ്പിക്കുന്ന ശ്രേണികൾക്ക് പുറത്തേക്ക് അതിനെ നീക്കാം. പ്രാദേശിക നെറ്റ്വർക്ക് മാതൃകയിൽ ഒന്നും മാറുന്നില്ല, കാരണം ടണൽ ടണലായി തുടരുന്നു, ഓപ്പറേറ്റിംഗ് സിസ്റ്റം അത് ഇപ്പോഴും റിപ്പോർട്ട് ചെയ്യുന്നു.

തെളിവിന്റെ ഒരു വശം നീങ്ങുന്നു, മറ്റേത് നിശ്ചലമായി നിൽക്കുന്നു. അവയ്ക്കിടയിലെ വിടവാണ് പ്രതീക്ഷകൾ പൊട്ടുന്നിടം.

ബ്രൗസർ സ്വന്തം ഇന്റർഫേസുകളും നിയന്ത്രണങ്ങളുമുള്ള മൂന്നാമത്തെ കേസാണ്. വെബ് ഉള്ളടക്കത്തിന് നേറ്റീവ് കഴിവ് ഒബ്ജക്റ്റ് വായിക്കാനാവില്ല, മൊബൈൽ ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ സവിശേഷത വെബ് പേജിന് ലഭ്യമാണെന്ന് കരുതുന്നത് വർഗ്ഗ പിശകാണ്. ചോദ്യം ഒരു വെബ്സൈറ്റിനെ സംബന്ധിക്കുന്നതാണെങ്കിൽ, പ്ലാറ്റ്ഫോം API പകർത്തുന്നതിന് പകരം വെബ്സൈറ്റിന് യഥാർത്ഥത്തിൽ എന്ത് ലഭിക്കാം എന്ന് പഠിക്കുക.

നിങ്ങൾ ചോദിക്കുന്ന ചോദ്യം കൊണ്ട് തീരുമാനിക്കുക

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

എന്തെങ്കിലും ശേഖരിക്കുന്നതിന് മുൻപ് ചോദ്യത്തിന് ഒരു വാക്യത്തിൽ പേര് നൽകുക. ആ വാക്യം ഏത് നിരീക്ഷണ കേന്ദ്രമാണ് പ്രധാനം എന്ന് തീരുമാനിക്കുന്നു, അന്വേഷണം മറ്റൊരു വാദത്തിലേക്ക് വഴുതിപ്പോകുന്നത് തടയുന്നു.

റിപ്പോർട്ട് ചെയ്യുമ്പോൾ ഓരോ നിരീക്ഷണത്തിനും അതിന്റെ ഉറവിടം അനുസരിച്ച് ലേബൽ നൽകുക, കാരണം ലേബലില്ലാത്ത വാദം പുനഃപരിശോധിക്കാനാവില്ല. പ്രാദേശിക മാർക്കറും വിലാസ അനുമാനവും രണ്ടും ഉപയോഗപ്രദമാണ്, ഒന്നും നിർണ്ണായകമല്ല, അതിനാൽ അവയെ ഒരു വിധിയിൽ ലയിപ്പിക്കുന്നത് പിശകാണ്.

ഒരു സേവനം അനുവദിച്ച കണക്ഷൻ നിരസിക്കുമ്പോൾ, സിഗ്നൽ മറയ്ക്കാൻ പ്രാദേശിക ക്രമീകരണം മാറ്റുന്നതിന് പകരം അതിന്റെ പിന്തുണയുള്ള പുനഃപരിശോധനാ വഴി ഉപയോഗിക്കുക. ഒരു നിരീക്ഷണം നീക്കം ചെയ്യുന്നത് ബാക്കിയുള്ളവ അപ്രത്യക്ഷമായി എന്ന് ഒരിക്കലും തെളിയിക്കുന്നില്ല.