बाहर निकलना या डिस्कनेक्ट करना: VPN के दो अलग नतीजे

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

क्लाइंट का दस्तावेज़ीकरण ही एकमात्र भरोसेमंद जगह है जहाँ से पता चलता है कि कौन-सा क्या है।

चार नियंत्रण, संभवतः चार व्यवहार

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

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

सर्वर पक्ष का व्यवधान पूरी तरह पाँचवाँ रास्ता है, और उपयोगकर्ताओं का सामना वास्तव में सबसे अधिक इसी से होता है।

हर क्रिया से पहले और बाद में स्थिति पढ़ें

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

systemctl status wg-quick@wg0 --no-pager
pgrep -a -f 'openvpn|wireguard|vpnagent'
ip link show | grep -E 'tun|wg'
nft list ruleset | grep -E 'drop|reject' | head -20
scutil --nc list

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

हाथ से डिस्कनेक्ट करना क्रैश नहीं है

डिस्कनेक्ट करना इच्छित शटडाउन पथ चलाता है, और क्रैश उसे छोड़ देता है। इसलिए एक के नतीजे दूसरे पर लागू नहीं होते, इसलिए मेन्यू विकल्प का उपयोग करने वाली जाँच क्लाइंट के मरने पर व्यवहार के बारे में दावे का समर्थन नहीं कर सकती।

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

वह अनुपलब्ध स्थिति चुनें जो आपको वास्तव में चाहिए

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

अगर लक्ष्य सामान्य सीधी पहुँच है, तो प्रक्रियाएँ मारने या पूरा फ़ायरवॉल बंद करने के बजाय दस्तावेज़ित नियंत्रण का उपयोग करें। बाधित निकास के छोड़े पुराने नियम जानबूझकर किए गए लॉकडाउन से अलग समस्या हैं, और उन्हें अलग सुधार चाहिए।

लिखें कि कौन-सा घटक रुका: टनल, दिखने वाला ऐप्लिकेशन, या नीति लागू करने वाली परत। वह एक वाक्य इन नियंत्रणों से पैदा होने वाली ज़्यादातर उलझन रोक देता है।