Android ઇમ્યુલેટર અને હોસ્ટ VPN: DNS સ્નેપશોટ અને NAT સમજૂતી

જ્યારે ઇમ્યુલેટર એવા બિલ્ડ સર્વર સુધી પહોંચી શકતું નથી જે હોસ્ટનું બ્રાઉઝર સરળતાથી ખોલે છે, ત્યારે ઉપયોગી પ્રશ્ન એ નથી કે VPN કામ કરે છે કે નહીં. પ્રશ્ન એ છે કે ગેસ્ટને બેમાંથી કઈ પદ્ધતિ ખૂટે છે. વર્ચ્યુઅલ ઉપકરણ ઇમ્યુલેટરના NAT પાછળ પોતાનું નેટવર્ક સ્ટેક ચલાવે છે, અને તેની રિઝોલ્વર સૂચિ બૂટ વખતે લીધેલી નકલ છે, તેથી પછી ઉપર આવેલી ટનલ હોસ્ટનો માર્ગ બદલે છે પણ ગેસ્ટ જે પૂછે છે તે બદલતી નથી. આ બે સ્તરો સમજવાથી આ સમસ્યાના લગભગ દરેક સ્વરૂપની સમજૂતી મળે છે.

ગેસ્ટ સ્થિર NAT પાછળનું અલગ સ્ટેક છે

QEMU નું વપરાશકર્તા મોડ નેટવર્કિંગ ગેસ્ટને 10.0.2.15 પર, ગેટવેને 10.0.2.2 પર અને DNS સેવાને 10.0.2.3 થી 10.0.2.6 પર મૂકે છે. ગેસ્ટનો બહાર જતો ટ્રાફિક હોસ્ટનું કર્નલ ફોરવર્ડ કરતું નથી; તે હોસ્ટ બાજુની સોકેટમાં રૂપાંતરિત થાય છે, દરેક ગેસ્ટ કનેક્શન માટે એક, અને તે સોકેટ હોસ્ટના સરનામા અવકાશમાંથી બહાર નીકળે છે. તેથી ગેસ્ટ કનેક્શન બનતી વખતે હોસ્ટનો રાઉટિંગ નિર્ણય વારસામાં લે છે, અને તેથી ગેસ્ટ પાસે રાઉટ ટેબલમાં કોઈ એવી નોંધ નથી જે તમારી ટનલનું નામ લે.

એ જ પદ્ધતિ ગેસ્ટને ઉપયોગી બહાર નીકળવાનો માર્ગ આપે છે. 10.0.2.2 એ હોસ્ટના લૂપબેક ઇન્ટરફેસનું ઉપનામ છે, તેથી લેપટોપ પર 127.0.0.1 પર સાંભળતી સેવા ગેસ્ટમાંથી તે સરનામે પહોંચી શકાય છે. ક્લાયંટ ફક્ત લૂપબેક પર જે પ્રગટ કરે છે તે આ રીતે પહોંચી શકાય છે, અને આ નીચે વર્ણવેલી પ્રોક્સી ગોઠવણીનો આધાર છે.

ગેસ્ટ જે કરી શકતું નથી તે છે હોસ્ટના નેટવર્કને એમ જોવું કે જાણે તેના પર નામ અવકાશ હોય. કોઈ પુલ નથી, વિભાજિત રાઉટ ટેબલ નથી અને વારસામાં મળેલો રિઝોલ્વર નથી, ફક્ત તેના પેકેટ સ્વીકારતી NAT સેવા અને વર્ચ્યુઅલ ઉપકરણ શરૂ થયું ત્યારે લોન્ચરે લીધેલો સ્નેપશોટ છે.

DNS એ સ્નેપશોટ છે, જીવંત દૃશ્ય નથી

શરૂઆતમાં ઇમ્યુલેટર હોસ્ટની રિઝોલ્વર સૂચિ વાંચે છે અને ગેસ્ટને ચાર સુધી સર્વર આપે છે, જે 10.0.2.3 થી 10.0.2.6 સરનામાં પર પ્રગટ થાય છે. જો તે સમયે ટનલ બંધ હતી, તો સ્નેપશોટમાં લેપટોપે વાપરેલો કોઈપણ જાહેર રિઝોલ્વર હોય છે, અને ગેસ્ટ આખી જિંદગી તેને પૂછતું રહે છે. જાહેર નામો ઉકેલાય છે, આંતરિક નામો નિષ્ફળ જાય છે, અને દરેક લક્ષણ VPN તરફ ઇશારો કરે છે જ્યારે ખરેખર જૂનું મૂલ્ય ટનલ ઉપર આવ્યાના થોડા મિનિટ પહેલાં પકડેલી રિઝોલ્વર સૂચિ છે.

તેથી ક્રમ દ્વારા સુધારો દંતકથા નથી. પહેલાં ટનલ જોડો, પછી ઇમ્યુલેટર ફરીથી શરૂ કરો, અને સ્નેપશોટ પુનઃસ્થાપિત કરવાને બદલે કોલ્ડ બૂટ પસંદ કરો, કારણ કે ઝડપી બૂટ ઇમેજ પહેલાં સાચવેલી રિઝોલ્વર અને રાઉટ સ્થિતિ સાથે પાછી આવી શકે છે. ગેસ્ટ હમણાં શું વાપરે છે તે જોવું હોય તો હોસ્ટને નહીં, ઉપકરણને પૂછો:

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 દબાણ કરે, તો ટનલને તે પૂરું પાડવા દો અને સરનામું હાર્ડકોડ કરવાને બદલે ગેસ્ટને કોલ્ડ બૂટ કરો.

