मिथक यह है कि फेल-क्लोज़्ड सुरक्षित सेटिंग है और फेल-ओपन लापरवाह। दोनों बताते हैं कि टनल के जाने के बाद ट्रैफ़िक के साथ क्या होता है, और इनमें से कोई भी यह नहीं बदलता कि वह टनल कितना अच्छा एन्क्रिप्ट करता है। लंबी अपवाद-सूची वाली फेल-क्लोज़्ड नीति ऐसे डिवाइस पर फेल-ओपन नीति से ज़्यादा लीक कर सकती है जो कभी ऑफ़िस नेटवर्क नहीं छोड़ता। वह नतीजा चुनें जिसे आप ट्रैफ़िक के मालिक को समझा सकें।

लेबल नतीजा बताता है, ताकत नहीं

यह शब्दावली नियंत्रण प्रणालियों से आती है: फेल-ओपन किसी घटक के विफल होने पर काम की अनुमति देता है, फेल-क्लोज़्ड उसे अस्वीकार करता है। VPN पर लागू करने पर विफल होने वाला घटक टनल है, और सवाल यह है कि क्या ट्रैफ़िक को किसी दूसरे रास्ते से जारी रहने की अनुमति है। साइफ़र का चुनाव, कुंजी की लंबाई और प्रोटोकॉल अलग निर्णय हैं।

उलझन बनी रहती है क्योंकि किल स्विच सुरक्षा सुविधा जैसा लगता है, और विक्रेता इसे वैसे ही बेचते हैं। यांत्रिक रूप से यह एक राउटिंग और फ़ायरवॉल नियम है जो उस ट्रैफ़िक को रोकता है जिसे टनल को ले जाना था, जो क्लाइंट में, ऑपरेटिंग सिस्टम में या गेटवे पर लागू होता है। जो परत इसे लागू करती है वही इसका दायरा भी तय करती है, और एक परत का नियम दूसरी को नहीं ढकता। गेटवे का नियम उस लैपटॉप की रक्षा नहीं कर सकता जो पहले ही दूसरे नेटवर्क पर जा चुका है।

हर नतीजा कैसा दिखता है

एक ही नीति इस बात पर बहुत अलग व्यवहार कर सकती है कि आपको कौन-सी विफलता मिलती है, इसलिए लेबल नहीं, घटनाओं की तुलना करें।

EventFail-open resultFail-closed result
Tunnel drops while a transfer runsTransfer continues on the direct pathTransfer stalls until the tunnel returns
Client exits or crashesRules disappear with the processRules persist only if the OS owns them
Device boots before sign-inNormal network accessBlocked until the VPN connects
Captive portal neededPortal loads normallyPortal unreachable without an exception
IPv6 not carried by the tunnelIPv6 traffic leaks directlyLeaks too, unless the block covers IPv6

आख़िरी पंक्ति वही है जो उन्हें पकड़ती है जो मानते हैं कि किल स्विच एक ही स्विच है। IPv4 रूट तालिका के लिए लिखा नियम IPv6 के डिफ़ॉल्ट मार्ग को अछूता छोड़ देता है, और एप्लिकेशन उसका आराम से उपयोग कर सकता है।

दायरा तय करता है कि लीक होगा या नहीं

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

स्थानीय-नेटवर्क अपवाद प्रिंटर, कास्टिंग और कैप्टिव पोर्टल के लिए होते हैं, और हर एक ब्लॉक में एक छेद है। उन्हें नीति के बगल में दर्ज करें, क्योंकि कॉन्फ़िगरेशन विरासत में पाने वाला व्यक्ति अन्यथा फेल-क्लोज़्ड को निरपेक्ष पढ़ेगा।

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

संक्रमण के दौरान इसे साबित करें

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

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

अंत में, सफ़ाई का रास्ता देखें। अगर किसी क्लाइंट के नियम सक्रिय रहते हुए उसे अनइंस्टॉल किया जाए, तो ऑपरेटिंग सिस्टम का फ़ायरवॉल बंद करने के बजाय विक्रेता की दस्तावेज़ी हटाने की प्रक्रिया अपनाएँ, जो बचे हुए नियम का मालिक कौन है इसका उत्तर दिए बिना असंबंधित सुरक्षा हटा देता है।

संबंधित लेख