तपाईंको एपको अपडेटहरू स्प्लिट टनेलिङले किन ढाक्दैन
तपाईंले बहिष्कृत गर्नुभएको एप सधैं अपडेट डाउनलोड गर्ने प्रक्रिया होइन। स्थानान्तरणको मालिक पत्ता लगाउनुहोस्, अपडेट प्रमाणीकरण राख्नुहोस् र प्याकेज डाउनलोड परीक्षण गर्नुहोस्।
तपाईंले एप्लिकेसनलाई स्प्लिट-टनेल बहिष्करण सूचीमा थप्नुहुन्छ, एप सिधै इन्टरनेटमा पुग्छ, र तैपनि अपडेटहरू असफल हुन्छन् वा अझै सुरुङबाट घसारिन्छन्। बहिष्करणले काम गर्यो। यसले डाउनलोड गर्ने प्रक्रियाभन्दा फरक प्रक्रिया मात्र ढाक्यो, किनभने आधुनिक अपडेटर विरलै एप्लिकेसन विन्डो जस्तै त्यही कार्यान्वयन योग्य फाइल हुन्छ।
भ्रम: एप बहिष्कृत गर्नु भनेको त्यसको ट्राफिक बहिष्कृत गर्नु
प्रति-एप स्प्लिट टनेलिङले प्लेटफर्म अनुसार प्रक्रिया, प्याकेज वा एप्लिकेसन मार्ग मिलाउँछ। यसले ब्रान्ड, सुविधा वा प्रयोगकर्ताको नियत मिलाउँदैन। जब एप्लिकेसनले डाउनलोडलाई हेल्पर, साझा प्लेटफर्म सेवा वा ब्राउजर कम्पोनेन्टमा सुम्पन्छ, त्यो हेल्परको आफ्नै पहिचान र सुरुङबाट आफ्नै बाटो हुन्छ। बहिष्करण सूचीलाई दुई प्रक्रिया एउटै उत्पादनका हुन् भन्ने थाहै छैन। तपाईंले कुनको नाम लिनुभयो त्यति मात्र जान्दछ।
त्यसैले नियमले भनिएको कुरा ठ्याक्कै गरिरहेको छ। स्थानान्तरण कसको हो भन्ने अनुमान गलत थियो, र सुधार थप बहिष्करण थप्नुको सट्टा त्यो मालिक पहिचान गर्नबाट सुरु हुन्छ।
स्थानान्तरणको मालिक पत्ता लगाउनुहोस्
Android मा, अपडेट तपाईंले बहिष्कृत गर्नुभएको एप प्याकेजको सट्टा साझा सेवा प्याकेजले ल्याउन सक्छ, र प्रति-एप VPN नियम सकेट खोल्ने प्याकेजमा लागू हुन्छ। Windows मा, अपडेटर सेवा एप्लिकेसनभन्दा फरक कार्यान्वयन मार्गमा चल्न सक्छ, त्यसैले एप मार्गसँग मिल्ने नियमले त्यसलाई छुटाउँछ। macOS मा, विशेषाधिकार प्राप्त हेल्पर वा प्रणाली अपडेट डेमनले स्थानान्तरण गर्न सक्छ जबकि एपले मात्र अनुरोध गर्छ।
प्रमाणबाट मालिक पहिचान गर्नुहोस्: प्लेटफर्मको नेटवर्क गतिविधि दृश्य, प्रक्रिया अनुसार फिल्टर गरिएको प्याकेट क्याप्चर, वा अपडेटर कम्पोनेन्टको नाम दिने विक्रेताको कागजात। प्रक्रियाको नामबाट अनुमान गर्नु भनेको दुई समान देखिने बाइनरी भ्रमित गरी गलतलाई बहिष्कृत गर्ने तरिका हो।
अपडेट प्रणालीहरूले काम पनि बाँड्छन्। सानो मेटाडेटा अनुरोधले संस्करण जाँच्छ, र धेरै ठूलो प्याकेज डाउनलोड सामग्री वितरण होस्ट वा अर्को डोमेनमा जान्छ। मेटाडेटा जाँच सुरुङबाट सफल हुन सक्छ जबकि प्याकेज स्थानान्तरण सुरुङले फरक तरिकाले रुट गर्ने होस्टमा अड्किन्छ। यही विभाजनले अपडेट पहिचान हुने तर कहिल्यै स्थापना नहुने भ्रमित प्रतिवेदन व्याख्या गर्छ। एप खुल्छ कि भनेर परीक्षण गर्नुको सट्टा प्याकेज डाउनलोड आफैंलाई उही यन्त्र र उही नेटवर्कबाट परीक्षण गर्नुहोस्।
मार्ग परिवर्तनपछि पनि प्रमाणीकरण टिक्छ
मार्ग बदल्नुले TLS, प्रकाशकको पहिचान वा प्याकेज हस्ताक्षर प्रमाणीकरण प्रतिस्थापन गर्दैन। अव्याख्यायित प्रमाणपत्र चेतावनी पार गरेपछि मात्र डाउनलोड सफल हुन्छ भनेर ती जाँचहरू बन्द नगर्नुहोस्। बहिष्कृत मार्गमा मात्र देखिने चेतावनी अवरोध होइन, एक खोज हो। बाइपास फराकिलो बनाउनुअघि त्यसको अनुसन्धान गर्नुहोस्।
व्यवस्थापित यन्त्रमा, प्रत्येक प्रणाली सेवाका लागि फराकिलो नियम थप्नुको सट्टा समर्थित अपवाद माग्नुहोस्। एउटा अपडेटर ठीक गर्न सबै साझा सेवाहरू बहिष्कृत गर्ने नियमले बाइपासलाई मूल अनुरोधभन्दा धेरै पर फराकिलो बनाउँछ।
अपडेट परीक्षण गर्नुहोस्, त्यसपछि मालिकको अभिलेख गर्नुहोस्
परिवर्तनपछि फेरि जडान गर्नुहोस् र लागू गरिएको नियम फेरि प्रमाणित गर्नुहोस्, किनभने केही क्लाइन्टहरू सुरुङ फेरि जोडिँदा आफ्नो रुटिङ पुनर्निर्माण गर्छन्। एउटा पूर्ण अपडेट चक्र चलाउनुहोस्: जाँच्नुहोस्, डाउनलोड गर्नुहोस्, प्रमाणित गर्नुहोस् र स्थापना गर्नुहोस्। सफल जाँचले मार्गको सबैभन्दा सानो भाग मात्र प्रमाणित गर्छ।
स्थानान्तरणको मालिक, गन्तव्य होस्टहरू र अभिप्रेत मार्ग स्प्लिट-टनेल नियम भएकै ठाउँमा अभिलेख गर्नुहोस्। अन्यथा अपडेट संयन्त्रको अर्को परिवर्तनले अपवादलाई चुपचाप अमान्य बनाउनेछ, र यो उत्तराधिकारमा पाउने व्यक्तिसँग नियम कुन प्रक्रियाका लागि लेखिएको थियो भन्ने जान्ने कुनै उपाय हुनेछैन।