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 अपयश पुनरुत्पादित करताना उपकरण कोणती नेटवर्क आणि क्षमता नोंदवते हे पटकन तपासण्याचा मार्ग आहे.