Android ॲप VPN वर चालण्यास नकार देते: कोणता स्तर ठरवतो

जेव्हा Android ॲप टनेल वर येण्याच्या क्षणी काम करणे थांबवते, तेव्हा तीन वेगवेगळ्या गोष्टी जबाबदार असू शकतात, आणि त्या सारख्याच दिसणाऱ्या अयशस्वीता निर्माण करतात. ॲप फोनची स्वतःची नेटवर्क स्थिती वाचून स्थानिक पातळीवर नकार देऊ शकते. सर्व्हर तुम्ही जिथून येता तो पत्ता वर्गीकृत करून तो नाकारू शकतो. किंवा नकाराचा VPN शी काहीही संबंध नसू शकतो. खालील क्रम काहीही बदलण्यापूर्वी पुरावे गोळा करतो, कारण आउटलेट बदलणे हे सर्वात महाग पाऊल आहे आणि तपासणी स्थानिक असेल तर सर्वात कमी मदत करणारे पाऊल आहे.

पायरी 1: ॲप कधी नकार देते ते शोधा

वेळ हा पहिला भेदक आहे. लॉग बफर रिकामा करा, अयशस्वीता पुन्हा निर्माण करा आणि ॲपने तक्रार करण्यापूर्वी काय केले ते पाहा:

adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60

जर ॲप कोणत्याही बाहेर जाणाऱ्या विनंतीचा प्रयत्न होण्यापूर्वीच नकार देते, तर तुम्ही स्थानिक निर्णय पाहत आहात. जर ते जोडले जाते, काहीतरी पाठवते आणि नंतर त्रुटी दाखवते, तर नकार दुसऱ्या बाजूने आला आहे. जर टनेल बंद असतानाही ॲप त्याच पद्धतीने अयशस्वी होते, तर VPN कधीही चल नव्हते.

त्या वेळेकडे पुरावा म्हणून पाहा, पुष्टी म्हणून नाही. ॲप कॅशे केलेला प्रतिसाद पुन्हा वाजवू शकते, आणि तुम्ही पाहण्यापूर्वी पार्श्वभूमी विनंत्या यशस्वी किंवा अयशस्वी झाल्या असू शकतात. शेवटच्या यशस्वी विनंतीच्या आणि त्रुटीच्या वेळमुद्रा नोंदवा, केवळ संदेश दिसलेला क्षण नाही.

पायरी 2: फोनचा स्वतःचा नेटवर्कविषयक दृष्टिकोन वाचा

Android VPN स्थिती नेटवर्क क्षमता म्हणून उघड करते, त्यामुळे टनेल सक्रिय आहे हे लक्षात घेण्यासाठी ॲपला व्यावसायिक पुरवठादारांची यादी लागत नाही. ते कनेक्टिव्हिटी सेवेला विचारते की सध्याचे नेटवर्क कोणते आहे, आणि उत्तरात VPN वाहतूक बिट असतो:

val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true

ती तपासणी स्थानिक आणि स्वस्त आहे, आणि ती कोणत्याही दूरस्थ वर्गीकरणाशिवाय “हे ॲप VPN वर चालत नाही” अशा संपूर्ण वर्गाच्या अहवालांचे स्पष्टीकरण देते. ॲप काय पाहू शकते हे अजूनही त्याच्या स्वतःच्या नेटवर्क संदर्भावर अवलंबून आहे, त्यामुळे प्रत्येक ॲप डिव्हाइसवरील प्रत्येक प्रोफाइल तपासते असे गृहीत धरू नका.

वर्कस्टेशनवरून तुम्ही चाचणी डिव्हाइसवर adb shell dumpsys connectivity वापरून आणि VPN नेटवर्क नोंद शोधून तीच स्थिती पाहू शकता. टनेल वर असलेली एक रन टनेल खाली असलेल्या रनशी तुलना करा, आणि दोन्ही आउटपुट ठेवा.

पायरी 3: सर्व्हर प्रत्यक्षात काय पाहतो ते वाचा

दुसरा निरीक्षक सेवा आहे. ती येणारा स्रोत पत्ता पाहते, आणि ती पत्ता, त्यामागील होस्टिंग नेटवर्क, प्रदेश, ऑपरेटर किंवा खाते व डिव्हाइसशी जोडलेल्या संकेतांवर कार्य करू शकते. यापैकी कोणतेही अद्वितीय ओळख नाही, आणि सामायिक पत्ता पद्धत बाजूचे अडवणूक सामान्य करते: एक निर्बंधित पत्ता त्याच भाषांतरामागील असंबंधित वापरकर्तेही बाहेर काढू शकतो.

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

