तपाईंले सुरुङबाट बाहिर राख्नुभएको एपलाई तपाईंको किल स्विचले रोक्छ?

किल स्विच खुला छ, एउटा एप जानाजान सुरुङबाट बाहिर राखिएको छ, र दुवै आवश्यकता अब एकअर्कासँग बाझिएका छन्। एउटा भन्छ सुरुङबाहेक केही बाहिर जान सक्दैन, अर्को भन्छ यो प्रोग्राम सिधै जानुपर्छ। हरेक क्लाइन्टले यो द्वन्द्व फरक तरिकाले समाधान गर्छ, र सेटिङ पृष्ठले कुन नियम जित्छ भन्ने विरलै बताउँछ। कुनै पनि लेबलमा भरोसा गर्नुअघि एपअनुसार नीति लेख्नुहोस्।

दुई नीति, एउटा मेसिन

किल स्विच असफलताबारे एउटा वाचा हो: जब सुरुङले ट्राफिक सुरक्षित गर्दैन, ट्राफिक रोकिन्छ। विभाजित सुरुङ छनोटबारे एउटा वाचा हो: यी प्रोग्राम वा गन्तव्यहरूले सुरुङ प्रयोग गर्छन्, र ती गर्दैनन्। दोस्रो वाचाले पहिलोले निर्णय गर्नुपर्ने ट्राफिक बनाउँछ। कुनै पनि वाचा गलत होइन; फरक मानिसहरूले फरक खतराका लागि ती लेखेका हुन्।

तीन परिणाम सम्भव छन् र तीमध्ये एउटा मात्र तैनाथीको उद्देश्य थियो। बाहिर राखिएको एप अवरोधका बेला सिधै रहन सक्छ, जसले विभाजनको सम्मान गर्छ र किल स्विच तोड्छ। यसलाई बाँकी सबैसँगै ब्लक गर्न सकिन्छ, जसले किल स्विचको सम्मान गर्छ र विभाजन तोड्छ। वा इन्टरफेस हराएपछि प्लेटफर्मले नियमको मूल्याङ्कन कसरी गर्छ भन्ने आधारमा यो कहिलेकाहीँ मात्र ब्लक हुन सक्छ। त्यही अन्तिम अवस्थाले टिकट बनाउँछ।

नियमभन्दा पहिले एपको सूची लेख्नुहोस्

सुरुङ प्रयोग गर्नुपर्ने प्रोग्राम, सिधै जानुपर्ने प्रोग्राम, र कुनै पनि सूचीमा कहिल्यै देखिन नहुने नाम वा गन्तव्यहरू सूचीबद्ध गर्नुहोस्। रिजोल्भरको व्यवहार र IPv6 पक्ष अलग राख्नुहोस्, किनकि दुवैले पृष्ठ ट्राफिकभन्दा फरक नीति पछ्याउन सक्छन्।

एपअनुसारका नियम सामान्यतया कार्यान्वयनयोग्य फाइल वा प्याकेजसँग मिल्छन्, त्यभित्रको प्रोफाइलसँग होइन। ब्राउजर प्रोफाइल, निजी विन्डो र एक्सटेन्सनले आफ्नै नेटवर्क पहिचान बोक्दैनन्, त्यसैले प्रक्रियाले पाएको कुरा उत्तराधिकारमा पाउँछन्। त्यो ब्राउजरले सुरु गरेको सहायक प्रक्रियाले त्यही नियम पटक्कै नपाउन सक्छ।

एउटा होइन, दुई सूची चाहिन्छ: सुरुङले के बोक्नुपर्छ, र के कुनै कारणले पनि यसको बाहिर जानु हुँदैन। दुवैमा देखिने एप कार्यान्वयनको विस्तार नभई आवश्यकताको द्वन्द्व हो, र क्लाइन्ट कन्फिगर गर्नुअघि यसलाई टुङ्गो लगाउनुपर्छ।

अवरोधका बेला क्लाइन्ट के गर्छ

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

VPN बिनाको जडान ब्लक गर्ने विकल्पसहितको Android को सधैं-खुला VPN सबैभन्दा स्पष्ट अवस्था हो, किनकि लकडाउन क्लाइन्टले होइन प्लेटफर्मले लागू गर्छ, र सुरुङ बन्द हुँदा बाहिर राखिएको प्याकेज बाँकी सबैसँगै ब्लक हुन्छ। आफ्नै ड्राइभरभित्र एपअनुसारका अपवाद लागू गर्ने डेस्कटप क्लाइन्टले सामान्यतया बाहिर राखिएको प्रक्रिया भौतिक इन्टरफेसमै छोड्छ, किनकि त्यसले त्यो प्रक्रियाको ट्राफिक कहिल्यै ओगटेको थिएन। दुवै व्यवहार रक्षायोग्य छन् र तीमध्ये एउटा मात्र बाहिर राखिएको एप प्रयोगयोग्य रहनुपर्छ भन्ने आवश्यकतासँग मिल्छ। नतिजा व्याख्या गर्नुअघि कुन घटकले नियम लागू गर्छ सोध्नुहोस्।

तपाईंअगाडिको अपरेटिङ सिस्टमको व्यवहार पढ्नुहोस्, अन्यत्र त्यही नामको सेटिङ होइन। लागू गर्ने API फरक छन्, र एउटा चेकबक्सले डेस्कटप र फोनमा पूर्ण रूपमा फरक अर्थ राख्न सक्छ। संस्करण पनि महत्त्वपूर्ण छ, किनकि Android संस्करणहरूबीच लकडाउन नियन्त्रण स्क्रिनहरूबीच सर्यो, र क्लाइन्ट पक्षको अपवाद सूची प्लेटफर्म लकडाउनजस्तै नियन्त्रण होइन।

तीन क्षण: सुरुङ खुला, सुरुङ बन्द, पुनः जडान

तीन क्षणमा हानिरहित अनुरोध प्रयोग गर्नुहोस्: सुरुङ चलिरहेको बेला, तपाईंलाई महत्त्वपूर्ण असफलताका बेला, र पुनः जडानपछि। एउटा ब्राउजर नतिजाले बाहिर राखिएको एपको व्यवहार स्थापित गर्न सक्दैन।

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --interface tun0 https://api.ipify.org
dig +short example.com

निर्गमन ठेगानाले कुन बाटो लिइयो देखाउँछ, र स्पष्ट इन्टरफेस परीक्षणले सुरुङ नै एकमात्र उपलब्ध निकास हुँदा के हुन्छ देखाउँछ। कुनै पनि चलाउनुअघि हरेक लाइनको छेउमा अपेक्षित नतिजा लेख्नुहोस्, नत्र आउटपुट पछि व्याख्या गरिनेछ।

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