ऐप का किल स्विच बनाम फ़ायरवॉल का किल स्विच: कौन क्या रोकता है

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

पहले लागू करने की व्यवस्था का नाम बताएँ

प्रक्रिया समाप्त करना ऐप के जीवनचक्र की सुविधा है। यह पहचानी गई टनल विफलता के बाद चुने हुए प्रोग्राम ढूँढकर उन्हें बंद कर देता है। जो मुख्य प्रक्रिया नहीं है वह सब बच जाता है: सहायक सेवाएँ, पृष्ठभूमि सिंक और एक सेकंड बाद शुरू हुआ कोई भी ऐप, सबका अपना जीवनचक्र और अपना समय है।

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

क्या ब्लॉक क्लाइंट से ज़्यादा टिकता है?

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

लंबे डाउनलोड के बीच क्लाइंट बंद करें और देखें कि स्थानांतरण रुकता है या चलता रहता है।

आम छेद देखें

IPv6 पहला है। IPv4 पतों के लिए लिखा नियम IPv6 ट्रैफ़िक को अछूता छोड़ देता है, और कई क्लाइंट केवल v4 आधा लिखते हैं। दूसरा इंटरफ़ेस है: USB टेथरिंग, दूसरा Wi-Fi एडाप्टर और सेलुलर मॉडेम प्राथमिक कनेक्शन तक सीमित नियम में शामिल न हों। बहिष्कृत ऐप और स्थानीय-नेटवर्क अपवाद तीसरा है।

Windows पर आप टॉगल पर भरोसा करने के बजाय स्थापित नियम पढ़ सकते हैं: Get-NetFirewallRule -DisplayName '*VPN*' और netsh wfp show filters दोनों दिखाते हैं कि क्या मौजूद है। Linux पर iptables -S, ip6tables -S और nft list ruleset आम मामलों को कवर करते हैं, और तीनों की तुलना करना ही मुख्य बात है।

DNS ही आम लीक है

UDP 53 खुला छोड़कर TCP रोकने से आपको बहुत विश्वसनीय किल स्विच मिलता है जो फिर भी हर होस्टनेम क्वेरी का जवाब देता है। यही तब भी लागू होता है जब DNS किसी दूसरे इंटरफ़ेस के रिज़ॉल्वर को सौंपा जाए, या जब क्लाइंट केवल v4 रोके और रिज़ॉल्वर v6 से पहुँच योग्य हो।

टनल बंद होने पर एक ज्ञात नाम रिज़ॉल्व करें और देखें कि जवाब आता है या नहीं। अगर आता है, तो ट्रैफ़िक पूरी तरह ब्लॉक नहीं है, स्टेटस आइकन चाहे कुछ भी कहे।

टॉगल नहीं, संक्रमण जाँचें

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

एक लैपटॉप का नतीजा फ़ोन या राउटर पर नहीं जाता। अलग प्लेटफ़ॉर्म API, अलग डिफ़ॉल्ट, और Android पर अंतर साफ़ है: ब्लॉकिंग के साथ always-on क्लाइंट नहीं, सिस्टम लागू करता है, इसलिए क्लाइंट न करे तब भी वह चलता रहता है। Android VPN मार्गदर्शिका इस विभाजन का वर्णन करती है।

वापसी का रास्ता रखें

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

अगर आप अपने क्लाइंट के लिए क्रैश, IPv6, DNS और संक्रमण जाँचों का जवाब नहीं दे सकते, तो उसे ज्ञात खामियों वाला ऐप-स्तरीय स्विच मानें और उसी हिसाब से योजना बनाएँ।