VPN ऐप क्रैश हो गया: क्या आपका किल स्विच अभी भी चालू है?

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

पहले रीबूट न करें; रीबूट आमतौर पर सबूत नष्ट कर देता है।

जो अभी भी चल रहा है वहीं से शुरू करें

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

अगर डेमॉन ज़िंदा है, तो सुरंग भी शायद ज़िंदा है, और ग़ायब विंडो सिर्फ़ दिखावा है।

Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40

ब्लॉक को ऐप से नहीं, लागू करने वाले से पढ़ें

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

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

स्वच्छ एग्ज़िट और क्रैश में फ़र्क़ करें

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

यही फ़र्क़ आपकी रिकवरी तय करता है: स्वच्छ एग्ज़िट को नया कनेक्शन चाहिए हो सकता है, जबकि क्रैश को बचे हुए नियमों को क्लाइंट की समर्थित मरम्मत क्रिया से हटाना चाहिए हो सकता है।

दूसरे नियंत्रण तोड़े बिना रिकवर करें

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

बार-बार क्रैश होने पर क्लाइंट संस्करण, प्लेटफ़ॉर्म बिल्ड और विक्रेता द्वारा माँगे गए सीमित लॉग इकट्ठा करें। किसी दूसरे खाते का क्लाइंट प्रोफ़ाइल, निजी कुंजी या पूरा कनेक्शन लॉग क्रैश रिपोर्ट के लिए ज़रूरी नहीं है, और इन्हें शामिल करना सहायता मामले को डेटा-प्रबंधन समस्या बना देता है।

एक क्रैश लीक का सबूत नहीं है। सबूत वह पैकेट है जो उस पथ से निकलते देखा गया जिसे नीति को रोकना था, उसी पल कैद किया गया जब क्लाइंट बंद था। इसे जानबूझकर, एक हानिरहित गंतव्य के साथ परखें, और लिखें कि कौन-सी प्रवर्तन परत टिकी रही।