फेल-ओपन विरुद्ध फेल-क्लोज्ड: 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 वरून सेल्युलरवर जाताना, आणि संरक्षित अॅप पार्श्वभूमीत ठेवून। अडवणूक क्लायंट प्रक्रिया लागू करत असेल, तर ती प्रक्रिया स्वच्छ बंद होण्याऐवजी मारली गेल्यावर काय होते तेही तपासा।
शेवटी, स्वच्छतेचा मार्ग तपासा। क्लायंटचे नियम सक्रिय असताना तो अनइन्स्टॉल केला गेल्यास, ऑपरेटिंग सिस्टमचा फायरवॉल बंद करण्याऐवजी विक्रेत्याची नोंदवलेली काढण्याची प्रक्रिया वापरा, कारण फायरवॉल बंद केल्याने असंबंधित संरक्षण जाते आणि उरलेला नियम कोणाचा आहे याचे उत्तर मिळत नाही।