VPN डिस्कनेक्ट होने के बाद भी किल स्विच ट्रैफ़िक को रोकता है

टनल गया, नेटवर्क आइकन सामान्य दिखता है, और कुछ भी लोड नहीं होता। आपने VPN डिस्कनेक्ट किया, या उसे अनइंस्टॉल किया, या रीबूट किया, और ड्रॉप के दौरान आपकी रक्षा करने वाला ब्लॉक अब भी खड़ा है। क्लाइंट विंडो इसे समझा नहीं सकती, क्योंकि आपको रोकने वाला क्लाइंट नहीं है: निर्णय आपके नाम पर कर्नेल में लिखा गया था, और उसे हटाने के लिए पीछे कुछ नहीं छोड़ा गया। Windows में वह स्थिति Windows Filtering Platform में रहती है; Linux में यह iptables या nftables में नियमों का समूह है, अक्सर एक स्नैपशॉट के साथ जो बूट पर फिर से चलाया जाता है। आगे वही क्रम है जो मैं इस्तेमाल करता हूँ: स्थिति पढ़ें, विफलता को समझाने वाला सबसे संकीर्ण ऑब्जेक्ट हटाएँ, और फिर जो भी उसे बार-बार वापस लाता है उसे खोजें।

किल स्विच कर्नेल की स्थिति है, कोई सेटिंग नहीं

डेस्कटॉप क्लाइंट टनल के बाहर के ट्रैफ़िक को अस्वीकार करने वाले फ़िल्टर जोड़कर ब्लॉकिंग लागू करते हैं। Windows में ये कनेक्शन-रीडायरेक्ट और ट्रांसपोर्ट परतों पर WFP फ़िल्टर हैं, और इनमें से कुछ स्थायी हैं: वे Base Filtering Engine के नीति भंडार में दर्ज होते हैं और मशीन बूट होने पर बहाल होते हैं, किसी भी VPN सॉफ़्टवेयर के चलने से पहले। क्लाइंट इस बात में अलग हैं कि वे कब सफ़ाई करते हैं। कुछ डिस्कनेक्ट पर फ़िल्टर हटाते हैं, कुछ केवल साफ़ एग्ज़िट पर, और कुछ केवल तब जब किल स्विच पहले बंद किया जाए। ब्लॉक सक्रिय रहते हुए अनइंस्टॉल करें, या प्रोसेस को मार दें, और फ़िल्टर रह जाते हैं।

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

कुछ भी हटाने से पहले WFP स्थिति पढ़ें

Windows आपके लिए ज़रूरी उपकरण देता है। एलिवेटेड प्रॉम्प्ट चलाएँ और प्लेटफ़ॉर्म की स्थिति डंप करें; डंप कार्य निर्देशिका में wfpstate.xml के रूप में आता है।

netsh wfp show state
netsh wfp show filters
Get-Service bfe

XML में गए हुए विक्रेता का नाम, Block क्रिया और परत खोजें। कनेक्शन-रीडायरेक्ट और ट्रांसपोर्ट पर फ़िल्टर ही सामान्य ट्रैफ़िक तोड़ते हैं; receive-accept परत पर फ़िल्टर आमतौर पर आपका कारण नहीं होता। अगर Base Filtering Engine बिलकुल नहीं चल रहा है, तो कहीं और देखें, क्योंकि उन फ़िल्टरों को लागू करने में और कुछ सक्षम नहीं है।

सामान्य फ़ायरवॉल दृश्य भी जाँचें, क्योंकि ज़्यादातर लोग दोनों में से केवल एक ही देखते हैं:

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

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

Linux नियम उसी सिंटैक्स में पढ़ें जिससे आप हटाएँगे

iptables -S नियमों को उसी रूप में छापता है जिसमें उन्हें जोड़ा जाता है, जिससे आउटपुट हटाने के लिए सीधे दोबारा इस्तेमाल करने योग्य हो जाता है। iptables -L -v -n पैकेट काउंटर जोड़ता है, और वे काउंटर बताते हैं कि कोई नियम वास्तव में आपके विफल अनुरोधों से मेल खाता है या केवल चेन में बैठा है।

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

चेन नीतियाँ पढ़ें, केवल नियम नहीं: -P OUTPUT DROP कोई नियम मेल न खाने पर भी ट्रैफ़िक रोकता है। IPv6 को अलग से जाँचें, क्योंकि दोनों परिवार इंस्टॉल करने वाला क्लाइंट IPv4 नियम जाने के बाद भी IPv6 ब्लॉक छोड़ सकता है, और तब लक्षण इस पर निर्भर करता है कि ऐप्लिकेशन किस परिवार को पसंद करता है। जहाँ nftables इस्तेमाल होता है, वहाँ nft list ruleset भी चलाएँ; दोनों उपकरण एक संगतता परत के ज़रिए साथ रहते हैं, और एक सूची ज़रूरी नहीं कि हर उस नियम को दिखाए जो पैकेट गिरा सकता है।

विफलता को समझाने वाला सबसे संकीर्ण ऑब्जेक्ट हटाएँ

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

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

स्थायी फ़िल्टर आख़िरी उपाय हैं। वे HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter के अंतर्गत रहते हैं, हर फ़िल्टर के लिए GUID कुंजी वाला एक मान। पहले कुंजी निर्यात करें, जो GUID हटा रहे हैं उन्हें दर्ज करें, केवल गए हुए क्लाइंट के मान हटाएँ, फिर रीबूट करें ताकि इंजन अपनी स्थिति फिर बनाए। पूरी कुंजी न हटाएँ और Base Filtering Engine बंद न करें: Windows Firewall और Defender इस पर निर्भर हैं, और आप एक व्यवधान को उससे बदतर से बदल देंगे।

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

Linux में, iptables -S जो पंक्ति छापता है उसे लें और -A को -D से बदलें। पहचाना गया वह एक नियम हटाना चेन फ़्लश करने से बेहतर है, क्योंकि यह आपकी अपनी नीति को अक्षुण्ण रखता है।

sudo iptables -D OUTPUT -p udp -j REJECT

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

उस मालिक को खोजें जो उसे वापस लाता है

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

अगर ब्लॉक लौटता है, तो हटाना समाधान नहीं था; मालिक था। दर्ज करें कि कौन-सा क्लाइंट या सेवा इसे इंस्टॉल करती है और वहीं सुविधा बंद करें, हर डिस्कनेक्ट के बाद फ़ायरवॉल परत पर उससे लड़ने के बजाय।

एक पिंग नहीं, असली ट्रैफ़िक से सत्यापित करें

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

सबूत रखें: निर्यात की गई BFE कुंजी, या बदलाव से पहले पकड़ा गया iptables -S आउटपुट। इसे ठीक कहने से पहले पुष्टि करें कि आपने ऑब्जेक्ट किस परत से हटाया, कौन-सा मालिक उसे फिर इंस्टॉल कर सकता है, एक साफ़ रीबूट के बाद की स्थिति, और कि कोई VPN प्रोसेस चले बिना सामान्य ब्राउज़िंग काम करती है। यदि आप सफ़ाई को स्क्रिप्ट करते हैं तो iptables(8) मैन पेज में सटीक हटाने और नीति सिंटैक्स है।