Android पर L2TP ऑटोमेशन: स्क्रिप्ट अनुरोध कर सकती है, बना नहीं सकती
shell रूट Android पर L2TP/IPsec नहीं उठाता। IPsec, L2TP, PPP और प्लेटफ़ॉर्म नीति में से हर एक का अपना हिस्सा है, इसलिए चुनें कि कौन इसे नियंत्रित कर सकता है।
मिथक यह है कि L2TP Android पर एक और चीज़ है जिसे shell स्क्रिप्ट शुरू कर सकती है: रूट जोड़ें, पुरानी सेवा को कॉल करें, हो गया। ऐसा नहीं हो सकता, क्योंकि टनल के पैकेट ले जाने से पहले चार अलग परतों को सहमत होना पड़ता है। IPsec परत पथ की रक्षा करती है, L2TP सत्र ले जाता है, PPP लिंक पर बातचीत करता है, और Android को परिणाम को VPN के रूप में पंजीकृत करना होता है जिसके चारों ओर वह रूट कर सके। मैंने इसे कॉपी किए गए कमांड के साथ दो बार होते देखा है, और दोनों बार रूट मौजूद था जबकि कुछ भी एन्क्रिप्ट नहीं था।
रूट बदलने से वास्तव में क्या होता है
रूट जोड़ना तय करता है कि पैकेट आगे कहाँ जाएगा। यह सुरक्षा संबंध पर बातचीत नहीं करता, L2TP सत्र नहीं खोलता, और वह PPP विनिमय नहीं चलाता जो पता, सहकर्मी और DNS सेटिंग्स पैदा करता है। फ़ोन पर दिखने वाला परिणाम वह ट्रैफ़िक है जो गलत रास्ते से निकलता है, या निकलकर मर जाता है, बिना कहीं कोई टनल स्थिति के।
यही बात पुराने रिलीज़ से कॉपी किए गए सेवा कॉल पर भी लागू होती है। Android की आंतरिक VPN प्लंबिंग प्रकाशित ऑटोमेशन API नहीं है, और किसी दूसरे संस्करण का क्रमांकित लेनदेन किसी अलग ऑपरेशन पर पहुँच सकता है या ऐसे विशेषाधिकार माँग सकता है जो स्क्रिप्ट के पास नहीं हैं। पासवर्ड ले जाने वाला ऑटोमेशन कभी भी अनुमानित आंतरिक तर्कों पर निर्भर नहीं होना चाहिए, क्योंकि विफलता या तो मौन no-op है या आधा बना प्रोफ़ाइल जिसे कोई साफ़ नहीं करता।
चार मालिक, और स्क्रिप्ट उनमें से कोई नहीं
इन्हें क्रम में लें। IPsec संरक्षित पथ स्थापित करता है और बनाए रखता है तथा सहकर्मियों को प्रमाणित करता है। L2TP उसके ऊपर सत्र ले जाता है, और यही स्तरिकरण कारण है कि मानक उन्हें एक प्रोटोकॉल के बजाय अलग तंत्र मानता है। उसके अंदर, PPP उन लिंक मापदंडों पर बातचीत करता है जिन्हें क्लाइंट उपयोग करेगा। फिर Android प्लेटफ़ॉर्म पक्ष रखता है: पंजीकृत VPN इंटरफ़ेस, प्रति-ऐप दायरा, always-on स्थिति और वह जीवनचक्र जो तय करता है कि ऐप मारे जाने पर क्या होता है।
स्क्रिप्ट उन परतों में से केवल अंतिम देख सकती है, और आमतौर पर परोक्ष रूप से। यह क्लाइंट से कनेक्ट करने को कह सकती है यदि वह क्लाइंट कोई प्रलेखित नियंत्रण उजागर करता है, और बाद में इंटरफ़ेस की स्थिति देख सकती है। यह नीचे की तीन परतों का विकल्प नहीं बन सकती, और प्लेटफ़ॉर्म को अप्रमाणित इंटरफ़ेस को VPN मानने के लिए नहीं कह सकती।
क्यों daemon भी छोटा रास्ता नहीं है
डिवाइस पर विशेषाधिकार प्राप्त Linux daemon शुरू करना गुम हिस्सा लगता है, और अक्सर यह वास्तव में टनल उठा भी देता है। जो यह नहीं करता वह है उस टनल को Android के साथ पंजीकृत करना। इंटरफ़ेस kernel के अंदर मौजूद है, लेकिन प्लेटफ़ॉर्म का VPN चयन, प्रति-ऐप रूटिंग, always-on नीति और जीवनचक्र इसके बारे में नहीं जानते, और daemon के अपने रूट और DNS बदलाव उन्हीं तालिकाओं के लिए नेटवर्क प्रबंधक से प्रतिस्पर्धा करते हैं।
परिणाम एक ऐसा कनेक्शन है जो daemon के ट्रैफ़िक के लिए काम करता है और रहस्यमय ढंग से उस ऐप के लिए नहीं जो आपके लिए मायने रखता था, या ऐसा जो तब तक बचा रहता है जब तक सिस्टम अपने नेटवर्क का पुनर्मूल्यांकन न करे। इनमें से कोई भी परिणाम प्लेटफ़ॉर्म बग नहीं है; यह socket रखने और VPN सुविधा रखने के बीच की सीमा है।
समर्थित रास्ते कैसे दिखते हैं
यदि संगठन ऐसे प्रोफ़ाइल पर जा सकता है जिसे Android स्वयं प्रदान करता है, तो प्लेटफ़ॉर्म का रास्ता ईमानदार है। API 30 से, VpnManager ऐप्स द्वारा प्लेटफ़ॉर्म VPN प्रोफ़ाइल के प्रावधान और नियंत्रण का समर्थन करता है, जिसमें कॉल करने वाले ऐप से जुड़ा प्राधिकरण प्रवाह है। यह L2TP कनवर्टर नहीं है: IKEv2 के लिए जो प्रोफ़ाइल मॉडल यह प्रदान करता है वह मौजूदा L2TP कॉन्फ़िगरेशन का अनुवाद नहीं करता, और प्रोटोकॉल बदलना एक माइग्रेशन है, नाम बदलना नहीं। पहचान, रास्ते, निजी DNS और पहुँच अनुमतियाँ जानबूझकर स्थानांतरित करनी होंगी।
यदि सेवा को L2TP/IPsec ही रहना है, तो समर्थित संयोजन वह क्लाइंट और OS रिलीज़ है जिसे ऑपरेटर वास्तव में प्रलेखित करता है, और उसका ऑटोमेशन अनुबंध यदि हो। जब कोई प्रलेखित बिना-निगरानी नियंत्रण न हो, तो सही उत्तर एक समर्थित मैन्युअल कनेक्शन है, न कि नाज़ुक विशेषाधिकार प्राप्त स्क्रिप्ट जो एक बिल्ड पर संयोग से काम करती है।
सही ऑटोमेशन क्या करता है
प्रलेखित नियंत्रण मिलने पर, ऑटोमेशन का काम छोटा और बचाव योग्य है: नामित कनेक्शन का अनुरोध करें, तैयारी की प्रतीक्षा करें, प्रमाणीकरण या सेटअप विफलता पर रुकें, इच्छित कार्यभार चलाएँ, और सफ़ाई उस घटक को छोड़ दें जो कनेक्शन रखता है। क्रेडेंशियल उस क्लाइंट के पास रहते हैं जो उन्हें संग्रहीत और बदलना जानता है।
पहली पंक्ति लिखने से पहले लिखें कि कौन सा घटक किस परत का मालिक है, और परिणाम को उसके विरुद्ध जाँचें:
- IPsec और PPP क्लाइंट संभालता है, स्क्रिप्ट के रास्ते नहीं।
- कनेक्शन प्लेटफ़ॉर्म की VPN स्थिति में दिखता है, इसलिए प्रति-ऐप दायरा और always-on उस पर लागू होते हैं।
- कोई आंतरिक सेवा कॉल, लेनदेन संख्या या अनुमानित तर्क क्रेडेंशियल नहीं ले जाता।
- किसी भी चरण में विफलता आधा-पंजीकृत प्रोफ़ाइल पीछे नहीं छोड़ती।