आपकी Android OpenVPN प्रोफ़ाइल रूट नहीं जोड़ पाती, क्योंकि फ़ोन के पास वर्चुअल इंटरफ़ेस पर कोई पता नहीं है, इसलिए रूट के इंगित करने के लिए कुछ नहीं है। रूट केवल यह बताते हैं कि पैकेट कहाँ जाने चाहिए। टनल पता यह बताता है कि टनल के भीतर फ़ोन कौन है, और इंटरफ़ेस बनने से पहले क्लाइंट को एक देना ही होगा। नीचे दी गई चार जाँचें क्रम से करें और पहली विफलता पर रुकें, क्योंकि पता बनने से पहले रूट संपादित करना असली समस्या छिपा देता है।

विफलता को उसी क्रम में पढ़ें जिसमें क्लाइंट उसे निष्पादित करता है

Android का VpnService.Builder दोनों धारणाओं को अलग रखता है: addAddress() उस इंटरफ़ेस पर पता रखता है जिसे ऐप बना रहा है, addRoute() गंतव्य उपसर्ग जोड़ता है, और establish() तब तक इंटरफ़ेस बनाने से इनकार करता है जब तक कम से कम एक पता न जोड़ा जाए। OpenVPN क्लाइंट प्रोफ़ाइल और सर्वर द्वारा भेजे गए विकल्पों को ठीक उन्हीं कॉल पर मैप करता है, इसलिए जो कनेक्शन कभी पता पार्स नहीं करता वह इंटरफ़ेस ही नहीं बना सकता।

इसीलिए आप जो लॉग पंक्ति पढ़ रहे हैं वह रूट का नाम ले सकती है जबकि कारण एक कदम पहले बैठा है। क्लाइंट रूट चरण तक तभी पहुँचता है जब इंटरफ़ेस मौजूद हो; पता न हो तो रूट कॉल तुरंत विफल हो जाता है या कभी चलता ही नहीं। जब लॉग कहे कि रूट नहीं जोड़ा जा सकता, तो रूट सिंटैक्स से नहीं, पते से शुरू करें।

जाँच 1: क्या सर्वर उत्तर में पता डालता है?

राउटेड OpenVPN सेवा में पता सर्वर पूल से या प्रति-क्लाइंट आवंटन से आता है, और टोपोलॉजी उसका आकार तय करती है। OpenVPN 2.4 या उससे नए सर्वर पर, सबनेट टोपोलॉजी वाली सेवा ऐसी दिखती है:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

उस आकार के साथ सर्वर ifconfig 10.8.0.6 255.255.255.0 जैसा कुछ भेजता है। पुराना topology net30 परिनियोजन इसके बजाय सहकर्मी पता भेजता है, उदाहरण के लिए ifconfig 10.8.0.6 10.8.0.5, इसलिए दोनों मॉडलों के बीच ले जाई गई प्रोफ़ाइल सही दिख सकती है जबकि वह गलत नेटमास्क ले जा रही हो।

क्लाइंट कनेक्शन लॉग में भेजे गए विकल्प सेट को खोजें। यदि उसमें ifconfig की एक भी पंक्ति नहीं है, तो सर्वर ने कभी पता नहीं भेजा या क्लाइंट ने विकल्प अस्वीकार कर दिया। जो सर्वर client-config-dir का उपयोग करता है, उस पर प्रमाणपत्र के common name के नाम वाली फ़ाइल मौजूद होनी चाहिए और आवंटन रखना चाहिए:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

जाँच 2: क्या क्लाइंट मिला हुआ पता रखता है?

बहुत चौड़ा फ़िल्टर दूसरा आम कारण है। pull-filter OpenVPN 2.4 और उससे नए में मौजूद है, और जब कई फ़िल्टर एक ही विकल्प से मेल खाते हैं तो अंतिम मेल खाने वाला जीतता है, इसलिए अंत में छोड़ा गया catch-all बिना त्रुटि के पता हटा देता है:

# removes every pushed option, including the address
pull-filter ignore "ifconfig"
pull-filter ignore "route"

फ़िल्टर को उसी विकल्प तक सीमित करें जिसे आप वास्तव में हटाना चाहते हैं और पते को अछूता छोड़ दें:

# keeps the pushed address, drops one unwanted LAN route
pull-filter ignore "route 10.60.0.0"

