ഹോസ്റ്റിലെ ബ്രൗസർ കുഴപ്പമില്ലാതെ തുറക്കുന്ന ഒരു build സർവറിലേക്ക് എമുലേറ്ററിന് എത്താൻ കഴിയാതെ വരുമ്പോൾ, ഉപയോഗപ്രദമായ ചോദ്യം VPN പ്രവർത്തിക്കുന്നുണ്ടോ എന്നതല്ല. ഗസ്റ്റിന് രണ്ട് സംവിധാനങ്ങളിൽ ഏതാണ് ഇല്ലാത്തത് എന്നതാണ് ചോദ്യം. വിർച്വൽ ഉപകരണം എമുലേറ്ററിന്റെ NAT-ന് പിന്നിൽ സ്വന്തം നെറ്റ്‌വർക്ക് സ്റ്റാക്ക് പ്രവർത്തിപ്പിക്കുന്നു, കൂടാതെ അതിന്റെ റിസോൾവർ പട്ടിക ബൂട്ട് സമയത്ത് എടുത്ത ഒരു പകർപ്പാണ്, അതിനാൽ പിന്നീട് ഉയരുന്ന ടണൽ ഹോസ്റ്റിന്റെ പാത മാറ്റുന്നു, പക്ഷേ ഗസ്റ്റ് ചോദിക്കുന്ന കാര്യം മാറ്റുന്നില്ല. ഈ രണ്ട് പാളികൾ മനസ്സിലാക്കുന്നത് ഈ പ്രശ്നത്തിന്റെ ഏതാണ്ട് എല്ലാ ഭാവങ്ങളെയും വിശദീകരിക്കുന്നു.

സ്ഥിരമായ NAT-ന് പിന്നിലെ വേറിട്ട സ്റ്റാക്കാണ് ഗസ്റ്റ്

QEMU-വിന്റെ user-mode നെറ്റ്‌വർക്കിംഗ് ഗസ്റ്റിനെ 10.0.2.15-ലും ഗേറ്റ്‌വേയെ 10.0.2.2-ലും DNS സേവനത്തെ 10.0.2.3 മുതൽ 10.0.2.6 വരെയും നിർത്തുന്നു. ഗസ്റ്റിന്റെ പുറത്തേക്കുള്ള ട്രാഫിക് ഹോസ്റ്റ് കേർണൽ ഫോർവേഡ് ചെയ്യുന്നില്ല; അത് ഹോസ്റ്റ് വശത്തെ സോക്കറ്റുകളാക്കി മാറ്റുന്നു, ഓരോ ഗസ്റ്റ് കണക്ഷനും ഒന്ന്, ആ സോക്കറ്റുകൾ ഹോസ്റ്റിന്റെ വിലാസ മേഖലയിൽ നിന്ന് പുറത്തുപോകുന്നു. അതുകൊണ്ടാണ് ഗസ്റ്റ് കണക്ഷൻ സൃഷ്ടിക്കപ്പെടുന്ന നിമിഷത്തിൽ ഹോസ്റ്റിന്റെ റൂട്ടിംഗ് തീരുമാനം പിന്തുടരുന്നത്, അതുകൊണ്ടാണ് ഗസ്റ്റിന്റെ റൂട്ട് ടേബിളിൽ നിങ്ങളുടെ ടണലിനെ പേരെടുത്തു പറയുന്ന എൻട്രി ഇല്ലാത്തത്.

അതേ സംവിധാനം ഗസ്റ്റിന് ഉപയോഗപ്രദമായ ഒരു പുറത്തുകടക്കൽ നൽകുന്നു. 10.0.2.2 ഹോസ്റ്റിന്റെ loopback ഇന്റർഫേസിന്റെ അലിയാസ് ആണ്, അതിനാൽ ലാപ്‌ടോപ്പിലെ 127.0.0.1-ൽ കേൾക്കുന്ന സേവനം ആ വിലാസത്തിൽ ഗസ്റ്റിൽ നിന്ന് എത്താവുന്നതാണ്. ക്ലയന്റ് loopback-ൽ മാത്രം വെളിപ്പെടുത്തുന്ന എന്തും ഈ വഴിയിൽ എത്താവുന്നതാണ്, ഇതാണ് താഴെ വിവരിക്കുന്ന പ്രോക്‌സി ക്രമീകരണത്തിന്റെ അടിസ്ഥാനം.

ഗസ്റ്റിന് ചെയ്യാൻ കഴിയാത്തത് ഹോസ്റ്റിന്റെ നെറ്റ്‌വർക്ക് തന്റേതായ namespace ആണെന്ന പോലെ നിരീക്ഷിക്കുകയാണ്. bridge ഇല്ല, പങ്കിട്ട റൂട്ട് ടേബിൾ ഇല്ല, പാരമ്പര്യമായി കിട്ടിയ റിസോൾവർ ഇല്ല; അതിന്റെ പാക്കറ്റുകൾ സ്വീകരിക്കുന്ന NAT സേവനവും വിർച്വൽ ഉപകരണം തുടങ്ങിയപ്പോൾ ലോഞ്ചർ എടുത്ത സ്നാപ്പ്ഷോട്ടും മാത്രം.

