OpenVPN Connect आणि Tasker: प्रोफाइल ID, नाव नाही

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

करार एका ॲपचा आणि एका आवृत्ती-श्रेणीचा आहे

OpenVPN Connect आणि OpenVPN for Android वेगवेगळे ॲप आहेत, आणि एका पॅकेजचे नाव घेणारा intent दुसऱ्यात काहीच करत नाही। कार्याला हात लावण्यापूर्वी कोणता क्लायंट इन्स्टॉल आहे आणि कोणत्या आवृत्तीने ते वर्तन निर्माण केले ज्याच्याशी तुम्ही तुलना करत आहात ते निश्चित करा। Android 3.3.2 किंवा त्यापुढील Connect साठीTasker चे नोंदवलेले एकत्रीकरण प्रोफाइल ID ची अपेक्षा करते। जुन्या सूचना ज्या दिसणाऱ्या नावापूर्वी AS किंवा PC लावतात त्या आधीच्या कराराचे वर्णन करतात, आणि त्या चालू कार्यात कॉपी करणे हेच काहीच का होत नाही याचे नेहमीचे कारण आहे।

ही आवृत्ती-मर्यादा बहुतेक अशा अहवालांचे स्पष्टीकरण देते की आधी हे चालत होते। ॲपने वैशिष्ट्य तोडले नाही; त्याने बदलले की वैशिष्ट्य काय स्वीकारते। आवृत्ती-श्रेणी हा तुम्ही ज्या कराराविरुद्ध लिहित आहात त्याचा भाग माना।

ओळख कोठून येते

Connect मध्ये इच्छित प्रोफाइल उघडा आणि त्याची प्रोफाइल ID प्रोफाइलच्याच तपशीलांतून कॉपी करा। यादीतून ओळखल्या जाणाऱ्या नावाऐवजी तेच मूल्य वापरा, कारण नाव फक्त लेबल आहे आणि ओळख म्हणजे ॲप ज्याच्याशी जुळवते ते। Tasker मधील Send Intent कृतीची कनेक्शन फील्ड खालील ब्लॉकसारखी दिसतात, फक्त ओळख बदलली जाते। वैयक्तिक किंवा कार्य प्रोफाइलची ॲप-प्रतही सुसंगत ठेवा।

Action: net.openvpn.openvpn.CONNECT
Extra: net.openvpn.openvpn.AUTOSTART_PROFILE_ID:'PROFILE_ID'
Extra: net.openvpn.openvpn.AUTOCONNECT:true
Package: net.openvpn.openvpn
Class: net.openvpn.unified.MainActivity
Target: Activity

कार्य प्रोफाइलमधील एक प्रत जिचे पॅकेज नाव तेच आणि साठवलेले प्रोफाइल वेगळे आहे ती intent स्वीकारेल आणि जुळणारे प्रोफाइल सापडणार नाही, जे तुटलेल्या कार्यासारखे दिसते, व्याप्तीच्या चुकीसारखे नाही। प्रोफाइल पुन्हा आयात किंवा बदलले गेल्यास ओळख संशयास्पद माना आणि ती पुन्हा तपासा। पुन्हा आयात केल्याने अनेकदा नवीन प्रोफाइल नोंद तयार होते, जरी दिसणारे नाव बदलत नसले तरी। दुसरे काही बदलण्यापूर्वी ओळख तपासा।

असंबंधित फील्ड नोंदीनुसार रिकामी ठेवा। श्रेणी, MIME प्रकार आणि मार्गदर्शक मागत नसलेली माहिती फील्ड Android चे intent सोडवण्याचे स्वरूप बदलू शकतात, आणि वेगळ्या पद्धतीने सोडवलेला intent ॲप तुमचे प्रोफाइल न सुरू करता उघडू शकतो।

कृती काय करते आणि तुमच्यासाठी काय ठेवते

