TAP या TUN? Android OpenVPN क्लाइंट और ब्रिज वाले सर्वर
TAP ईथरनेट फ़्रेम ले जाता है, TUN IP पैकेट ले जाता है, और Android ऐप को केवल दूसरा प्रकार मिलता है। दोनों की तुलना करें, फिर सर्वर पक्ष ठीक करें।
लैपटॉप पर चलने वाली प्रोफ़ाइल फ़ोन पर विफल हो जाती है। स्पष्ट कदम क्लाइंट कॉन्फ़िग में एक शब्द बदलना है। वह शब्द मदद नहीं करेगा, क्योंकि दोनों सिरे एक ही तरह की ट्रैफ़िक की बात नहीं कर रहे।
TAP ईथरनेट फ़्रेम ले जाता है। TUN IP पैकेट ले जाता है। Android VPN ऐप को एक IP इंटरफ़ेस दिया जाता है, जो कॉन्फ़िग कुछ भी कहे, दोनों में से एक व्यवस्था को संभव और दूसरी को असंभव बना देता है।
तुलना छोटी है, लेकिन यह तय करती है कि आप इसे फ़ोन पर ठीक कर सकते हैं या सेवा बदलनी होगी।
अलग-अलग पेलोड वाले दो टनल प्रकार
TAP इंटरफ़ेस ईथरनेट एडाप्टर की तरह व्यवहार करता है। यह फ़्रेम ले जाता है, यानी ARP, ब्रॉडकास्ट और वह सब कुछ जो LAN IP के नीचे ले जाता है। यही ब्रिजिंग को संभव बनाता है: टनल ब्रॉडकास्ट डोमेन बढ़ाता है और क्लाइंट ऐसे व्यवहार करते हैं जैसे वे स्विच में लगे हों।
TUN इंटरफ़ेस उसे संबोधित IP पैकेट ले जाता है। बातचीत के लिए कोई लिंक लेयर नहीं, कोई ARP नहीं और कोई ब्रॉडकास्ट नहीं। रूटिंग तय करती है कि टनल में क्या जाएगा, और सर्वर-साइड कॉन्फ़िग ब्रिज के बजाय सबनेट का उपयोग करता है।
दोनों सिरों को सहमत होना चाहिए कि वे इनमें से कौन-सा कर रहे हैं। एक तरफ़ dev tap को dev tun में बदलने से सेवा परिवर्तित नहीं होती; इससे ऐसा क्लाइंट बनता है जो रूटेड टनल की अपेक्षा करता है और सर्वर अब भी फ़्रेम भेजता है, और हैंडशेक सफल हो सकता है जबकि कोई उपयोगी चीज़ पार नहीं होती।
Android असल में ऐप को क्या देता है
प्लेटफ़ॉर्म का VpnService API किसी ऐप को IP पैकेट के लिए वर्चुअल इंटरफ़ेस देता है, जो पते, रूट और MTU के साथ कॉन्फ़िगर होता है। उस API में कोई ईथरनेट एडाप्टर नहीं है, और ऐप के पास एक बनाने का कोई रास्ता नहीं है।
इसलिए OpenVPN Connect Android पर TAP ब्रिजिंग के बजाय रूटेड TUN कनेक्शन का समर्थन प्रलेखित करता है। Android FAQ इस सीमा का क्लाइंट-पक्ष कथन है, और यह प्लेटफ़ॉर्म API से मेल खाता है।
रूट नेटवर्किंग टूल, कस्टम फ़र्मवेयर या स्पष्ट अनुवाद परत लागू करने वाला उत्पाद अलग व्यवस्थाएँ हैं। सामान्य स्थिति वही है जिसके आसपास योजना बनानी चाहिए: ऐसा ऐप जो आपकी फ़ाइल आयात कर सके और सामान्य उपयोगकर्ता के रूप में चल सके, एक IP इंटरफ़ेस के साथ और उसके नीचे कुछ भी नहीं।
फिर भी कोशिश करने पर कैसा दिखता है
कनेक्शन आमतौर पर स्थापित हो जाता है। यही विफलता को उलझन भरा बनाता है: क्लाइंट कनेक्टेड बताता है, सर्वर लॉग एक पीयर दिखाता है, और कोई एप्लिकेशन काम नहीं करता।
फ़ोन को सौंपे गए पते पर भेजी गई ट्रैफ़िक नहीं पहुँचती, क्योंकि सर्वर फ़्रेम को ऐसे MAC पते पर ब्रिज करता है जो फ़ोन के पास कभी नहीं था। ब्रॉडकास्ट पर निर्भर खोज खाली रहती है। यदि LAN ब्रिज के ज़रिए DHCP पर निर्भर है, तो फ़ोन को उस तरह लीज़ नहीं मिलेगी, और ब्रिज वाले सबनेट में हाथ से दिया पता भी गुम इंटरफ़ेस नहीं बनाता।
कुछ क्लाइंट पहले ही विफल हो जाते हैं, प्रोफ़ाइल आयात पर, जब उन्हें ऐसा डिवाइस प्रकार दिखता है जिसे वे लागू नहीं कर सकते। दोनों व्यवहार एक ही बात कहते हैं, और रूट जोड़कर, DNS बदलकर या टनल की पता-श्रेणी बढ़ाकर इनमें से कोई भी ठीक नहीं होता।
सर्वर पक्ष को क्या बदलना है
सुधार उसी का है जो VPN सेवा चलाता है, और यह आमतौर पर माइग्रेशन नहीं बल्कि अतिरिक्त होता है। रूटेड डिवाइस, अपने क्लाइंट सबनेट और पते सौंपकर फ़ोनों को ज़रूरी रूट भेजने वाले सर्वर-साइड कॉन्फ़िग के साथ दूसरा OpenVPN इंस्टेंस चलाएँ। मौजूदा ब्रिज वाला इंस्टेंस उन डिवाइसों की सेवा जारी रखता है जिन्हें सचमुच ईथरनेट चाहिए।
दो बातें इसे व्यवहार में काम कराती हैं। LAN को नए क्लाइंट सबनेट के लिए VPN होस्ट की ओर इशारा करने वाला रिटर्न रूट चाहिए, वरना जवाब कभी वापस नहीं आएँगे। और टनल होस्ट का फ़ायरवॉल टनल इंटरफ़ेस और LAN के बीच फ़ॉरवर्ड करना चाहिए, और यही वह कदम है जो सबसे ज़्यादा छूटता है जब होस्ट से ही किया गया परीक्षण सफल होता है।
यदि ऑपरेटर सेवा नहीं जोड़ सकता, तो विकल्प ऐसा डिवाइस है जो ब्रिज में शामिल हो सके, यानी फ़ोन की ओर से काम करने वाला लैपटॉप या राउटर। यह अपनी प्रबंधन लागत वाला अस्थायी उपाय है, Android कॉन्फ़िग नहीं।
टनल से नहीं, एप्लिकेशन से निर्णय लें
पूछें कि फ़ोन को असल में कहाँ पहुँचना है, फिर उसका मानचित्रण करें। नाम या पते से पहुँचने वाली फ़ाइल शेयरिंग या इंट्रानेट साइट IP आवश्यकता है, और DNS नाम हल कर देने तथा रूट मौजूद होने पर रूटेड टनल उसे पूरा करता है। स्थानीय ब्रॉडकास्ट डोमेन ब्राउज़ करने वाला खोज उपकरण IP आवश्यकता नहीं है, और कितनी भी रूटिंग उसे नहीं भरेगी।
| Requirement | Tunnel that satisfies it |
|---|---|
| File server or intranet by hostname | Routed TUN, with working DNS |
| Broadcast or ARP-based discovery | Ethernet bridging, so not an ordinary Android client |
| Multicast delivery | Bridging or an explicit multicast relay |
| One application to one address | Routed TUN, narrowest possible route |
वह तालिका भेजने का अनुरोध भी है। एप्लिकेशन, उसका इस्तेमाल किया जाने वाला पता या नाम, और यह कि क्या वह खोज पर निर्भर है, बताएँ। ऑपरेटर उस विवरण पर कार्य कर सकता है, जो कोई ऐसे फ़ोन पर नहीं कर सकता जो कनेक्ट ही न हो।
अंत में, जिन डिवाइसों को ज़रूरत है उनके लिए TAP सेवा रखें, बजाय हर क्लाइंट से LAN एडाप्टर की नकल कराने के। स्पष्ट उद्देश्य वाली दो सेवाओं का समर्थन करना उस एक से आसान है जो सभी के लिए आधी-अधूरी चलती है।