કનેક્શનના સમયે રાઉટિંગ હોસ્ટને અનુસરે છે

ગેસ્ટ કનેક્શન હોસ્ટ સોકેટ બને છે, તેથી રાઉટિંગ નિર્ણય સોકેટ બનાવતી વખતે લેવાય છે. વિનંતી પહેલાં ટનલ ઉપર હોવાથી વિનંતી પ્રોફાઇલના માર્ગો મુજબ ટનલમાંથી નીકળે છે. ફક્ત પસંદ કરેલા પ્રીફિક્સ લઈ જતી સ્પ્લિટ-ટનલ પ્રોફાઇલ તમારા ખાનગી સબનેટને બહાર રાખશે, તેથી હોસ્ટની પહોંચ ગેસ્ટ વિશેની ધારણા છે, પરિણામ નથી. હાલના ગેસ્ટ કનેક્શન જે માર્ગ સાથે બન્યા તે જાળવે છે, તેથી ફરી જોડાતો ક્લાયંટ ઇમ્યુલેટરની અંદર અટકેલું ડાઉનલોડ હંમેશા ઠીક કરતો નથી.

ચકાસણી હોસ્ટના ઇન્ટરફેસ પર છે, ગેસ્ટના આંકડામાં નહીં:

sudo tcpdump -ni tun0 'host 203.0.113.10'

જો ગેસ્ટની વિનંતી ટનલ ઇન્ટરફેસ પર દેખાય, તો રાઉટિંગ કામ કરે છે અને સમસ્યા તેની ઉપર છે. જો તે ભૌતિક ઇન્ટરફેસ પર દેખાય, તો પ્રોફાઇલ તે પ્રીફિક્સ આવરી લેતું નથી, અને ગેસ્ટ બાજુનું કોઈપણ પુનઃરૂપરેખાંકન તેને બદલશે નહીં.

જ્યારે ક્લાયંટ ફક્ત લૂપબેક પ્રોક્સી આપે છે

કેટલાક વ્યાપારી ક્લાયંટ કોઈ સિસ્ટમ ટનલ બનાવતા જ નથી. તેઓ 127.0.0.1 પર HTTP અથવા SOCKS શ્રોતા પ્રગટ કરે છે અને અપેક્ષા રાખે છે કે એપ્લિકેશન તેનો ઉપયોગ કરશે. ગેસ્ટ તે સોકેટ સીધું જોઈ શકતું નથી, પણ ઇમ્યુલેટરને તે વાપરવા કહી શકાય છે, કાં તો વિસ્તૃત નિયંત્રણો દ્વારા (સેટિંગ્સ, પછી પ્રોક્સી, મેન્યુઅલ મોડ, હોસ્ટ 127.0.0.1 અને ક્લાયંટ જે પોર્ટ છાપે છે) અથવા શરૂ કરતી વખતે:

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

ક્લાયંટ વિન્ડોથી પોર્ટની નકલ કરો; અનુમાનિત પોર્ટ શાંતિથી નિષ્ફળ જાય છે અને તૂટેલી ટનલ જેવો દેખાય છે. આ શું આવરે છે તે યાદ રાખો: HTTP પ્રોક્સી સેટિંગને પ્રોક્સી-જાગૃત એપ્લિકેશનો માને છે, અને કાચા સોકેટ તેને સંપૂર્ણ અવગણે છે. જો કામનો ભાર પોતાના કનેક્શન ખોલતું નેટિવ બાઇનરી હોય, તો પ્રોક્સી માર્ગ ટનલ સમાન નથી અને સરખામણી સ્પષ્ટ રીતે કરવી પડે.

પરિણામ ગેસ્ટની અંદરથી સાબિત કરો

એક જ સત્રમાં બે પરીક્ષણ દ્વારા રિઝોલ્યુશનને રાઉટિંગથી અલગ કરો. જે નામ નિષ્ફળ જાય જ્યારે સંખ્યાત્મક સરનામું જવાબ આપે, તે DNS સ્નેપશોટની સમસ્યા છે, અને સુધારો ક્રમ અથવા સ્પષ્ટ રિઝોલ્વર છે. બંને નિષ્ફળ જાય તો તે રાઉટિંગ અથવા નીતિ તરફ ઇશારો કરે છે, અને આગળની ચકાસણી એ છે કે એપ પોતાના નેટવર્ક પ્રતિબંધો ધરાવતી કાર્ય પ્રોફાઇલમાં ચાલે છે કે નહીં.

અંતે, તમે કયા ગેસ્ટ પર પરીક્ષણ કરો છો તે જાણો. ખૂબ જૂની ઇમ્યુલેટર ઇમેજ ગેસ્ટ બાજુના VPN ક્લાયંટને જરૂરી tun સપોર્ટ વિના મોકલવામાં આવી હતી, તેથી ત્યાં કોઈ પણ પ્રોફાઇલ કામ કરી શકતું ન હતું; હાલની ઇમેજમાં તે છે. હાલની ઇમેજ પર નિષ્ફળ જતો ક્લાયંટ ક્લાયંટ કે પ્રોફાઇલની સમસ્યા છે, અને હોસ્ટની ટનલ ફરી બનાવવાથી પરિણામ બદલાશે નહીં.