DNS ഒരു സ്നാപ്പ്ഷോട്ടാണ്, ജീവനുള്ള കാഴ്ചയല്ല

തുടക്കത്തിൽ എമുലേറ്റർ ഹോസ്റ്റിന്റെ റിസോൾവർ പട്ടിക വായിച്ച് ഗസ്റ്റിന് നാല് വരെ സർവറുകൾ നൽകുന്നു, അവ 10.0.2.3 മുതൽ 10.0.2.6 വരെയുള്ള വിലാസങ്ങളിൽ വെളിപ്പെടുത്തുന്നു. അപ്പോൾ ടണൽ താഴെയായിരുന്നെങ്കിൽ, സ്നാപ്പ്ഷോട്ടിൽ ലാപ്‌ടോപ്പ് ഉപയോഗിച്ച ഏതെങ്കിലും പബ്ലിക് റിസോൾവർ ഉണ്ടാകും, ഗസ്റ്റ് തന്റെ ആയുസ്സ് മുഴുവൻ അതിനോട് ചോദിച്ചുകൊണ്ടിരിക്കും. പബ്ലിക് പേരുകൾ റിസോൾവ് ചെയ്യുന്നു, ആന്തരിക പേരുകൾ പരാജയപ്പെടുന്നു, എല്ലാ ലക്ഷണങ്ങളും VPN-ലേക്ക് വിരൽ ചൂണ്ടുന്നു, യഥാർത്ഥത്തിൽ കാലഹരണപ്പെട്ട മൂല്യം ടണൽ ഉയരുന്നതിന് കുറച്ച് മിനിറ്റ് മുൻപ് പകർത്തിയ റിസോൾവർ പട്ടികയാണ്.

അതിനാൽ ക്രമം തിരുത്തുന്നത് കെട്ടുകഥയല്ല. ആദ്യം ടണൽ ബന്ധിപ്പിക്കുക, പിന്നെ എമുലേറ്റർ പുനരാരംഭിക്കുക, സ്നാപ്പ്ഷോട്ട് പുനഃസ്ഥാപിക്കുന്നതിനേക്കാൾ കോൾഡ് ബൂട്ട് തിരഞ്ഞെടുക്കുക, കാരണം quick-boot ഇമേജ് മുൻപ് സേവ് ചെയ്ത റിസോൾവർ, റൂട്ട് അവസ്ഥയുമായി തിരികെ വരാം. ഗസ്റ്റ് ഇപ്പോൾ എന്താണ് ഉപയോഗിക്കുന്നതെന്ന് കാണണമെങ്കിൽ, ഹോസ്റ്റിനോടല്ല, ഉപകരണത്തോട് ചോദിക്കുക:

adb shell dumpsys connectivity | grep -i -A2 dns
adb shell ping -c 1 build.internal.example

എമുലേറ്റർ തുടക്കത്തിൽ വ്യക്തമായ ഒരു റിസോൾവറും സ്വീകരിക്കുന്നു, ഗസ്റ്റ് ഏത് സർവർ ഉപയോഗിക്കണമെന്ന് കൃത്യമായി അറിയുമ്പോൾ ഇത് ഉപയോഗപ്രദവും ആ സർവർ പബ്ലിക് ആണെങ്കിൽ അപകടകരവുമാണ്:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

പബ്ലിക് റിസോൾവറിന് ആന്തരിക സോണിന്റെ പകർപ്പില്ല, അതിനാൽ ഒന്ന് പിൻ ചെയ്യുന്നത് ക്രമപ്രശ്നത്തെ സ്ഥിരമായ പരാജയമാക്കി മാറ്റുന്നു. പ്രൊഫൈൽ സ്വകാര്യ DNS പുഷ് ചെയ്യുന്നെങ്കിൽ, ടണൽ അത് നൽകട്ടെ, വിലാസം hard-code ചെയ്യുന്നതിന് പകരം ഗസ്റ്റ് കോൾഡ് ബൂട്ട് ചെയ്യുക.

കണക്ഷൻ സമയത്ത് റൂട്ടിംഗ് ഹോസ്റ്റിനെ പിന്തുടരുന്നു

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

പരിശോധന ഹോസ്റ്റ് ഇന്റർഫേസിലാണ്, ഗസ്റ്റ് സ്ഥിതിവിവരക്കണക്കുകളിലല്ല:

sudo tcpdump -ni tun0 'host 203.0.113.10'

