Android एपले VPN बाहिर नामहरू समाधान गर्छ: बाइन्डिङ जाँचसूची

VPN क्लाइन्टकै ब्राउजरले पुग्ने भए पनि Android एपले आन्तरिक नाम समाधान गर्न सक्दैन, र त्यही बिल्ड अर्को फोनमा काम गर्छ। URL चर होइन। चर भनेको एपको प्रक्रियालाई समाधानका लागि कुन नेटवर्क प्रयोग गर्न अनुमति छ भन्ने हो, र तपाईंका सकेटहरूले प्रयोग गर्ने नेटवर्क नै सक्रिय VPN हो भन्ने Android ले ग्यारेन्टी गर्दैन। यी जाँचहरू क्रममा गर्नुहोस् र resolver स्न्यापसट तपाईंको अनुमानसँग नमिलेपछि रोक्नुहोस्।

चरण 1: एप कुन नेटवर्कमा छ भनी प्रमाणित गर्नुहोस्

स्ट्याटस बार होइन, एपको आफ्नै दृश्य पढ्नुहोस्। ConnectivityManager बाट सक्रिय नेटवर्क, त्यसको LinkProperties, DNS सर्भरको सूची र निजी DNS सेटिङ लिनुहोस्। सूचीमा VPN को resolver छ भने एपसँग त्यहाँ पुग्ने बाटो छ; यदि त्यसमा Wi-Fi को resolver छ भने त्यो प्रक्रियाका लागि टनेल पूर्वनिर्धारित नेटवर्क होइन।

VPN आइकनले टनेल अवस्थित छ भन्ने मात्र बताउँछ। यसले एपको प्रक्रिया त्यसमा बाइन्ड भएको थियो भन्ने बताउँदैन, र Android ले सधैं सक्रिय देखिने नेटवर्कबाट नाम समाधान मार्गनिर्देशन गर्दैन। अर्को यन्त्रमा फर्वार्ड गर्ने स्थानीय VPN एपहरू, इन्टरनेट नभएका Wi-Fi नेटवर्क र विक्रेताका बिल्डहरूले एपलाई टनेलका सर्भरको सट्टा पूर्वनिर्धारित resolver सोध्न छोड्न सक्छन्।

चरण 2: VPN ट्रान्सपोर्ट माग्नुहोस् र प्रक्रिया बाइन्ड गर्नुहोस्

एपले टनेलको resolver अनिवार्य रूपमा प्रयोग गर्नुपर्ने भए VPN ट्रान्सपोर्ट भएको नेटवर्क माग्नुहोस् र कलब्याकमा प्रक्रिया बाइन्ड गर्नुहोस्, ताकि कोडले नेटवर्क कहिले आउँछ अनुमान नगरोस्:

val request = NetworkRequest.Builder()
    .addTransportType(NetworkCapabilities.TRANSPORT_VPN)
    .build()

connectivityManager.requestNetwork(request, object : NetworkCallback() {
    override fun onAvailable(network: Network) {
        val bound = connectivityManager.bindProcessToNetwork(network)
        Log.i(TAG, "bound to VPN network: " + bound)
    }
})

यो कलले सम्पूर्ण प्रक्रियाको पूर्वनिर्धारित नेटवर्क बदल्छ, त्यसैले त्यसपछि सिर्जना गरिएको हरेक सकेटले त्यही प्रयोग गर्छ। पहिले नै रहेका सकेटहरू आफू सिर्जना भएको नेटवर्कमै रहन्छन्, त्यसैले बाइन्ड अघि खोलिएको जडान पूल पुरानै बाटोबाट समाधान गर्न सक्छ। फर्काइने मान boolean हो, र false नतिजाको अर्थ बाइन्ड भएन; छोटो ढिलाइसँग पुनः प्रयास गर्नुहोस् र दुवै प्रयास लग गर्नुहोस्।

चरण 3: बाइन्डलाई आवश्यकतामा मात्र सीमित गर्नुहोस्