कनेक्शन intent पाठवणे ॲपला प्रोफाइल सुरू करण्यास सांगते। ते त्या प्रोफाइलला आवश्यक असलेली परवानगी टाळत नाही। Connect अजूनही विचारणा दाखवू शकते, म्हणूनच नोंदवलेली स्वायत्त स्थिती असे गृहीत धरते की अतिरिक्त परवानगी आणि साठवलेली कनेक्शन क्रेडेन्शियल नाहीत। मोह हा आहे की ही मर्यादा काढून टाकावी आणि पासवर्ड किंवा खाजगी कीची गुपिते सामायिक Tasker निर्यातीत टाकावी।

असे करू नका। कार्य निर्यात ही मजकूर फाइल आहे जी लोक चॅट थ्रेडमध्ये कॉपी करतात, आणि तिथे ठेवलेली गुपिते ती सामायिक होते त्या क्षणी उघड होतात। प्रोफाइलला गरज असल्यास ॲपची स्वतःची साठवलेली कनेक्शन क्रेडेन्शियल वापरा, आणि MFA विचारणा विचारणाच राहू द्या। जे उत्तर साठवून विचारणा टाळते त्याने समस्या सोडवण्याऐवजी गुपित हलवले आहे।

डिस्कनेक्टच्या बाजूला स्वतःची नोंदवलेली कृती आहे, आणि ती क्लायंटवर केलेली युक्ती नाही:

Action: net.openvpn.openvpn.DISCONNECT
Extra: net.openvpn.openvpn.STOP:true
Package: net.openvpn.openvpn
Class: net.openvpn.unified.MainActivity
Target: Activity

डिस्कनेक्ट भाग पाडण्यासाठी जाणूनबुजून अस्तित्वात नसलेल्या प्रोफाइलशी जोडणे हा तोच मार्ग आहे जो जुन्या थ्रेडमध्ये दिसतो आणि नंतर अपडेटनंतर शांतपणे अयशस्वी होतो। स्पष्ट कृती वापरा।

पुढचे पाऊल चालण्यापूर्वी स्थिती तपासा

intent यशस्वीपणे सुरू होणे हे सिद्ध करते की विनंती पोहोचली, हे नाही की बोगदा अस्तित्वात आहे। जर कार्य नंतर अंतर्गत ॲप उघडत असेल,त्या पायरीला मर्यादित कालमर्यादेसह तयारी-अट लागते। पाठवल्यानंतर लगेचच केलेली कृती शेवटी एखाद्या विचारणेशी आदळेल।

$ adb shell cmd package resolve-activity --brief net.openvpn.openvpn
net.openvpn.openvpn/net.openvpn.unified.MainActivity
$ adb shell dumpsys activity activities | grep -i openvpn

resolve प्रश्न पुष्टी करतो की तुम्ही लक्ष्य करत असलेले पॅकेज आणि क्रियाकलाप त्या उपकरणावर आहेत, ज्यामुळे क्लास फील्डमधील टायपिंग चूक बाद होते। क्रियाकलाप डंप दाखवतो की तुमचे कार्य चालल्यानंतर प्रत्यक्षात पुढे काय आहे, आणि ॲपने जोडण्याऐवजी विचारणा उघडली का हे पाहण्याचा तो सर्वात स्वस्त मार्ग आहे। अयशस्वी कार्यानंतर दोन्ही चालवा, कोणते फील्ड चुकीचे आहे याचा अंदाज घेण्याऐवजी। क्लासच्या नावातील फरक लगेच त्रुटी देतो, तर गायब प्रोफाइल कोणतीही दिसणारी त्रुटी देत नाही।

कार्य पाठवण्यापूर्वी डिस्कनेक्टची मालकी ठरवा। जो शॉर्टकट असा बोगदा पाडतो ज्यावर दुसरे कार्य अवलंबून आहे, तो अशी मदत तिकीट निर्माण करेल जी त्याच्या कारणाशी अजिबात मिळत नाही। एकाच क्लायंटवर नियंत्रण ठेवणारी दोन ऑटोमेशन ठेवल्यास अशी शर्यत तयार होते जी तुम्ही लॉगमधून सोडवू शकत नाही, म्हणून नवीन चालू लागताच जुनी कृती हटवा।