ഗസ്റ്റ് അഭ്യർത്ഥന ടണൽ ഇന്റർഫേസിൽ കണ്ടാൽ റൂട്ടിംഗ് പ്രവർത്തിക്കുന്നു, പ്രശ്നം അതിന് മുകളിലാണ്. അത് ഫിസിക്കൽ ഇന്റർഫേസിൽ കണ്ടാൽ പ്രൊഫൈൽ ആ പ്രിഫിക്സ് ഉൾക്കൊള്ളുന്നില്ല, ഗസ്റ്റ് വശത്തെ ഏത് പുനർക്രമീകരണവും അത് മാറ്റില്ല.

ക്ലയന്റ് loopback പ്രോക്‌സി മാത്രം വാഗ്ദാനം ചെയ്യുമ്പോൾ

ചില വാണിജ്യ ക്ലയന്റുകൾ സിസ്റ്റം ടണൽ ഒട്ടും സൃഷ്ടിക്കുന്നില്ല. അവ 127.0.0.1-ൽ HTTP അല്ലെങ്കിൽ SOCKS ലിസണർ വെളിപ്പെടുത്തി ആപ്പുകൾ അത് ഉപയോഗിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നു. ഗസ്റ്റിന് ആ സോക്കറ്റ് നേരിട്ട് കാണാൻ കഴിയില്ല, പക്ഷേ എമുലേറ്ററിനോട് അത് ഉപയോഗിക്കാൻ പറയാം, ഒന്നുകിൽ extended controls വഴി (Settings, പിന്നെ Proxy, manual mode, host 127.0.0.1 ഒപ്പം ക്ലയന്റ് പ്രിന്റ് ചെയ്യുന്ന പോർട്ട്) അല്ലെങ്കിൽ തുടക്കത്തിൽ:

emulator -avd Pixel_API_34 -http-proxy http://127.0.0.1:8080

ക്ലയന്റ് വിൻഡോയിൽ നിന്ന് പോർട്ട് പകർത്തുക; ഊഹിച്ച പോർട്ട് നിശബ്ദമായി പരാജയപ്പെട്ട് തകർന്ന ടണലിനെപ്പോലെ തോന്നിക്കും. ഇത് എന്തിനെ ഉൾക്കൊള്ളുന്നു എന്ന് ഓർക്കുക: HTTP പ്രോക്‌സി ക്രമീകരണം പ്രോക്‌സി അറിയുന്ന ആപ്പുകൾ മാനിക്കുന്നു, അസംസ്കൃത സോക്കറ്റുകൾ അത് പൂർണ്ണമായി അവഗണിക്കുന്നു. ജോലിഭാരം സ്വന്തം കണക്ഷനുകൾ തുറക്കുന്ന native binary ആണെങ്കിൽ, പ്രോക്‌സി പാത ടണലിന് തുല്യമല്ല, താരതമ്യം വ്യക്തമായി ചെയ്യണം.

ഫലം ഗസ്റ്റിന്റെ ഉള്ളിൽ നിന്ന് തെളിയിക്കുക

ഒരേ സെഷനിൽ രണ്ട് പരിശോധനകളിലൂടെ റിസോള്യൂഷനെ റൂട്ടിംഗിൽ നിന്ന് വേർതിരിക്കുക. സംഖ്യാ വിലാസം ഉത്തരം നൽകുമ്പോൾ പേര് പരാജയപ്പെടുന്നത് DNS സ്നാപ്പ്ഷോട്ട് പ്രശ്നമാണ്, പരിഹാരം ക്രമമോ വ്യക്തമായ റിസോൾവറോ ആണ്. രണ്ടും പരാജയപ്പെടുന്നത് റൂട്ടിംഗിനെയോ നയത്തെയോ സൂചിപ്പിക്കുന്നു, അടുത്ത പരിശോധന ആപ്പ് സ്വന്തം നെറ്റ്‌വർക്ക് നിയന്ത്രണങ്ങളുള്ള work profile-നുള്ളിൽ പ്രവർത്തിക്കുന്നുണ്ടോ എന്നതാണ്.

അവസാനമായി, ഏത് ഗസ്റ്റിലാണ് പരിശോധിക്കുന്നതെന്ന് അറിയുക. വളരെ പഴയ എമുലേറ്റർ ഇമേജുകൾ ഗസ്റ്റ് വശത്തെ VPN ക്ലയന്റിന് ആവശ്യമായ tun പിന്തുണയില്ലാതെയാണ് പുറത്തിറങ്ങിയത്, അതിനാൽ അവിടെ ഒരു പ്രൊഫൈലിനും പ്രവർത്തിക്കാൻ കഴിയുമായിരുന്നില്ല; നിലവിലെ ഇമേജുകളിൽ അത് ഉണ്ട്. നിലവിലെ ഇമേജിൽ പരാജയപ്പെടുന്ന ക്ലയന്റ് ക്ലയന്റിന്റെയോ പ്രൊഫൈലിന്റെയോ പ്രശ്നമാണ്, ഹോസ്റ്റ് ടണൽ പുനർനിർമ്മിക്കുന്നത് ഫലം മാറ്റില്ല.

അനുബന്ധ ലേഖനങ്ങൾ