अ‍ॅपचा किल स्विच vs फायरवॉलचा किल स्विच: प्रत्येक काय थांबवतो
एक किल स्विच अ‍ॅप्स बंद करतो आणि दुसरा पॅकेट फिल्टर बसवतो. या तपासण्या क्रमाने करा आणि प्रामाणिक उत्तर देता येणार नाही अशा पहिल्यावर थांबा.
फीचर यादीतील किल स्विच टनेल पडल्यावर काय होते याबद्दल जवळपास काहीच सांगत नाही. एक अंमलबजावणी निवडलेल्या प्रक्रिया बंद करते, दुसरी ऑपरेटिंग सिस्टमच्या सीमेवर पॅकेट फिल्टर बसवते, आणि तिसरी फक्त पुन्हा जोडण्याचा प्रयत्न करते. फरक अपयशानंतरच्या सेकंदांत दिसतो, सेटिंग्ज स्क्रीनवर नाही. या तपासण्या क्रमाने करा आणि प्रामाणिक उत्तर देता येणार नाही अशा पहिल्यावर थांबा, कारण तिथेच तुमची खरी व्याप्ती संपते.
आधी अंमलबजावणीच्या यंत्रणेचे नाव द्या
प्रक्रिया थांबवणे हे अ‍ॅपच्या जीवनचक्राचे वैशिष्ट्य आहे. ओळखलेल्या टनेल अपयशानंतर ते निवडलेले प्रोग्राम शोधते आणि बंद करते. मुख्य प्रक्रिया नसलेले सर्व टिकते: सहाय्यक सेवा, पार्श्वभूमी सिंक आणि एक सेकंदानंतर सुरू झालेले कोणतेही अ‍ॅप, प्रत्येकाचे स्वतःचे जीवनचक्र आणि स्वतःची वेळ असते.
पॅकेट फिल्टरिंग हे ऑपरेटिंग सिस्टमचे वैशिष्ट्य आहे. अनुमत मार्गाने न जाणारा रहदारी ते नाकारते, हे अधिक मजबूत वचन आहे, पण नियम प्रत्यक्षात जुळतो तेवढ्यापुरतेच. पत्ता कुटुंब, इंटरफेस, वगळलेली अ‍ॅप्स आणि अपवाद हे ठरवतात, क्लायंटमधील लेबल नाही.
ब्लॉक क्लायंटपेक्षा जास्त टिकतो का?
या क्रमाने चार प्रश्न विचारा: क्रॅशमध्ये, हाताने बाहेर पडताना, लॉगआउटमध्ये आणि रीबूटमध्ये काय होते. क्लायंट स्वतः ज्या नियमाची देखभाल करतो तो सहसा स्वच्छ शटडाउनमध्ये काढला जातो आणि अनेकदा क्रॅशनंतर राहतो. प्लॅटफॉर्म स्टोअरमध्ये स्थापित नियम उलटा वागू शकतो: क्लायंट आणि कधीकधी अनइन्स्टॉल दोन्ही टिकून राहतो.
लांब डाउनलोडच्या मध्ये क्लायंट बंद करा आणि हस्तांतरण थांबते की सुरू राहते ते पाहा.
नेहमीची छिद्रे शोधा
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 आणि संक्रमण तपासण्यांना उत्तर देऊ शकत नसाल, तर त्याला ज्ञात छिद्रांसह अ‍ॅप-स्तरीय स्विच समजा आणि त्यानुसार नियोजन करा.