सभी pull बंद करने की सलाह आमतौर पर उसी से आती है जो एक ही रूट से छुटकारा पाना चाहता है। route-nopull अधिक संकीर्ण स्विच है: यह ifconfig और बाकी भेजे गए विकल्प रखता है जबकि भेजे गए रूट और DHCP जैसे विकल्प अस्वीकार करता है। जब सचमुच यही चाहिए तभी इसका उपयोग करें, और पते का प्रश्न अलग से हल करें।

जाँच 3: क्या पता आपके लिखने का है?

मैन्युअल एड्रेसिंग तभी जायज़ है जब ऑपरेटर आपको मान सौंपे। यदि आप स्वयं लिखते हैं तो वह VPN क्लाइंट सबनेट से आना चाहिए, सक्रिय सत्रों में अद्वितीय होना चाहिए और सर्वर जो टोपोलॉजी चलाता है उससे मेल खाना चाहिए। डेस्कटॉप ब्रिज या दूरस्थ LAN के किसी होस्ट का पता कॉपी करना दोनों ही कारणों से विफल होता है: फ़ोन ऐसे पते का दावा करेगा जो पहले से कहीं और है, और गेटवे के पास उसका लौटने का मार्ग नहीं होगा।

रूट में दूरस्थ LAN का उपसर्ग गंतव्य है, कभी फ़ोन की पहचान नहीं। 10.60.0.0/24 के लिए रूट कहता है कि उस नेटवर्क तक टनल से पहुँचें; यह नहीं बताता कि फ़ोन के पास कौन-सा 10.60.0.x पता होना चाहिए, और फ़ोन के पास उनमें से कोई नहीं होना चाहिए। स्थिर आवंटन सर्वर पक्ष के होते हैं, जहाँ वे गतिशील पूल से टकरा नहीं सकते।

एक ही पहचान पर दो सत्र वही टकराव उजागर करते हैं। यदि एक ही प्रमाणपत्र दो बार जुड़ता है और सर्वर दोनों को एक निश्चित पता भेजता है, तो दूसरा सत्र पहले की नकल बन जाता है, और समाधान क्लाइंट पक्ष का संपादन नहीं बल्कि अलग पहचान या अलग आवंटन हैं।

जाँच 4: क्या कोई और टनल स्लॉट रोक रहा है?

Android एक समय में केवल एक सक्रिय VPN सेवा की अनुमति देता है। कोई दूसरा VPN ऐप, या ऐसी प्रोफ़ाइल के लिए चालू छोड़ी गई always-on VPN प्रविष्टि जो अब काम नहीं करती, आपके OpenVPN क्लाइंट के establish() कॉल करने से पहले वह स्लॉट ले सकती है। तब प्रोफ़ाइल मान्य होने पर भी इंटरफ़ेस कभी दिखता नहीं, इसलिए दूसरा VPN डिस्कनेक्ट करें, always-on सेटिंग बंद करें और प्रोफ़ाइल को छूने से पहले फिर से जुड़ें।

ईथरनेट ब्रिजिंग पर ज़ोर देने वाली सेवा दूसरी बंद गली है। बिना root वाला Android ऐप IP टनल बना सकता है, ब्रिज किया हुआ ईथरनेट सेगमेंट नहीं, इसलिए आप जो भी पता लिखें वह dev tap सर्वर को काम नहीं कराएगा; ऑपरेटर को राउटेड सेवा देनी होगी। समस्या की रिपोर्ट करते समय क्लाइंट का नाम और संस्करण, भेजा गया विकल्प सेट, टोपोलॉजी और वह सटीक चरण शामिल करें जहाँ पता दिखना चाहिए था।

यदि चारों जाँचें पास हों और पता मौजूद, अद्वितीय और सही ढंग से मास्क किया हुआ हो, तो रूट का प्रश्न सामान्य हो जाता है: सर्वर किन उपसर्गों को अधिकृत करता है और क्लाइंट को उन्हें कैसे सीमित करना चाहिए। कुछ और बदलने से पहले टनल पता, उसका नेटमास्क और टोपोलॉजी लिख लें, क्योंकि यही तीन मान ऑपरेटर को सर्वर के दृश्य से तुलना करने के लिए चाहिए।

संबंधित लेख