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 सर्व्हरवर दुरुस्त करा, फोनवर नाही.
- रोलबॅक प्रत ठेवा, आणि रीबूटनंतर पुन्हा तपासा.