हॉटस्पॉट क्लायंटसाठी स्प्लिट टनलिंग हे प्रति-अ‍ॅप वगळणे नाही
अ‍ॅपला 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 नियम साचवण्याऐवजी निवडक धोरण समर्थित डाउनस्ट्रीम राउटरवर हलवा। राउटर स्थिर मालकासह स्रोत व गंतव्य जुळणी व्यक्त करू शकतो, आणि टिदरिंग मॉड्यूलचे दस्तऐवज फोन प्रत्यक्षात काय करतो याचा योग्य संदर्भ आहे।