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 स्न्यापसटको समस्या हो, र समाधान क्रम वा स्पष्ट रिजोल्भर हो। दुवै असफल भए त्यो राउटिङ वा नीति देखाउँछ, र अर्को जाँच एप आफ्नै नेटवर्क प्रतिबन्ध भएको work profile भित्र चल्छ कि भन्ने हो।

अन्तमा, तपाईं कुन गेस्टमा परीक्षण गर्दै हुनुहुन्छ थाहा पाउनुहोस्। धेरै पुराना इम्युलेटर इमेजहरू गेस्ट पक्षको VPN क्लाइन्टलाई चाहिने tun समर्थन बिना निस्कन्थे, त्यसैले त्यहाँ कुनै प्रोफाइल कहिल्यै चल्न सकेन; हालका इमेजहरूमा त्यो छ। हालको इमेजमा असफल हुने क्लाइन्ट क्लाइन्ट वा प्रोफाइलको समस्या हो, र होस्ट टनेल पुनः बनाउँदा नतिजा बदलिँदैन।