Android ആപ്പ് VPN-ന് പുറത്ത് പേരുകൾ നിർണ്ണയിക്കുന്നു: ബൈൻഡിംഗ് പരിശോധനാ പട്ടിക

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

ഘട്ടം 1: ആപ്പ് ഏത് നെറ്റ്വർക്കിലാണെന്ന് തെളിയിക്കുക

സ്റ്റാറ്റസ് ബാർ അല്ല, ആപ്പിന്റെ സ്വന്തം കാഴ്ച വായിക്കുക. ConnectivityManager-ൽ നിന്ന് സജീവ നെറ്റ്വർക്ക്, അതിന്റെ LinkProperties, DNS സെർവറുകളുടെ പട്ടിക, സ്വകാര്യ DNS ക്രമീകരണം എന്നിവ നേടുക. പട്ടികയിൽ VPN-ന്റെ resolver ഉണ്ടെങ്കിൽ ആപ്പിന് അതിലേക്ക് വഴിയുണ്ട്; അതിൽ Wi-Fi-യുടെ resolver ഉണ്ടെങ്കിൽ ആ പ്രോസസ്സിന് ടണൽ ഡിഫോൾട്ട് നെറ്റ്വർക്ക് അല്ല.

VPN ഐക്കൺ ഒരു ടണൽ നിലവിലുണ്ടെന്ന് മാത്രം പറയുന്നു. ആപ്പ് പ്രോസസ്സ് അതിൽ ബൈൻഡ് ചെയ്യപ്പെട്ടിരുന്നു എന്ന് പറയുന്നില്ല, സജീവമായി തോന്നുന്ന നെറ്റ്വർക്കിലൂടെ മാത്രം Android നാമനിർണ്ണയം റൂട്ട് ചെയ്യുന്നുമില്ല. മറ്റൊരു ഉപകരണത്തിലേക്ക് ഫോർവേഡ് ചെയ്യുന്ന ലോക്കൽ VPN ആപ്പുകൾ, ഇന്റർനെറ്റ് ഇല്ലാത്ത Wi-Fi നെറ്റ്വർക്കുകൾ, നിർമ്മാതാക്കളുടെ ബിൽഡുകൾ എന്നിവ ടണലിന്റെ സെർവറുകൾക്ക് പകരം ഡിഫോൾട്ട് resolver-നോട് ചോദിക്കാൻ ആപ്പിനെ വിട്ടേക്കാം.

ഘട്ടം 2: VPN ട്രാൻസ്പോർട്ട് ആവശ്യപ്പെട്ട് പ്രോസസ്സ് ബൈൻഡ് ചെയ്യുക

ആപ്പ് ടണലിന്റെ resolver നിർബന്ധമായും ഉപയോഗിക്കേണ്ടിവരുമ്പോൾ, VPN ട്രാൻസ്പോർട്ടുള്ള നെറ്റ്വർക്ക് ആവശ്യപ്പെട്ട് കോൾബാക്കിൽ പ്രോസസ്സ് ബൈൻഡ് ചെയ്യുക, നെറ്റ്വർക്ക് എപ്പോൾ വരുമെന്ന് കോഡ് ഊഹിക്കാതിരിക്കാൻ:

val request = NetworkRequest.Builder()
    .addTransportType(NetworkCapabilities.TRANSPORT_VPN)
    .build()

connectivityManager.requestNetwork(request, object : NetworkCallback() {
    override fun onAvailable(network: Network) {
        val bound = connectivityManager.bindProcessToNetwork(network)
        Log.i(TAG, "bound to VPN network: " + bound)
    }
})

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

ഘട്ടം 3: ബൈൻഡ് ആവശ്യമുള്ളതിൽ മാത്രം പരിമിതപ്പെടുത്തുക

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

resolver-ന്റെ രണ്ട് സവിശേഷതകൾക്ക് ഒരു പിശകുമില്ലാതെ ബൈൻഡിനെ തോൽപ്പിക്കാം. കർശന മോഡിലെ സ്വകാര്യ DNS ക്വറികൾ നെറ്റ്വർക്ക് resolver-ന് പകരം പേരുള്ള DoT സെർവറിലേക്ക് അയയ്ക്കുന്നു, സ്വന്തം DNS-over-HTTPS ക്ലയന്റ് ഉള്ള ആപ്പ് സിസ്റ്റം resolver-നെ പൂർണ്ണമായി ഒഴിവാക്കുന്നു. ബൈൻഡ് പരാജയപ്പെട്ടു എന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ് രണ്ടും പരിശോധിക്കുക. VPN-ന്റെ DNS സെർവറിൽ എത്താത്ത ഒരു ക്വറിയും ടണൽ വശത്തെ ഒരു ലോഗിലും പ്രത്യക്ഷപ്പെടില്ല.

