स्प्लिट टनलिंग आपके ऐप के अपडेट को क्यों कवर नहीं करती

आप एप्लिकेशन को स्प्लिट-टनल बहिष्करण सूची में जोड़ते हैं, ऐप सीधे इंटरनेट तक पहुँचता है, और अपडेट फिर भी विफल होते हैं या फिर भी सुरंग से रेंगते रहते हैं। बहिष्करण ने काम किया। उसने केवल डाउनलोड करने वाली प्रक्रिया से अलग एक प्रक्रिया को कवर किया, क्योंकि आधुनिक अपडेटर शायद ही कभी ऐप विंडो जैसी वही निष्पादन योग्य फ़ाइल होता है।

भ्रम: ऐप को बाहर रखना उसकी ट्रैफ़िक को बाहर रखता है

प्रति-ऐप स्प्लिट टनलिंग प्लेटफ़ॉर्म के आधार पर किसी प्रक्रिया, पैकेज या एप्लिकेशन पथ से मेल खाती है। वह किसी ब्रांड, सुविधा या उपयोगकर्ता के इरादे से मेल नहीं खाती। जब ऐप डाउनलोड को किसी हेल्पर, साझा प्लेटफ़ॉर्म सेवा या ब्राउज़र घटक को सौंपता है, तो उस हेल्पर की अपनी पहचान और सुरंग से होकर अपना रास्ता होता है। बहिष्करण सूची को पता ही नहीं है कि दोनों प्रक्रियाएँ एक ही उत्पाद की हैं। उसे केवल इतना पता है कि आपने किसका नाम लिया।

इसलिए नियम ठीक वही कर रहा है जो उसे बताया गया था। ट्रांसफ़र का मालिक कौन है, यह मान्यता गलत थी, और सुधार अधिक बहिष्करण जोड़ने के बजाय उस मालिक की पहचान से शुरू होता है।

ट्रांसफ़र का मालिक खोजें

Android पर, अपडेट उस ऐप पैकेज के बजाय किसी साझा सेवा पैकेज द्वारा लाया जा सकता है जिसे आपने बाहर रखा था, और प्रति-ऐप VPN नियम उस पैकेज पर लागू होता है जो सॉकेट खोलता है। Windows पर, अपडेटर सेवा एप्लिकेशन से अलग निष्पादन पथ के अंतर्गत चल सकती है, इसलिए ऐप पथ से मेल खाने वाला नियम उसे चूक जाता है। macOS पर, कोई विशेषाधिकार प्राप्त हेल्पर या सिस्टम अपडेट डेमॉन ट्रांसफ़र कर सकता है जबकि ऐप केवल उसका अनुरोध करता है।

मालिक को साक्ष्य से पहचानें: प्लेटफ़ॉर्म का नेटवर्क गतिविधि दृश्य, प्रक्रिया के अनुसार फ़िल्टर किया गया पैकेट कैप्चर, या विक्रेता का दस्तावेज़ जो अपडेटर घटक का नाम देता है। प्रक्रिया के नाम से अनुमान लगाना ही वह तरीका है जिससे दो एक जैसी दिखने वाली बाइनरी फ़ाइलें भ्रमित होती हैं और गलत वाली बाहर रखी जाती है।

अपडेट सिस्टम अक्सर काम भी बाँटते हैं। एक छोटा मेटाडेटा अनुरोध किसी संस्करण की जाँच करता है, और उससे कहीं बड़ा पैकेज डाउनलोड किसी कंटेंट डिलीवरी होस्ट या अलग डोमेन पर जाता है। मेटाडेटा जाँच सुरंग से होकर सफल हो सकती है जबकि पैकेज ट्रांसफ़र उस होस्ट पर अटक जाता है जिसे सुरंग अलग तरह से रूट करती है। यही विभाजन उस भ्रमित करने वाली रिपोर्ट को समझाता है जिसमें अपडेट पहचाने जाते हैं पर कभी इंस्टॉल नहीं होते। ऐप खुलता है या नहीं यह जाँचने के बजाय पैकेज डाउनलोड की ही जाँच करें, उसी डिवाइस और उसी नेटवर्क से।

सत्यापन रूट परिवर्तन के बाद भी टिकता है

रूट बदलना TLS, प्रकाशक की पहचान या पैकेज हस्ताक्षर सत्यापन की जगह नहीं लेता। उन जाँचों को बंद न करें क्योंकि डाउनलोड केवल तभी सफल होता है जब आप किसी अव्याख्यायित प्रमाणपत्र चेतावनी को पार करते हैं। केवल बहिष्कृत पथ पर दिखने वाली चेतावनी एक खोज है, बाधा नहीं। बायपास चौड़ा करने से पहले उसकी जाँच करें।

प्रबंधित डिवाइस पर हर सिस्टम सेवा के लिए व्यापक नियम जोड़ने के बजाय समर्थित अपवाद माँगें। एक अपडेटर ठीक करने के लिए सभी साझा सेवाओं को बाहर रखने वाला नियम बायपास को मूल अनुरोध से बहुत आगे तक चौड़ा कर देता है।

अपडेट जाँचें, फिर मालिक का दस्तावेज़ीकरण करें

बदलाव के बाद फिर से कनेक्ट करें और लागू किए गए नियम को फिर से सत्यापित करें, क्योंकि कुछ क्लाइंट सुरंग के फिर से जुड़ने पर अपना रूटिंग फिर से बनाते हैं। एक पूरा अपडेट चक्र चलाएँ: जाँचें, डाउनलोड करें, सत्यापित करें और इंस्टॉल करें। सफल जाँच पथ का केवल सबसे छोटा हिस्सा साबित करती है।

ट्रांसफ़र का मालिक, गंतव्य होस्ट और इच्छित रूट स्प्लिट-टनल नियम के उसी स्थान पर दर्ज करें। अन्यथा अपडेट तंत्र का अगला बदलाव अपवाद को चुपचाप अमान्य कर देगा, और जिसे वह विरासत में मिलेगा उसके पास यह जानने का कोई तरीका नहीं होगा कि नियम किस प्रक्रिया के लिए लिखा गया था।