प्रत्येक एपको किल स्विच बनाम सम्पूर्ण यन्त्रको लकडाउन: के परिवर्तन हुन्छ
लेबल होइन, संरक्षित समूहका आधारमा निर्णय गर्नुहोस्: बहिष्कृत एप, पृष्ठभूमि सहायक र नयाँ जडानका लागि के रोकिन्छ, र प्रत्येक अवस्था कसरी परीक्षण गर्ने.
प्रत्येक एपको किल स्विच सतर्क विकल्पजस्तो सुनिन्छ: टनेल खस्दा कामको क्लाइन्टले मात्र आफ्नो सञ्जाल गुमाउँछ, र बाँकी सबै चलिरहन्छ। त्यसपछि कसैले याद गर्छ कि व्यक्तिगत ब्राउजरले जेसुकै भए पनि पृष्ठ लोड गर्यो, त्यही सुइटसँग आएको सिङ्क सहायकले बारम्बार प्रयास गरिरह्यो, र क्यासमा राखिएको नाम अझै टनेललाई कहिल्यै नछोएको ठेगानामा समाधान भइरहेको थियो। सुविधामा रहेको लेबल र योले वास्तवमै जोगाउने जडानको समूह दुई फरक कुरा हुन्। पहिले संरक्षित समूह निर्धारण गर्नुहोस्, किनकि त्यही समूहले प्रत्येक एपको कार्यान्वयन वा सम्पूर्ण यन्त्रको लकडाउन इमानदार विवरण हो कि होइन भन्ने तय गर्छ।
लेबल होइन, समूहबाट सुरु गर्नुहोस्
प्रत्येक एपको नीतिले छानिएका एपहरू जोगाउँछ। यन्त्रको लकडाउन फराकिलो सञ्जाल सीमातर्फ लक्षित हुन्छ, सामान्यतया स्थानीय प्रिन्टिङ, व्यवस्थापन ट्राफिक वा क्याप्टिभ पोर्टलका लागि अभिलेखित अपवादसहित। तीन प्रश्नको उत्तर नदिँदासम्म कुनै लेबल पूर्ण हुँदैन: बहिष्कृत एपलाई के हुन्छ, ती एपले सुरु गर्ने सहायकलाई के हुन्छ, र सुरक्षा उपलब्ध नहुँदा खोलिएका जडानलाई के हुन्छ।
क्लाइन्टको कुनै पनि सेटिङ छुनुअघि यी उत्तर लेख्नुहोस्। यदि आवश्यकता "यो पेरोल क्लाइन्टले टनेलबाहिर इन्टरनेटसँग कहिल्यै बोल्नु हुँदैन, र मेरो ब्राउजरले बोल्न सक्छ" भन्ने हो भने, समूह सानो छ र प्रत्येक एपको कार्यान्वयन मिल्छ। यदि आवश्यकता "यो यन्त्रमा केही पनि सुरक्षाविना इन्टरनेटसम्म पुग्नु हुँदैन, अपडेट सेवाबाहेक" भन्ने हो भने, कुनै पनि प्रत्येक एपको नीतिले त्यो दिँदैन, किनकि तपाईंले नाम नलिएका एपहरू नै समस्या हुन्।
प्रत्येक एपको कार्यान्वयन पहिचानकर्तासँग मिल्छ, प्रोग्राम नामसँग होइन
Android प्याकेजमार्फत प्रत्येक एपको VPN दिन्छ, र यसको VpnService कागजात ले यो सधैं-खुला सञ्चालन र अवरोधसँग कसरी अन्तरक्रिया गर्छ भन्ने वर्णन गर्छ। iOS व्यवस्थापन प्रोफाइलमार्फत प्रत्येक एपको VPN सेट गर्छ र एप वा डोमेनअनुसार मिलाउँछ। Windows र Linux मा प्रक्रियाअनुसार मार्ग नै छैन, त्यसैले त्यही विचार प्रोग्राममा सीमित फायरवाल नियम वा मालिक प्रयोगकर्तासँग मिल्ने नियमद्वारा अनुमान गरिन्छ।
सीमा पहिचानकर्ता हो, र पहिचानकर्तालाई छल्न सजिलो छ। जुन एपले सिस्टम ब्राउजरलाई URL दिन्छ, वा कुनै भ्युअरमा कागजात खोल्छ, त्यो तपाईंको नीतिले कहिल्यै नाम नलिएको प्रक्रियामा जान्छ। खस्दा अन्त्य गर्ने विकल्प पनि प्याकेट फिल्टर होइन: यसले तपाईंले कन्फिगर गरेको एप मार्छ, तर चाइल्ड प्रक्रिया, क्यु वर्कर वा ब्राउजर ट्याबले विद्यमान सकेट जीवित राख्न सक्छ।
लकडाउनले प्रत्येक एपको नीतिले देख्न नसक्ने कुरा ढाक्छ
सम्पूर्ण यन्त्रको लकडाउनले छनोट हटाउँछ। टनेलको नभएको हरेक बाहिर जाने प्याकेट फालिन्छ, तपाईंको एप नीतिले कहिल्यै नजानेका प्रक्रियाको ट्राफिकसमेत। Android मा यो सधैं-खुला VPN र जडान अवरोध गर्ने सेटिङको संयोजन हो, र कार्यान्वयन सिस्टममा हुन्छ, क्लाइन्ट विन्डोमा होइन। डेस्कटपमा यो स्थायी फायरवाल नियम वा पुग्न नसकिने गेटवेतर्फ देखाइएको पूर्वनिर्धारित मार्ग हो।
मूल्य भनेको बाँकी सबै रोकिन्छ, त्यसैले अपवाद पछिको सोच होइन, डिजाइनको भाग बन्छन्। स्थानीय प्रिन्टर, सेवा खोज, क्याप्टिभ पोर्टल लगइन, व्यवस्थापन एजेन्ट र OS अपडेटलाई प्रत्येकलाई अभिलेखित प्वाल चाहिन्छ, किनकि प्रत्येक टनेल बन्द हुँदा खुला रहने बाटो हो। लकडाउन त्यो सूचीको सबैभन्दा छोटो प्रविष्टिजति मात्र बलियो हुन्छ।
DNS, IPv6 र पृष्ठभूमि सहायकले चुहावट लुकाउँछन्
संरक्षित एपले नाम समाधान गर्न नसक्नुले क्यास गरिएका उत्तर वा सिधा IP ट्राफिक अवरुद्ध छ भनी प्रमाणित गर्दैन। यदि रिजोल्भर टनेलबाहिर अझै पुग्न सकिने छ भने, नाम समाधान हुन्छ र जडान असफल हुन्छ, जुन चलिरहेको किल स्विचजस्तो देखिन्छ र होइन। अझ नराम्रो, क्यास गरिएको रेकर्डले टनेलले नबोक्ने ठेगानातर्फ देखाउन सक्छ, त्यसैले जडान सिधै बाहिर जान्छ अनि एपले VPN त्रुटि रिपोर्ट गर्छ।
IPv6 लाई यो चलाउने हरेक प्लेटफर्ममा आफ्नै नियम चाहिन्छ, किनकि v4 का लागि खसाल्ने नियमले v6 मार्ग ढाक्दैन। मोबाइलमा, निजी DNS सेटिङले समाधानलाई यन्त्र नीतिले जाँच नगर्ने इन्क्रिप्टेड च्यानलमा सार्न सक्छ। र पृष्ठभूमि सहायक डेस्कटपमा सामान्य दोषी हुन्: ट्रेमा अपडेटर वा सिङ्क प्रक्रिया VPN क्लाइन्टअघि सुरु हुन्छ र आफ्नै जडान राख्छ, त्यसैले बदलिएको मार्ग यसले कहिल्यै देख्दैन।
तीन एप र दुई संक्रमण परीक्षण गर्नुहोस्
| Test | What it proves |
|---|---|
| Included app, by name and by direct IP | the policy is applied, not just the resolver |
| Excluded app, same checks | the exclusion is intentional and documented |
| Helper or updater process | nothing inherited an older route |
| Tunnel drop, then Wi-Fi to cellular | the block survives the transition |
हरेक पङ्क्ति दुई पटक चलाउनुहोस्, एक पटक होस्टनामसँग र एक पटक शाब्दिक ठेगानासँग, र सञ्जालले दिन्छ भने अर्को पटक IPv6 मा। उत्तीर्ण भन्नाले समावेश गरिएको एप रोकियो, बहिष्कृत एपले तपाईंले लेखेअनुसार व्यवहार गर्यो, र सहायक बाहिर फिस्किएन। तपाईंले स्वीकार्य ठान्नुभएको सिधा व्यवहार अभिलेख गर्नुहोस्, ताकि अर्को प्रशासकले जानाजान गरिएको अपवाद र खराबीबीच फरक छुट्याउन सकून्।
त्यसपछि नतिजा एउटा वाक्यमा वर्णन गर्नुहोस् जसले एप र सर्तको नाम लिन्छ, उदाहरणका लागि: पेरोल क्लाइन्टसँग टनेलबाहिर मार्ग छैन, ब्राउजर डिजाइनअनुसार सिधा छ, र टनेल बन्द हुँदा बाँकी सबै रोकिन्छ। त्यो वाक्य लेख्न गाह्रो भएमा, नीति अझै एकअर्कासँग लडिरहेका दुई नीति हुन्।