सम्पूर्ण प्रक्रियाको बाइन्डिङ असभ्य छ। टेलिमेट्री, अपडेट जाँच र तेस्रो पक्षका SDK पनि टनेलमा जान्छन्, र टनेलमा इन्टरनेट छैन भने ती असफल हुन थाल्छन्। एउटै अनुरोधका लागि नेटवर्कको सकेट फ्याक्टरी प्रयोग गर्नुहोस् र बाँकी सबै यन्त्रको पूर्वनिर्धारितमा राख्नुहोस्। जानाजान एउटा मोडेल छान्नुहोस्: प्रत्येक जडानका लागि साँघुरो बाइन्ड, वा VPN हराउँदा स्पष्ट अनबाइन्डसहित प्रक्रिया बाइन्ड।

resolver का दुई सुविधाले कुनै त्रुटिबिना बाइन्डलाई पराजित गर्न सक्छन्। कडा मोडमा निजी DNS ले क्वेरीहरू नेटवर्क resolverको सट्टा नाम भएको DoT सर्भरमा पठाउँछ, र आफ्नै DNS-over-HTTPS क्लाइन्ट बोकेको एपले प्रणाली resolver पूर्ण रूपमा बाइपास गर्छ। बाइन्ड असफल भयो भन्ने निष्कर्ष निकाल्नु अघि दुवै जाँच्नुहोस्। VPN को DNS सर्भरसम्म कहिल्यै नपुग्ने क्वेरी टनेलतर्फको कुनै लगमा देखिँदैन।

चरण 4: CONNECTED अवरोधमा विश्वास नगर्नुहोस्

WorkManager मा NetworkType.CONNECTED भन्नाले नेटवर्क जोडिएको छ भन्ने हो, र तलको Wi-Fi वा सेलुलर लिंक गए पनि VPN ट्रान्सपोर्टले त्यो पूरा गर्छ। काम चल्छ, हरेक अनुरोध असफल हुन्छ, र पुनः प्रयास नीतिले त्यसलाई शेड्युलिङ बगजस्तो देखिने आँधीमा बदल्छ। टनेल एउटा नेटवर्क हो; त्यो अवरोध कहिल्यै इन्टरनेट जाँच थिएन।

कामलाई साँच्चै आवश्यक पर्ने क्षमता जाँच्नुहोस्, जस्तै प्रमाणित इन्टरनेट पहुँच, र ब्याकअफसहित सीमित पुनः प्रयास नीति राख्नुहोस्। कामलाई निजी नाम चाहिन्छ भने काम गर्नु अघि त्यो नाम छानिएको नेटवर्कमा समाधान गर्नुहोस्, र सफल हुनै नसक्ने अनुरोध दोहोर्याउनुको सट्टा स्पष्ट त्रुटिसँग छिटो असफल हुनुहोस्।

चरण 5: प्रमाण रेकर्ड गर्नुहोस् र दायरा पुनः परीक्षण गर्नुहोस्

छानिएको नेटवर्कका ट्रान्सपोर्ट प्रकार, LinkProperties बाट DNS सर्भरहरू, बाइन्डले true फर्कायो कि, र पहिलो अनुरोधको ठ्याक्कै असफलता लग गर्नुहोस्। त्यसपछि त्यही बाइन्डिङमुनि निजी नाम र सार्वजनिक नाम चलाउनुहोस्। त्यो जोडीले एपले टनेल resolver प्रयोग गर्यो कि चुपचाप यन्त्रको पूर्वनिर्धारितमा फर्कियो देखाउँछ, र त्यही प्रयोगकर्ताले अनुभव गर्ने भिन्नता हो।

तपाईंले समर्थन गर्ने सबैभन्दा पुरानो Android संस्करणमा र एउटा हालको रिलिजमा दोहोर्याउनुहोस्। पूर्वनिर्धारित बाटो सही देखिने बनाउने resolver व्यवहार नै यन्त्र र संस्करण फरक पर्ने ठाउँ हो, र नयाँ परीक्षण यन्त्रमा मात्र पास हुने बिल्ड तपाईंले पठाउने दायराका लागि प्रमाणित छैन। adb shell dumpsys connectivity असफलता पुनरुत्पादन गर्दा यन्त्रले कुन नेटवर्क र क्षमता रिपोर्ट गर्छ छिटो पुष्टि गर्ने तरिका हो।