फेल-ओपन वा फेल-क्लोज्ड: VPN किल स्विचले के निर्धारण गर्छ
दुवै शब्दले टनेल गएपछि के हुन्छ भन्ने वर्णन गर्छन्, इन्क्रिप्शन कति बलियो छ भन्ने होइन। तपाईंले छान्ने दायराले ट्राफिक साँच्चै चुहिन्छ कि भन्ने निर्धारण गर्छ।
फेल-क्लोज्ड सुरक्षित सेटिङ र फेल-ओपन लापरवाह हो भन्ने कथा हो। दुवैले टनेल गएपछि ट्राफिकलाई के हुन्छ भन्ने वर्णन गर्छन्, र कुनैले पनि त्यो टनेलले कति राम्ररी इन्क्रिप्ट गर्छ भन्ने बदल्दैन। लामो अपवाद-सूची भएको फेल-क्लोज्ड नीतिले कार्यालय नेटवर्क कहिल्यै नछोड्ने उपकरणमा फेल-ओपन नीतिभन्दा बढी चुहिन सक्छ। ट्राफिकको मालिकलाई बुझाउन सक्ने नतिजा छान्नुहोस्।
लेबलले नतिजा बताउँछ, शक्ति होइन
यो शब्दावली नियन्त्रण प्रणालीबाट आएको हो: कुनै घटक असफल हुँदा फेल-ओपनले सञ्चालनको अनुमति दिन्छ, फेल-क्लोज्डले अस्वीकार गर्छ। VPN मा लागू गर्दा असफल हुने घटक टनेल हो, र प्रश्न ट्राफिकलाई अर्को मार्गबाट जारी राख्न अनुमति छ कि छैन भन्ने हो। साइफरको छनोट, कुञ्जीको लम्बाइ र प्रोटोकल छुट्टाछुट्टै निर्णय हुन्।
भ्रम कायम रहन्छ किनभने किल स्विच सुरक्षा सुविधाजस्तो सुनिन्छ, र विक्रेताहरूले त्यसै गरी बजारीकरण गर्छन्। यान्त्रिक रूपमा यो टनेलले बोक्नुपर्ने ट्राफिक रोक्ने राउटिङ र फायरवाल नियम हो, जो क्लाइन्टमा, अपरेटिङ सिस्टममा वा गेटवेमा लागू गरिन्छ। कुन तहले लागू गर्छ, त्यसैले यसको दायरा पनि निर्धारण गर्छ, र एउटा तहको नियमले अर्कोलाई ढाक्दैन। गेटवेको नियमले पहिले नै अर्को नेटवर्कमा गइसकेको ल्यापटपको रक्षा गर्न सक्दैन।
प्रत्येक नतिजा कस्तो देखिन्छ
एउटै नीति तपाईंले कुन असफलतामा पर्नुहुन्छ भन्ने आधारमा धेरै फरक व्यवहार गर्न सक्छ, त्यसैले लेबल होइन, घटनाहरू तुलना गर्नुहोस्।
| Event | Fail-open result | Fail-closed result |
|---|---|---|
| Tunnel drops while a transfer runs | Transfer continues on the direct path | Transfer stalls until the tunnel returns |
| Client exits or crashes | Rules disappear with the process | Rules persist only if the OS owns them |
| Device boots before sign-in | Normal network access | Blocked until the VPN connects |
| Captive portal needed | Portal loads normally | Portal unreachable without an exception |
| IPv6 not carried by the tunnel | IPv6 traffic leaks directly | Leaks too, unless the block covers IPv6 |
अन्तिम पङ्क्ति त्यही हो जसले किल स्विच एउटै स्विच हो भन्ने ठान्नेहरूलाई समात्छ। IPv4 रुट तालिकाका लागि लेखिएको नियमले IPv6 पूर्वनिर्धारित मार्गलाई अछुतो राख्छ, र एप्लिकेसनले त्यसलाई सहजै प्रयोग गर्न सक्छ।
दायराले चुहिन्छ कि भन्ने निर्धारण गर्छ
कुन मोड हो भन्ने सोध्नुअघि नीतिले के ढाक्छ भन्ने सोध्नुहोस्। प्रति-एप्लिकेसन नियमले एउटा एपको रक्षा गर्छ र अरू केही होइन, उपकरण-व्यापी नियमले अपवादबाहेक सबैको, र गेटवे नियमले त्यो गेटवेसम्म पुग्ने ट्राफिकको मात्र रक्षा गर्छ। DNS लाई आफ्नै निर्णय चाहिन्छ, किनभने स्थानीय रिजोल्भरमा पठाइएको क्वेरीले पेलोड अवरुद्ध हुँदा पनि नामहरू खुलासा गर्न सक्छ।
स्थानीय-नेटवर्कका अपवाद प्रिन्टर, कास्टिङ र क्याप्टिभ पोर्टलका लागि छन्, र प्रत्येक अवरोधमा एउटा प्वाल हो। तिनीहरूलाई नीतिको छेउमा लेख्नुहोस्, किनभने कन्फिगरेसन उत्तराधिकारमा पाउने व्यक्तिले अन्यथा फेल-क्लोज्डलाई निरपेक्ष पढ्नेछ।
पुन: जडान र अवरोध पनि छुट्टाछुट्टै नियन्त्रण हुन्। क्लाइन्ट कहिल्यै अवरोध नगरी स्वचालित रूपमा पुन: जडान हुन सक्छ, वा पुन: जडान नगरी अवरोध गर्न सक्छ, र संयोजनले अवरोधका क्रममा प्रयोगकर्ताले के अनुभव गर्छ भन्ने निर्धारण गर्छ।
संक्रमणको क्रममा यो प्रमाणित गर्नुहोस्
स्थिर अवस्थाको परीक्षणले केही प्रमाणित गर्दैन। टनेल जानाजानी खसाल्नुहोस् र सुरक्षित हुनुपर्ने एप्लिकेसन प्रयास गर्नुहोस्, त्यसपछि त्यो नेटवर्कसम्म पुग्यो कि भनी जाँच्नुहोस्। क्लाइन्टको सूचकलाई नतिजासँग तुलना गर्नुहोस्, किनभने अझै जोडिएको भन्ने सूचक नै यो नीति अस्तित्वमा रहनुको कारण हो। सुरक्षित एप्लिकेसन सफल भयो भने मोडको नामलाई अर्थ छैन; तपाईंसँग चुहावट छ।
साइन-इन अघि कोल्ड बुटबाट दोहोर्याउनुहोस्, Wi-Fi बाट सेलुलरमा जाँदा, र सुरक्षित एप पृष्ठभूमिमा राखेर। यदि अवरोध क्लाइन्ट प्रक्रियाले लागू गर्छ भने, त्यो प्रक्रिया सफासँग बन्द हुनुको सट्टा मारिँदा के हुन्छ त्यो पनि परीक्षण गर्नुहोस्।
अन्तमा, सफाइको बाटो जाँच्नुहोस्। यदि क्लाइन्टका नियम सक्रिय हुँदा त्यो अनइन्स्टल गरियो भने, अपरेटिङ सिस्टमको फायरवाल बन्द गर्नुको सट्टा विक्रेताको लिखित हटाउने प्रक्रिया प्रयोग गर्नुहोस्, किनभने फायरवाल बन्द गर्दा असम्बन्धित सुरक्षा हट्छ र बाँकी नियम कसको हो भन्ने उत्तर दिँदैन।