Android VPN सर्व्हर: root फोनला पोहोचण्यायोग्य करत नाही
फोन VPN क्लायंटना सेवा देऊ शकतो का हे तीन वेगळ्या समस्या ठरवतात: आत येणारा मार्ग, विशेषाधिकार मॉडेल आणि फॉर्वर्डिंग. root फक्त मधल्याला स्पर्श करतो.
root प्रक्रियेला कोणती नेटवर्किंग क्रिया करून पाहण्याची परवानगी आहे हे बदलते. ते फोनला सार्वजनिकरीत्या पोहोचण्यायोग्य पत्ता देत नाही, ऑपरेटरकडे येणारे मॅपिंग राखून ठेवत नाही आणि रीबूटनंतर डेमन जिवंत ठेवत नाही. तुम्ही Android फोन VPN सर्व्हर म्हणून काम करू शकतो का हे ठरवत असाल, तर तीन प्रश्न वेगळे करा: इच्छित क्लायंट लिसनरपर्यंत पोहोचू शकतो का, सर्व्हर अंमलबजावणीला कोणते विशेषाधिकार मॉडेल लागते, आणि बोगदा उभा राहिल्यावर काय फॉर्वर्ड करायचे.
कोणी आणि कुठून फोनपर्यंत पोहोचायचे
त्याच परवानगी असलेल्या LAN मधला क्लायंट आणि मोबाइल डेटावरचा क्लायंट दोन वेगवेगळी नेटवर्क तपासत आहेत. आधी इच्छित ते ठरवा, कारण उत्तरे एकमेकांवर लागू होत नाहीत. Wi-Fi वर न मागितलेल्या आत येणाऱ्या रहदारीला सामान्यतः वरच्या राउटरवर मॅपिंग आणि त्यापुढे वापरण्यायोग्य सार्वजनिक मार्ग लागतो. सेल्युलरवर ऑपरेटर-स्तरीय 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 प्रवेश हा त्या निकालातील एक संभाव्य घटक आहे, आणि क्वचितच निर्णायक.