Android OpenVPN: फ़ोन को रूट किए बिना निजी रूट जोड़ना
Android वाकई जो प्रोफ़ाइल लोड करता है उसमें एक रूट जोड़ें, फिर जाँचें कि सर्वर उसे अनुमति देता है। संपादन, दोबारा कनेक्ट और चार जाँचों के लिए गाइड।
आपको एक और निजी सबनेट चाहिए — मान लीजिए 10.60.0.0/24 — जो प्रोफ़ाइल में अभी नहीं है। लैपटॉप पर आप रूट जोड़कर आगे बढ़ जाते। Android में VPN एक ऐप है, tun डिवाइस उसी ऐप का है, और root के बिना संपादित करने के लिए कोई रूटिंग टेबल नहीं है। रूट फिर भी होना चाहिए, पर वह उस प्रोफ़ाइल में जाता है जो क्लाइंट लोड करता है, और वह तभी काम करता है जब दूसरा पक्ष सहमत हो। यहाँ संपादन, दोबारा कनेक्ट, सर्वर पक्ष और रोलबैक है।
संपादन से पहले: रूट क्या कर सकता है और क्या नहीं
रूट एक सवाल का जवाब देता है: इस गंतव्य का ट्रैफ़िक किस इंटरफ़ेस से जाएगा। यह किसी चीज़ की अनुमति नहीं देता। अगर नेटवर्क के मालिक ने सहमति नहीं दी है कि यह फ़ोन उस सबनेट तक पहुँच सकता है, तो सही रूट सही दिखने वाला कॉन्फ़िग और गेटवे पर चुपचाप ड्रॉप पैदा करता है, और अगला घंटा आप गलत फ़ाइल संपादित करने में बिताएँगे।
पहले वह सहमति लें, नेटवर्क का मालिक हो तो लिखित में। फिर नोट करें कि आप क्या नहीं कर रहे: आप फ़ोन को उस LAN के अंदर पता नहीं दे रहे, सर्वर का लिसनर नहीं बदल रहे, और होस्टनाम से साइट नहीं चुन रहे। ये चार अलग बदलाव हैं और सिर्फ़ पहला आपका है।
| The route gives you | The route does not give you |
|---|---|
| A destination prefix associated with the tunnel | Permission to forward at the gateway |
| A path for the phone's own traffic | A return route on the target host |
| A scope for the client's virtual interface | A name in DNS, or HTTPS identity |
वही प्रोफ़ाइल संपादित करें जो क्लाइंट वाकई लोड करता है
सामान्य OpenVPN विकल्प टेक्स्ट आयात करने वाले संगत क्लाइंट के लिए, जोड़ एक पंक्ति है:
route 10.60.0.0 255.255.255.0इसे प्रोफ़ाइल के मुख्य भाग में, दूसरे रूटिंग निर्देशों के पास जोड़ें, और ऑपरेटर का endpoint, प्रमाणपत्र, कुंजी प्रबंधन और सत्यापन पंक्तियाँ जैसी थीं वैसी ही रखें। एक पंक्ति उधार लेने के लिए पूरा पुराना उदाहरण चिपकाएँ नहीं: कम्प्रेशन, पूर्ण फ़ाइल पथ और पुरानी cipher सेटिंग्स साथ आती हैं और अलग डिबगिंग सत्र का ख़र्च कराएँगी।
जो कदम लोग चूक जाते हैं वह फ़ाइल का स्वामित्व है। अगर ऐप ने प्रोफ़ाइल आयात किया है, तो वह जो प्रति इस्तेमाल करता है वह ऐप की है, और डाउनलोड किए मूल को संपादित करने से कुछ नहीं बदलता। क्लाइंट के समर्थित एडिटर का उपयोग करें, या संपादित फ़ाइल को अपडेट पथ से दोबारा आयात करें, और समान नाम कई हों तो सक्रिय प्रोफ़ाइल का नाम पुष्ट करें। लिख लें कि आपने कौन-सी बदली।
अगर प्रोफ़ाइल में पहले से route-nopull है, तो सर्वर से कोई रूट इंस्टॉल नहीं होता और फ़ोन को ज़रूरी हर प्रीफ़िक्स स्पष्ट रूप से सूचीबद्ध करना पड़ता है। यह वैध डिज़ाइन है, पर इसका मतलब है कि छूटी हुई पंक्ति सर्वर के इनकार जैसी ही दिखती है।
दोबारा कनेक्ट करें और डिवाइस पर जाँचें
पहले डिस्कनेक्ट करें, फिर ऐप को पिछला सत्र बहाल करने देने के बजाय वही विशेष प्रोफ़ाइल दोबारा कनेक्ट करें जिसे आपने संपादित किया। कनेक्शन लॉग खोलें और पुष्ट करें कि क्लाइंट ने नई पंक्ति पार्स की; फ़्रंटएंड जिस रूट निर्देश को अनदेखा करता है वह गलत प्रति संपादित करने का आम नतीजा है।
गंतव्य को नाम से नहीं, पते से जाँचें। किसी ज्ञात सेवा पोर्ट पर TCP जाँच ping से ज़्यादा जानकारी देती है, क्योंकि बहुत से होस्ट ICMP का जवाब देते हैं जबकि सेवा पोर्ट फ़िल्टर होता है। अगर पता जवाब देता है और नाम नहीं, तो आपका सवाल रिज़ॉल्वर का है, रूटिंग का नहीं, और अगला भाग आपके लिए नहीं है।
यहाँ दो स्कोप जाँचें भी हैं। प्रति-ऐप VPN का मतलब है कि पता रूट मौजूद हो सकता है जबकि आप जिस ऐप से जाँच रहे हैं वह शामिल सेट से बाहर हो, इसलिए ऐसे ऐप से जाँचें जो सचमुच अंदर हो। और एक IPv4 प्रीफ़िक्स IPv6 पथ के बारे में कुछ नहीं कहता; अगर सेवा dual-stack है, तो संबंधित IPv6 रूट जोड़ें या उम्मीद करें कि क्लाइंट वह पथ चुनेगा जो आपने नहीं चाहा था।
एक नकारात्मक नतीजा जल्दी पहचानना ठीक है: अगर full-tunnel रूट पहले से 0.0.0.0/0 कवर करता है, तो प्रीफ़िक्स गायब नहीं है और उसे दोबारा जोड़ने से कुछ नहीं बदलता। दोहरा कवरेज सर्वर-साइड इनकार या गायब जवाब ठीक नहीं करता।
सर्वर पर पथ पूरा करें
फ़ोन से आगे तीन चीज़ें सही होनी चाहिए। गेटवे को गंतव्य तक रूट और फ़ोन के स्रोत को उस ओर अग्रेषित करने की अनुमति चाहिए। लक्ष्य को वह स्रोत स्वीकार करना और गेटवे से जवाब वापस भेजना चाहिए, वरना डिज़ाइन को egress पर सोच-समझकर अनुवाद चाहिए। OpenVPN मैनुअल का route विकल्प क्लाइंट-साइड निर्देश कवर करता है; अग्रेषण और रिटर्न रूटिंग अलग मशीनों पर अलग सेटिंग्स हैं।
अगर गंतव्य गेटवे के ठीक पीछे नहीं बल्कि किसी दूसरे VPN क्लाइंट के पीछे है, तो सर्वर को उस पीयर के सबनेट के लिए iroute चाहिए। वह निर्देश सर्वर का है और बताता है कि कौन-सा क्लाइंट किसी प्रीफ़िक्स का मालिक है; फ़ोन उसे अपनी प्रोफ़ाइल से नहीं दे सकता, और क्लाइंट-साइड संपादन कितना भी हो उसका विकल्प नहीं है।
रिटर्न पथ स्पष्ट रूप से जाँचें। टनल के बजाय डिफ़ॉल्ट रूट से निकलने वाला जवाब क्लासिक आधा-खुला लक्षण पैदा करता है: कनेक्शन एक दिशा में बनता है और कुछ वापस नहीं आता। जब लक्ष्य वापस रूट नहीं कर सकता तो गेटवे पर स्रोत अनुवाद वैध सुधार है, पर यह अपने परिणामों वाला नीति निर्णय है।
रोलबैक और स्वीकृति
संपादन से पहले पिछली प्रोफ़ाइल रखें। अगर बदलाव हालत बिगाड़े, तो उस प्रति को उसी पुनःआयात पथ से बहाल करें, दोबारा कनेक्ट करें, और पुष्ट करें कि पुराना व्यवहार लौटा — इससे पुष्ट होता है कि आपने वही बदला जो आपने सोचा था। जो रोलबैक पुरानी स्थिति नहीं लौटाता उसका मतलब है कि ऐप के पास तीसरी प्रति है जो आपको नहीं मिली।
बदलाव तब स्वीकारें जब चार बातें कायम हों, ताज़ा कनेक्शन के बाद इस क्रम में जाँची गई: गंतव्य अपने सेवा पोर्ट पर जवाब देता है, अपेक्षित हो तो निजी नाम रिज़ॉल्व होता है, HTTPS अब भी इच्छित होस्टनाम मान्य करता है, और रीबूट या Wi-Fi से सेलुलर पर जाने के बाद भी सब काम करता है। आखिरी जाँच वही है जो ऐसा रूट पकड़ती है जो सिर्फ़ तब तक है जब तक Android टनल फिर से स्थापित न करे।
- कुछ भी संपादित करने से पहले पुष्ट करें कि नेटवर्क का मालिक गंतव्य की अनुमति देता है।
- रूट उस प्रोफ़ाइल में रखें जो क्लाइंट लोड करता है, फिर दोबारा आयात करें और कनेक्ट करें।
- सही पता परिवार के लिए, प्रति-ऐप स्कोप के अंदर, सेवा पोर्ट से जाँचें।
- अग्रेषण, रिटर्न रूटिंग और iroute सर्वर पर ठीक करें, फ़ोन पर नहीं।
- रोलबैक प्रति रखें, और रीबूट के बाद दोबारा जाँचें।