ഘട്ടം 4: CONNECTED നിയന്ത്രണത്തെ വിശ്വസിക്കരുത്

WorkManager-ലെ NetworkType.CONNECTED എന്നാൽ ഒരു നെറ്റ്വർക്ക് കണക്ട് ചെയ്തിരിക്കുന്നു എന്നാണ്, താഴെയുള്ള Wi-Fi അല്ലെങ്കിൽ സെല്ലുലാർ ലിങ്ക് പോയാലും VPN ട്രാൻസ്പോർട്ട് അത് തൃപ്തിപ്പെടുത്തുന്നു. ജോലി പ്രവർത്തിക്കുന്നു, എല്ലാ അഭ്യർത്ഥനകളും പരാജയപ്പെടുന്നു, വീണ്ടും ശ്രമിക്കാനുള്ള നയം അതിനെ ഷെഡ്യൂളിംഗ് ബഗ് പോലെ തോന്നിക്കുന്ന ഒരു കൊടുങ്കാറ്റാക്കി മാറ്റുന്നു. ടണൽ ഒരു നെറ്റ്വർക്കാണ്; ആ നിയന്ത്രണം ഒരിക്കലും ഇന്റർനെറ്റ് പരിശോധനയായിരുന്നില്ല.

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

ഘട്ടം 5: തെളിവുകൾ രേഖപ്പെടുത്തി ശ്രേണി വീണ്ടും പരിശോധിക്കുക

തിരഞ്ഞെടുത്ത നെറ്റ്വർക്കിന്റെ ട്രാൻസ്പോർട്ട് തരങ്ങൾ, LinkProperties-ൽ നിന്നുള്ള DNS സെർവറുകൾ, ബൈൻഡ് true മടക്കിനൽകിയോ, ആദ്യ അഭ്യർത്ഥനയുടെ കൃത്യമായ പരാജയം എന്നിവ ലോഗ് ചെയ്യുക. തുടർന്ന് അതേ ബൈൻഡിന് കീഴിൽ സ്വകാര്യ നാമവും പൊതു നാമവും പ്രവർത്തിപ്പിക്കുക. ആ ജോടി ആപ്പ് ടണൽ resolver ഉപയോഗിച്ചോ അതോ നിശ്ശബ്ദമായി ഉപകരണത്തിന്റെ ഡിഫോൾട്ടിലേക്ക് പിൻവാങ്ങിയോ എന്ന് കാണിക്കുന്നു, അതാണ് ഉപയോക്താവ് അനുഭവിക്കുന്ന വ്യത്യാസം.

നിങ്ങൾ പിന്തുണയ്ക്കുന്ന ഏറ്റവും പഴയ Android പതിപ്പിലും ഒരു നിലവിലെ റിലീസിലും ഇത് ആവർത്തിക്കുക. ഡിഫോൾട്ട് വഴി ശരിയായി തോന്നിക്കുന്ന resolver സ്വഭാവം ഉപകരണങ്ങളും പതിപ്പുകളും വ്യത്യാസപ്പെടുന്ന കൃത്യമായ സ്ഥലമാണ്, ഏറ്റവും പുതിയ പരീക്ഷണ ഉപകരണത്തിൽ മാത്രം വിജയിക്കുന്ന ബിൽഡ് നിങ്ങൾ അയയ്ക്കുന്ന ശ്രേണിക്ക് പരിശോധിച്ചിട്ടില്ല. adb shell dumpsys connectivity പരാജയം പുനരുൽപ്പാദിപ്പിക്കുമ്പോൾ ഉപകരണം ഏത് നെറ്റ്വർക്കുകളും കഴിവുകളും റിപ്പോർട്ട് ചെയ്യുന്നു എന്ന് വേഗത്തിൽ സ്ഥിരീകരിക്കാനുള്ള വഴിയാണ്.