जर ॲप सेल्युलरवर चालते आणि त्याच खात्यासह टनेलवर अयशस्वी होते, तर नकार दूरच्या टोकावर किंवा ॲपच्या स्वतःच्या धोरणात आहे. दोन्ही ठिकाणी अयशस्वी झाल्यास, VPN भेदक घटक नाही आणि तुम्ही एंडपॉइंटची चाचणी थांबवावी.

पायरी 4: पुरावे तीन निर्णयांपैकी एकाशी जुळवा

तीन संयोजने जवळजवळ प्रत्येक अहवाल व्यापतात. टनेल सक्रिय असताना कोणत्याही बाहेर जाणाऱ्या प्रयत्नाशिवाय नकार स्थानिक वाहतूक तपासणीकडे निर्देश करतो. बाहेर जाऊन त्रुटी, विशिष्ट होस्टवर वेळ संपणे किंवा प्रदेश-संदेशासह परत येणारी विनंती दूरच्या बाजूकडे निर्देश करते. टनेलशिवाय सेल्युलरवर पुनरावृत्ती होणारी अयशस्वीता खाते, ॲप आवृत्ती किंवा सेवेच्या स्वतःच्या धोरणाकडे निर्देश करते, आणि कोणताही VPN बदल तिला हलवणार नाही.

निर्णय त्याला निर्माण करणाऱ्या पुराव्यासह लिहा. या पायरीचे मूल्य म्हणजे ती तो चक्र थांबवते ज्यात कोणी हातातल्या फोनवर चालणारी तपासणी दुरुस्त करण्यासाठी चार वेळा आउटलेट नोड बदलतो.

ती दावे प्रामाणिकही ठेवते. स्वतः होस्ट करणे एंडपॉइंट आणि त्याचा इंटरनेट आउटलेट बदलते; ते Android ला VPN नेटवर्क सक्रिय आहे हे विसरायला लावत नाही, आणि पत्ते वर्गीकृत करणाऱ्या सेवेची स्वीकृतीची हमी देत नाही. स्थानिक फिल्टर तुमच्या स्वतःच्या VPN नेटवर्कवरही व्यावसायिकाप्रमाणेच सहजतेने सक्रिय होऊ शकतो.

पायरी 5: समर्थित मार्ग घ्या आणि तो पडताळा

उत्पादनाच्या दस्तऐवजी धोरणाने आणि त्याच्या समर्थन-मालकापासून सुरुवात करा. क्लायंट आवृत्ती, अचूक संदेश आणि अयशस्वीतेचा अरुंद वेळ-खिडकी पाठवा; केवळ त्रुटी आहे हे सिद्ध करण्यासाठी संपूर्ण रहदारी कॅप्चर किंवा ओळखपत्रे पाठवू नका.

जर सेवा थेट प्रवेशाला परवानगी देते आणि डिव्हाइस धोरणही परवानगी देते, तर प्रत्येक ॲपसाठी वगळणे हीच समर्थित पद्धत आहे, आणि ती टनेल लपवण्याऐवजी ते ॲप जाणीवपूर्वक टनेलमधून काढते. मग ॲपची रहदारी स्वतःच्या मार्गाने बाहेर पडते, जो कोणीतरी स्वीकारावा लागणारा धोरण-निर्णय आहे. VPN शिवाय अडवणारी संरचना असल्यास वगळलेले ॲप कनेक्टिव्हिटी गमावू शकते, त्यामुळे चालते असे वचन देण्यापूर्वी ते संयोजन तपासा.

कोणत्याही बदलानंतर पायरी-एकची वेळ चाचणी पुन्हा करा, ॲप चालते याची खात्री करा, आणि इतर प्रत्येक ॲप अजूनही टनेल वापरते याची खात्री करा. नंतर आधीची संरचना पुनर्संचयित करा आणि अयशस्वीता परत येते का ते तपासा, कारण तुम्ही पुन्हा निर्माण करू शकत नाही अशी दुरुस्ती हा असा योगायोग आहे जो तुम्हाला पुन्हा भेटेल.