हॉटस्पॉट क्लायंट के लिए स्प्लिट टनलिंग प्रति-ऐप बहिष्करण नहीं है
किसी ऐप को 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 नियम जमा करने के बजाय चयनात्मक नीति को किसी समर्थित डाउनस्ट्रीम राउटर पर ले जाएँ। राउटर स्थिर स्वामी के साथ स्रोत और गंतव्य मिलान व्यक्त कर सकता है, और टेथरिंग मॉड्यूल का दस्तावेज़ ही इस बात का सही संदर्भ है कि फ़ोन वास्तव में क्या करता है।