Android DNS ശരിയായി വായിക്കുക: നെറ്റ്വർക്ക് അനുസരിച്ച്, resolv.conf-ൽ അല്ല

നിങ്ങൾ ഉപകരണത്തിൽ shell എടുക്കുന്നു, /etc/resolv.conf വായിക്കുന്നു അല്ലെങ്കിൽ പഴയ net.dns1 മൂല്യം കുത്തിത്തോണ്ടുന്നു, ഒരു വിലാസം കിട്ടുന്നു. നിങ്ങളുടെ മുന്നിലുള്ള ആപ്പ് തികച്ചും മറ്റൊന്ന് വഴി പരിഹരിക്കുന്നു. നിലവിലെ Android പതിപ്പിൽ resolver നെറ്റ്വർക്ക് അനുസരിച്ചാണ്: സിസ്റ്റം ഓരോ Network-നും നയം സൂക്ഷിക്കുന്നു, അഭ്യർത്ഥന അയച്ച socket-ന് അത് പ്രയോഗിക്കുന്നു. ഫയലും പഴയ ഗുണവും ശേഷിപ്പുകളാണ്, അവയൊന്നും നിങ്ങളുടെ ചോദ്യം യഥാർത്ഥത്തിൽ സഞ്ചരിച്ച വഴി വിവരിക്കുന്നില്ല.

ഈ വിടവ് split-tunnel, Private DNS വിന്യാസങ്ങളിൽ കാണാം, ഇവിടെ ഒരേ ഫോണിലുള്ള രണ്ട് ആപ്പുകൾക്ക് നിയമാനുസൃതമായി വ്യത്യസ്ത ഉത്തരങ്ങൾ കാണാം. ഈ ഗൈഡ് തെറ്റായ അല്ലെങ്കിൽ ഇല്ലാത്ത പരിഹാരത്തിൽ നിന്ന് തുടങ്ങി അത് ഉടമസ്ഥതയിലുള്ള കോൺഫിഗറേഷനിലേക്ക് തിരികെ പോകുന്നു.

resolver ഒരു നെറ്റ്വർക്കിന്റേതാണ്, ഉപകരണത്തിന്റേതല്ല

Android 9-ഉം അതിനുശേഷവും പേരുകളുടെ പരിഹാരം socket ബന്ധിച്ച Network അടിസ്ഥാനമാക്കിയ സിസ്റ്റം resolver വഴി പോകുന്നു. ഓരോ നെറ്റ്വർക്കും അതിന്റേതായ LinkProperties വഹിക്കുന്നു, ആ ഗുണങ്ങൾ ആ നെറ്റ്വർക്കിന് മാത്രമായി DNS സെർവർ പട്ടിക, തിരയൽ ഡൊമെയ്നുകൾ, Private DNS അവസ്ഥ എന്നിവ സൂക്ഷിക്കുന്നു. ആ മാതൃകയിൽ ഫയലിൽ നിന്ന് വായിക്കാവുന്ന ഒരൊറ്റ ഉപകരണ-വ്യാപക പട്ടികയുമായി ഒത്തുപോകുന്നതൊന്നുമില്ല.

VPN ഈ വിഭജനം വ്യക്തമാക്കുന്നു. ടണൽ ഉയരുമ്പോൾ VPN ആപ്പ് VPN-ന്റെ സ്വന്തം നെറ്റ്വർക്കിൽ രജിസ്റ്റർ ചെയ്ത DNS സെർവറുകൾ നൽകുന്നു, അതുവഴി അതിലൂടെ റൂട്ട് ചെയ്യുന്ന ആപ്പുകൾ ആ സെർവറുകളിൽ പരിഹരിക്കുന്നു, ഒഴിവാക്കിയ ആപ്പുകൾ താഴെയുള്ള നെറ്റ്വർക്ക് ഉപയോഗിക്കുന്നു. ഒരു ഉപകരണം, രണ്ട് ഉത്തര വഴികൾ, വൈരുദ്ധ്യമില്ല.

സ്നാപ്പ്ഷോട്ട് ബാധിത ആപ്പിന്റെ ഉള്ളിൽ നിന്ന് വായിക്കുക

ആപ്പിനോട് തന്നെ ചോദിക്കുക. Context ഉം സാധാരണ android.permission.ACCESS_NETWORK_STATE അനുമതിയും ഉള്ള ഒരു മെത്തേഡിന് സിസ്റ്റം ഗുണങ്ങളിൽ തൊടാതെ സ്നാപ്പ്ഷോട്ട് വായിക്കാം:

