Android एम्युलेटर आणि होस्ट VPN: DNS स्नॅपशॉट आणि NAT

एम्युलेटर त्या बिल्ड सर्व्हरपर्यंत पोहोचू शकत नाही जो होस्टच्या ब्राउझरमध्ये व्यवस्थित उघडतो, तेव्हा उपयुक्त प्रश्न 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 असल्यासारखे निरीक्षण करणे. ब्रिज नाही, सामायिक राउट टेबल नाही आणि वारशाने मिळालेला रिझोल्व्हर नाही; फक्त त्याचे पॅकेट स्वीकारणारी 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'

गेस्टची विनंती टनेल इंटरफेसवर दिसली तर राउटिंग चालू आहे आणि समस्या त्याच्या वर आहे. ती भौतिक इंटरफेसवर दिसली तर प्रोफाइल त्या प्रीफिक्सला व्यापत नाही, आणि गेस्ट बाजूचे कोणतेही पुनर्संरचना ते बदलणार नाही.

जेव्हा क्लायंट फक्त loopback प्रॉक्सी देतो

काही व्यावसायिक क्लायंट सिस्टम टनेल अजिबात तयार करत नाहीत. ते 127.0.0.1 वर HTTP किंवा SOCKS लिसनर उघडतात आणि अनुप्रयोग तो वापरतील अशी अपेक्षा करतात. गेस्ट ते सॉकेट थेट पाहू शकत नाही, पण एम्युलेटरला ते वापरण्यास सांगता येते, एकतर विस्तारित नियंत्रणांद्वारे (Settings, नंतर Proxy, मॅन्युअल मोड, होस्ट 127.0.0.1 आणि क्लायंटने छापलेला पोर्ट) किंवा सुरुवातीला:

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

क्लायंट विंडोमधून पोर्ट कॉपी करा; अंदाज लावलेला पोर्ट शांतपणे अयशस्वी होतो आणि तुटलेल्या टनेलसारखा दिसतो. हे काय व्यापते ते लक्षात ठेवा: HTTP प्रॉक्सी सेटिंग प्रॉक्सी जाणणाऱ्या अनुप्रयोगांकडून आदरली जाते, आणि कच्चे सॉकेट ती पूर्णपणे दुर्लक्षित करतात. कामगिरी स्वतःची कनेक्शन उघडणारी native binary असेल तर प्रॉक्सी मार्ग टनेलशी समतुल्य नाही आणि तुलना स्पष्टपणे करावी लागते.

निकाल गेस्टच्या आतून सिद्ध करा

एकाच सत्रात दोन चाचण्यांनी रिझोल्युशन आणि राउटिंग वेगळे करा. संख्यात्मक पत्ता उत्तर देत असताना नाव अयशस्वी होते ते DNS स्नॅपशॉटचे समस्या आहे, आणि उपाय म्हणजे क्रम किंवा स्पष्ट रिझोल्व्हर. दोन्ही अयशस्वी झाल्यास ते राउटिंग किंवा धोरणाकडे निर्देश करते, आणि पुढील तपासणी म्हणजे अनुप्रयोग स्वतःच्या नेटवर्क निर्बंधांसह कार्य-प्रोफाइलमध्ये चालतो का.

शेवटी, कोणत्या गेस्टवर तुम्ही चाचणी करत आहात ते जाणून घ्या. अत्यंत जुन्या एम्युलेटर इमेजेस गेस्ट बाजूच्या VPN क्लायंटला आवश्यक असलेल्या tun समर्थनाशिवाय येत, त्यामुळे तिथे कोणताही प्रोफाइल कधीच चालू शकत नव्हता; सध्याच्या इमेजेसमध्ये ते आहे. सध्याच्या इमेजवर अयशस्वी होणारा क्लायंट हा क्लायंट किंवा प्रोफाइलचा प्रश्न आहे, आणि होस्ट टनेल पुन्हा बांधल्याने निकाल बदलणार नाही.