Android VPN सर्वर: root फ़ोन को पहुँच-योग्य नहीं बनाता
तीन अलग समस्याएँ तय करती हैं कि कोई फ़ोन VPN क्लाइंट की सेवा कर सकता है या नहीं: आने वाला रास्ता, विशेषाधिकार मॉडल और फ़ॉरवर्डिंग। root केवल बीच वाले को छूता है।
root बदलता है कि किसी प्रक्रिया को कौन-से नेटवर्किंग ऑपरेशन आज़माने की अनुमति है। यह फ़ोन को सार्वजनिक रूप से पहुँच-योग्य पता नहीं देता, ऑपरेटर के पास आने वाली मैपिंग आरक्षित नहीं करता, और रीबूट के बाद डेमन को जीवित नहीं रखता। यदि आप तय कर रहे हैं कि कोई Android फ़ोन VPN सर्वर की तरह काम कर सकता है या नहीं, तो तीन प्रश्न अलग करें: क्या इच्छित क्लाइंट लिसनर तक पहुँच ही सकता है, सर्वर कार्यान्वयन को कौन-सा विशेषाधिकार मॉडल चाहिए, और सुरंग बनने के बाद क्या फ़ॉरवर्ड करना होगा।
किसे और कहाँ से फ़ोन तक पहुँचना है
उसी अनुमत LAN पर क्लाइंट और मोबाइल डेटा पर क्लाइंट दो अलग नेटवर्क जाँच रहे हैं। पहले इच्छित वाला तय करें, क्योंकि उत्तर एक-दूसरे पर लागू नहीं होते। Wi-Fi पर बिना माँगा आने वाला ट्रैफ़िक आमतौर पर अपस्ट्रीम राउटर पर मैपिंग और उसके आगे उपयोगी सार्वजनिक रास्ता माँगता है। सेल्युलर पर carrier-grade NAT का अर्थ है कि आने वाला IPv4 अक्सर उपलब्ध नहीं होता, फ़ोन जो भी अनुमति दे।
वही अंतिम बिंदु ऐसा है जिसे root छू नहीं सकता। फ़ोन का स्थानीय फ़ायरवॉल और ऑपरेटर का NAT अलग-अलग सिस्टम हैं, और पहले को बदलने का दूसरे पर कोई असर नहीं होता। निजी इंटरफ़ेस पता, मोबाइल-डेटा आइकन या सुनता हुआ सॉकेट पहुँच-योग्यता का प्रमाण नहीं हैं। यदि ऑपरेटर का रास्ता वैश्विक रूप से राउट-योग्य IPv6 देता है, तब भी उसके लिए जानबूझकर लिसनर और फ़ायरवॉल नीति चाहिए; पता होना कनेक्शन स्वीकार करने के बराबर नहीं है।
| Client path | What actually decides reachability |
|---|---|
| Same LAN | The phone's listener and its local firewall |
| Wi-Fi, from the internet | A mapping on the upstream router plus a usable public path beyond it |
| Cellular IPv4 | The carrier's NAT, which the handset does not control |
| Cellular IPv6 | Address, listener and firewall policy together |
सेवा देना और फ़ॉरवर्ड करना दो अलग सफलताएँ हैं
पूरा हुआ VPN हैंडशेक साबित करता है कि सुरंग मौजूद है। यह साबित नहीं करता कि क्लाइंट फ़ोन के पीछे के LAN तक पहुँच सकता है, और यह भी नहीं कि फ़ोन इंटरनेट एग्ज़िट की तरह काम कर सकता है। ये अलग कॉन्फ़िगरेशन हैं जो भीतरी पता योजना, रूट, वापसी व्यवहार और उस काम के लिए संकीर्ण फ़ॉरवर्डिंग नीति पर बनते हैं जो आप वास्तव में चाहते हैं।
विफलता का तरीका अनुमानित है: हैंडशेक सफल होता है, क्लाइंट जुड़ा दिखता है, और कुछ भी लोड नहीं होता। क्लाइंट को डीबग करने से पहले तय करें कि दो भूमिकाओं में से कौन-सी बना रहे हैं। फ़ोन के नेटवर्क पर किसी डिवाइस तक दूरस्थ पहुँच और पूर्ण-सुरंग इंटरनेट एग्ज़िट के लिए अलग फ़ॉरवर्डिंग नियम चाहिए, और एक चाहते समय दोनों देना आपकी माँगी गई क्षमता जोड़े बिना जोखिम बढ़ाता है।
विशेषाधिकार मॉडल एक विकल्प है, root या कुछ नहीं ऐसा नहीं
kernel TUN डिवाइस इस्तेमाल करने वाले पारंपरिक OpenVPN डेमन को संबंधित क्षमताएँ, डिवाइस नोड तक पहुँच और Android की सुरक्षा नीति का सहयोग चाहिए। root SELinux से व्यापक छूट नहीं है; विशेषाधिकार प्राप्त प्रक्रिया भी प्लेटफ़ॉर्म नीति से सीमित रहती है। इसीलिए Linux सर्वर पर आसानी से चलने वाली बाइनरी फ़ोन पर अनुमतियों के बारे में स्पष्ट त्रुटि के बिना विफल हो सकती है।
यूज़रस्पेस गेटवे कार्यान्वयन का विशेषाधिकार मॉडल पूरी तरह अलग हो सकता है, इसलिए यह आम दावा कि Android पर हर VPN सर्वर को root चाहिए, बहुत व्यापक है। root आपको अधिक ऑपरेशन आज़माने की क्षमता देता है, यह गारंटी नहीं कि उन्हें अनुमति मिलेगी या परिणाम पहुँच-योग्य होगा।
Android का अपना VPN-सेवा पंजीकरण फिर एक अलग तंत्र है। यह ऐप को परिभाषित जीवनचक्र वाला प्रबंधित क्लाइंट इंटरफ़ेस देता है; यह सामान्य सर्वर इंस्टॉलर नहीं है, और टर्मिनल से डेमन शुरू करने से उसे हमेशा-चालू प्रबंधन, प्रति-ऐप नीति या अपना रिकवरी मार्ग नहीं मिलता।
यदि आप एग्ज़िट पॉइंट चाहते हैं, तो आर्किटेक्चर बदलें
जब लक्ष्य मौजूदा OpenVPN प्रोफ़ाइल के साथ संगतता नहीं, बल्कि केवल फ़ोन के ज़रिए दूरस्थ इंटरनेट एग्ज़िट हो, तो समर्थित ओवरले एग्ज़िट नोड अधिक उपयुक्त डिज़ाइन है। Tailscale अपने पंजीकरण, प्राधिकरण और क्लाइंट-चयन चरणों के साथ Android एग्ज़िट-नोड भूमिका का दस्तावेज़ीकरण करता है।
यह अदला-बदली वास्तविक है और स्पष्ट कहने योग्य है: आप अलग प्रोटोकॉल, अलग भरोसा मॉडल और उस खाते तथा समन्वय सेवा पर निर्भरता स्वीकार करते हैं। यह बिना बदले OpenVPN क्लाइंट को ओवरले में शामिल नहीं करता, और आपको सार्वजनिक पते पर OpenVPN लिसनर नहीं देता।
परिनियोजन को अभी और क्या चाहिए
आप कोई भी रास्ता चुनें, परिचालन की बुनियादी बातें तय करती हैं कि यह एक सप्ताह टिकेगा या नहीं। सर्वर क्रेडेंशियल निजी रखें, अलग-अलग क्लाइंट पहचान जारी करें, और ज़रूरत से पहले निरस्तीकरण की योजना बनाएँ। तय करें कि अपडेट कैसे आते हैं, सेवा को पृष्ठभूमि में क्या चालू रखता है और रीबूट या नेटवर्क बदलाव के बाद यह कैसे उबरती है।
सुविधाजनक दिखने वाले शॉर्टकट से बचें: पुरानी स्थैतिक बाइनरी, हार्डकोड किए गए इंटरफ़ेस नाम, और ऐसी स्टार्टअप स्क्रिप्ट जो मौजूदा फ़ायरवॉल नीति मिटा देती है। फिर परिणाम को केवल एक ठोस परीक्षण पर स्वीकारें: अधिकृत दूरस्थ क्लाइंट इच्छित संसाधन तक पहुँचता है, प्रतिबंधित गंतव्य अनुपलब्ध रहते हैं, और समर्थित जीवनचक्र घटना के बाद डिवाइस स्वयं लौट आता है। root पहुँच उस परिणाम का एक संभावित घटक है, और शायद ही कभी निर्णायक।