हटस्पट क्लाइन्टका लागि स्प्लिट टनेलिङ प्रति-एप बहिष्कार होइन
कुनै एपलाई VPN बाट बाहिर राख्दा फोन मात्र बदलिन्छ। टेथर गरिएको ल्यापटपलाई आफ्नै फरवार्डिङ नियम चाहिन्छ, जो स्रोत, गन्तव्य र NAT मा मिलाइन्छ।
एउटै जस्तो सुनिने दुई आवश्यकता एउटै होइनन्: «यो एपलाई VPN बाट बाहिर राख» र «यो एउटा गन्तव्यलाई मेरो हटस्पटको ल्यापटपका लागि VPN बाहिर पठाऊ»। पहिलोले फोनको सकेटले कुन सञ्जाल रोज्ने भन्ने कुरा बदल्छ। दोस्रोले फोनले पहिले नै स्वीकार गरिसकेपछि अर्को यन्त्रबाट आएको प्याकेटको फरवार्डिङ निर्णय बदल्नुपर्छ। दुवैलाई मिसाउनु भनेको हटस्पट क्लाइन्टसँग सधैं फोनको आफ्नै ब्राउजरमा मात्र लागू हुने अपवाद बाँकी रहनु हो।
दुई प्रश्नका मालिक दुई फरक उपप्रणाली हुन्
Android एप सञ्जाल र टेथरिङलाई अलग राख्छ। एपका सकेटलाई जडान स्ट्याकले सञ्जालमा तोक्छ, र VPN एपले आफ्ना कुन सकेट सुरुङभित्र जाने भनेर निर्णय गर्छ। टेथर गरिएको क्लाइन्टबाट फरवार्ड गरिएका प्याकेट टेथरिङ उपप्रणालीले सम्हाल्छ, जसले netd सँग मार्ग, नीति नियम र डाउनस्ट्रिम इन्टरफेसमा अनुवाद माग्छ।
प्रति-एप बहिष्कार एपले सकेट खोल्दा मूल्याङ्कन गरिन्छ। फरवार्ड गरिएको प्याकेट त्यो जाँचसम्म कहिल्यै पुग्दैन, किनभने त्यो यस यन्त्रको एप सकेटबाट उत्पन्न भएको होइन। दुई सेटिङले एकअर्काको ठाउँ लिन नसक्नुको पूरै कारण यही हो, र यो दुवैमध्ये कुनैमा पनि बग होइन।
प्रति-एप बहिष्कारले वास्तवमा के बदल्छ
VpnService को निर्माताले addDisallowedApplication सँग सुरुङबाहिर रहने प्याकेजका नाम दिन सक्छ, वा addAllowedApplication सँग भित्र अनुमति दिइएका एकमात्र प्याकेजका नाम दिन सक्छ। ती एपले त्यसपछि अन्तर्निहित सञ्जालमा सकेट खोल्छन्, जबकि VPN बाँकी सबैका लागि पूर्वनिर्धारित मार्गको मालिक रहन्छ।
दायरा ठ्याक्कै छ: प्याकेजका आफ्नै सकेट, यस यन्त्रमा, सुरुङ चालु रहेसम्म। यसले फरवार्ड गरिएको ट्राफिकबारे केही भन्दैन, दोस्रो यन्त्रबारे केही होइन, र प्रणालीले टेथरिङको तर्फबाट पठाउने प्याकेटबारे पनि केही होइन।
यो गन्तव्य नियन्त्रण पनि होइन। ब्राउजर बहिष्कार गर्दा त्यो ब्राउजरले पुग्ने हरेक ठेगाना बहिष्कार हुन्छ, सुरुङभित्र राख्न चाहेको पनि सहित। जब आवश्यकताले एपको सट्टा गन्तव्य भन्छ, तब एप छनोटकर्ता बनावटैले नै गलत औजार हो।
फोनका लागि टेथर गरिएको प्याकेट कस्तो देखिन्छ
क्लाइन्टको प्याकेट हटस्पट इन्टरफेसमा फोनले दिएको निजी स्रोत ठेगानासहित, मानौं 192.168.43.20, र सार्वजनिक गन्तव्यसहित आउँछ। यसलाई फरवार्ड गर्न फोनलाई माथिल्लो लिङ्कतर्फ मार्ग र अनुवाद नियम चाहिन्छ, ताकि जवाफहरूले फर्कने बाटो भेटून्, किनभने क्लाइन्टको निजी ठेगाना सेलुलर सञ्जालमा अर्थहीन हुन्छ।
Android ले यसलाई राउटिङ तालिका छान्ने नीति नियमहरूद्वारा व्यक्त गर्छ, र सञ्जाल तथा VPN बदलिँदा netd ले सम्बन्धित तालिका र नियमहरू पुनः बनाउँछ। फोरम पोस्ट वा उही मोडेलको पुरानो रिलिजबाट प्रतिलिपि गरिएको तालिका नम्बर, नियम प्राथमिकता वा इन्टरफेस नामले दिगो स्वामित्व स्थापित गर्दैन। यही पुनर्निर्माणले हातले लेखिएको नियम एक घण्टा चलेर अर्को पुनःजडानपछि रोकिन सक्नुको कारण पनि हो।
हटस्पट अपवादलाई वास्तवमा कुन नीति चाहिन्छ
कुनै नियम छुनुअघि निर्णयलाई स्रोत, गन्तव्य र इच्छित मार्गका रूपमा लेख्नुहोस्। एक स्वीकृत गन्तव्यका लागि न्यूनतम रूप यस्तो देखिन्छ:
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
दुवै दिशा पूरा हुनुपर्छ। सीधा शाखालाई हालैको सेलुलर माथिल्लो लिङ्कबाट प्रयोगयोग्य मार्ग चाहिन्छ; VPN शाखालाई सुरुङ मार्ग र फरवार्ड गर्ने अनुमति चाहिन्छ। कुनै पनि स्रोत अनुवाद तपाईंले छानेको निकाससँग मिल्नुपर्छ, किनभने सुरुङ इन्टरफेसमा लागू गरिएको NAT ले सुरुङको ठेगाना देखाउँछ, सेलुलरको होइन, र तब फर्कने मार्ग जाने मार्गसँग मिल्दैन।
जवाफहरू ट्र्याक गरिएको अवस्था वा स्पष्ट मार्गबाट त्यही डाउनस्ट्रिम क्लाइन्टसम्म पुग्नुपर्छ, र बाहिर जाने प्याकेटको काउन्टरले यसमध्ये केही पनि प्रमाणित गर्दैन। VPN को आफ्नै बाह्य यातायात पनि अपवादको दायराबाहिर राख्नुहोस्, नत्र सुरुङका वाहक प्याकेटले क्लाइन्टको वेब अनुरोधका लागि लेखिएको नीति विरासतमा पाउँछन्।
समातिएको एउटा ठेगाना गन्तव्य होइन
ब्राउजरबाट पढिएको एउटै IPv4 ठेगाना एक क्षणको तस्बिर हो। ठूला सेवाहरू anycast वा घुम्ने किनार ठेगानाको समूहबाट जवाफ दिन्छन्, धेरै दोहोरो-स्ट्याक छन्, र लगइन प्रवाहले पृष्ठले कहिल्यै नदेखाउने प्रमाणीकरण र टेलिमेट्री होस्ट छुन सक्छ। तपाईंले संयोगवश देखेको ठेगानाको वरिपरि बनाइएको अपवाद अर्को पटक सेवाले भार सन्तुलन गर्दा तोडिन्छ।
सेवाको मालिकले अभिलेख गरेका ठेगाना, वा उसले प्रकाशित गर्ने दायरा प्रयोग गर्नुहोस्, र दुवै ठेगाना परिवारलाई गन्नुहोस्। यदि आवश्यकतालाई स्थिर समूहका रूपमा व्यक्त गर्न सकिँदैन भने, त्यो सम्भवतः सेवाका लागि नीतिको प्रश्न हो, फोनमा राउटिङको उपाय होइन।
डाउनस्ट्रिम पक्षबाट प्रमाणित गर्नुहोस्
तीन जाँच, यही क्रममा: ल्यापटपबाट छानिएको सेवा, VPN भित्र रहनुपर्ने सामान्य गन्तव्य, र अप्रभावित रहनुपर्ने फोन एप। त्यसपछि पुनःजडानपछि र माथिल्लो लिङ्क बदलिएपछि दोहोर्याउनुहोस्, किनभने तब नै नीति तालिकाहरू पुनः बनाइन्छन्।
यदि फोनको साझेदारी कार्यान्वयनले पुनःजडानभरि त्यो सम्झौता राख्न सक्दैन भने, ह्यान्डसेटमा root नियम थुपार्नुको सट्टा छनोट नीतिलाई समर्थित डाउनस्ट्रिम राउटरमा सार्नुहोस्। राउटरले स्थिर मालिकसँग स्रोत र गन्तव्य मिलान व्यक्त गर्न सक्छ, र टेथरिङ मोड्युलको कागजात फोनले वास्तवमा के गर्छ भन्ने कुराको सही सन्दर्भ हो।