val cm = getSystemService(ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val links = network?.let { cm.getLinkProperties(it) }

val dnsServers = links?.dnsServers
val privateDnsActive = links?.isPrivateDnsActive
val privateDnsName = links?.privateDnsServerName

activeNetwork നിങ്ങളുടെ പ്രോസസ്സിന്റെ ഡിഫോൾട്ട് നെറ്റ്വർക്കാണ്, ഉപകരണത്തിലെ ഏക നെറ്റ്വർക്കല്ല, വിളിക്കുന്നയാൾക്ക് ഉപയോഗയോഗ്യമായ ഡിഫോൾട്ട് ഇല്ലെങ്കിൽ null ആകാം. തടഞ്ഞ ഡിഫോൾട്ട് VPN സാധാരണ കാരണമാണ്. isPrivateDnsActive ആ നെറ്റ്വർക്കിലെ ചോദ്യങ്ങൾ TLS വഴി പേരിട്ട resolver-ലേക്ക് പോകുന്നുണ്ടോ എന്ന് പറയുന്നു, ഇത് ലളിതമായ UDP 53 പരിശോധന എന്ത് കാണിക്കും എന്നത് മാറ്റുന്നു. API ഉപരിതലം LinkProperties പ്രകാരം രേഖപ്പെടുത്തിയിരിക്കുന്നു, അതിലെ ഓരോ മൂല്യവും കോൺഫിഗറേഷന്റെ സ്നാപ്പ്ഷോട്ടാണ്, ഒരു പ്രത്യേക ചോദ്യം ഒരു പ്രത്യേക സെർവറിൽ എത്തി എന്നതിന്റെ തെളിവല്ല.

ഡിഫോൾട്ട് നെറ്റ്വർക്ക് ജോലി ചെയ്യുന്നതല്ലാത്തപ്പോൾ

സ്നാപ്പ്ഷോട്ട് ഡിഫോൾട്ടിന് മാത്രം ഉത്തരം നൽകുന്നു. ആപ്പിന് അതിന്റെ പ്രോസസ്സോ ഒരു socket-ഓ മറ്റൊരു നെറ്റ്വർക്കിലേക്ക് ബന്ധിക്കാം, അപ്പോൾ പരിഹാരം ആ തിരഞ്ഞെടുപ്പ് പിന്തുടരുന്നു, നിങ്ങളുടെ ഡയഗ്നോസ്റ്റിക്സ് ഇപ്പോഴും ഡിഫോൾട്ട് റിപ്പോർട്ട് ചെയ്യുന്നു. സ്വന്തം DNS-over-HTTPS resolver കൊണ്ടുവരുന്ന ബ്രൗസർ സിസ്റ്റം പട്ടികയോട് ഒട്ടും ചോദിക്കുന്നില്ല, അതിനാൽ അതിന്റെ ഉത്തരങ്ങൾ ബാക്കി ഉപകരണത്തെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. വർക്ക് പ്രൊഫൈൽ ആപ്പ് സ്വന്തം നയത്തോടെ വേറിട്ട ഉപയോക്താവിന് കീഴിൽ പ്രവർത്തിക്കുന്നു. സെർവറുകളെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് ബൈൻഡിംഗ് പരിശോധിക്കുക.

VPN സംയോജനമാണ് മറ്റേ പകുതി. dhcp-option DNS വരി OpenVPN പ്രൊഫൈലിൽ സ്വീകരിക്കുന്നതും ആ വിലാസം Android VPN നെറ്റ്വർക്കിൽ രജിസ്റ്റർ ചെയ്യുന്നതും രണ്ട് വെവ്വേറെ ഘട്ടങ്ങളാണ്, സെർവറിലേക്കുള്ള വഴി ഇല്ലാതിരിക്കുന്നത് തെറ്റായ വിലാസം പോലെ തന്നെ നിശബ്ദമായി പരാജയപ്പെടുന്നു. ഡെവലപ്പ്മെന്റ് മെഷീനിൽ നിന്ന് adb shell dumpsys connectivity build അനുവദിക്കുമ്പോൾ അതേ ലിങ്ക് ഗുണങ്ങൾ നെറ്റ്വർക്ക് അനുസരിച്ച് അച്ചടിക്കുന്നു, ഇത് കോഡ് എഴുതാതെ പട്ടിക സ്ഥിരീകരിക്കുന്നു.

കോൺഫിഗറേഷനെ നിങ്ങൾക്ക് അനുവാദമുള്ള ഒരു പരിഹാരവുമായി താരതമ്യം ചെയ്യുക

സ്വകാര്യ നാമമേഖലയിൽ പരിഹരിക്കേണ്ട ഒരു പേരും ഒരു പൊതു പേരും തിരഞ്ഞെടുക്കുക, രണ്ട് ഫലങ്ങളും സ്നാപ്പ്ഷോട്ടിന് അരികിൽ എഴുതുക: നെറ്റ്വർക്ക്, കോൺഫിഗർ ചെയ്ത സെർവറുകൾ, Private DNS അവസ്ഥ, പിശകിന്റെ കൃത്യമായ പാഠം. പേരിട്ട സെർവറിലേക്കുള്ള നേരിട്ടുള്ള ചോദ്യം ആ സെർവർ നിങ്ങൾക്ക് ഉത്തരം നൽകുന്നു എന്ന് തെളിയിക്കുന്നു; സാധാരണ ആപ്പ് പരിഹാരം അതിനെ തിരഞ്ഞെടുത്തു എന്ന് തെളിയിക്കുന്നില്ല. കാഷെയിലുള്ള ഉത്തരം പുതിയ പരിശോധനയല്ല, അതിനാൽ കാഷെ ശൂന്യമാക്കുക അല്ലെങ്കിൽ ഇന്ന് ആരും ചോദിക്കാത്ത പേര് ഉപയോഗിക്കുക.

resolver ഒരു പ്രത്യേക ആക്സസ് നെറ്റ്വർക്കിലെ ക്ലയന്റുകൾക്ക് മാത്രം സേവനം നൽകുന്നുവെങ്കിൽ, VPN പുറത്തുകടന്നതിന് ശേഷം അത് കാണുന്നത് ഫലം നിർണ്ണയിച്ചേക്കാം, ഇത് അത് നടത്തുന്നവർക്കുള്ള നയപരമായ ചോദ്യമാണ്, ഓപ്പറേറ്റർമാർ UDP 53 തടയുന്നു എന്നതിന്റെ തെളിവല്ല. Private DNS സജീവമുള്ളിടത്ത് അപൂർണ്ണ ഹോസ്റ്റ്നാമം രൂപകൽപ്പന പ്രകാരം നിരസിക്കപ്പെടാം, അതേ സെർവർ പൊതു നാമങ്ങൾക്ക് സാധാരണയായി ഉത്തരം നൽകുന്നു. ഗുണങ്ങൾ വായിക്കുന്നത് ഏത് രീതിയാണ് നിലവിലുള്ളതെന്ന് പറയുന്നു, അതിനാൽ പാക്കറ്റ് ഫിൽട്ടറുകൾ ഊഹിക്കുന്നത് നിർത്തുന്നു.

ഈ പൊരുത്തക്കേട് ഏത് പാളിയുടേതാണോ അത് ശരിയാക്കുക

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

പൊതു resolver-കൾ DHCP ഹുക്കിലേക്കോ സിസ്റ്റം ഗുണത്തിലേക്കോ തള്ളുന്നത് തുടർച്ചയായി സംഭവങ്ങൾ സൃഷ്ടിക്കുന്ന അറ്റകുറ്റപ്പണിയാണ്: സ്വകാര്യ നാമങ്ങൾ പരിഹരിക്കുന്നത് നിലയ്ക്കുന്നു, മാറ്റം VPN സെഷനെ അതിജീവിക്കുന്നു, ഉപകരണത്തിലെ അടുത്ത വ്യക്തിക്ക് ഉടമയില്ലാത്ത പഴയ വിലാസം കിട്ടുന്നു. മാറ്റം VPN-ലോ ആപ്പിലോ ഈ പൊരുത്തക്കേടിന്റെ ഉടമസ്ഥതയുള്ള മാനേജ്മെന്റ് പാളിയിലോ സൂക്ഷിക്കുക, പിന്നീട് സ്നാപ്പ്ഷോട്ട് വീണ്ടും വായിച്ച് സെർവർ പട്ടിക യഥാർത്ഥത്തിൽ മാറിയെന്ന് സ്ഥിരീകരിക്കുക.

അവസാനം നിങ്ങൾക്ക് ഒരു നെറ്റ്വർക്ക്, resolver പട്ടിക, Private DNS അവസ്ഥ എന്നിവയുമായി ബന്ധിച്ച ഒരു ആപ്പ് അഭ്യർത്ഥന വേണം. ഈ ശൃംഖല കാണിക്കാൻ കഴിയുമ്പോൾ, ഫയലിലുള്ള പരിചിത വിലാസം ഒന്നിന്റെയും തെളിവല്ല.