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 सर्भरमा सुधार्नुहोस्, फोनमा होइन।
- रोलब्याक प्रतिलिपि राख्नुहोस्, र रिबुटपछि फेरि जाँच्नुहोस्।