VPN विच्छेद भएपछि पनि सुरक्षा स्विचले ट्राफिक रोक्छ

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

सुरक्षा स्विच एउटा सेटिङ होइन, कर्नेल अवस्था हो

डेस्कटप क्लाइन्टहरूले टनेलबाहिरको ट्राफिक अस्वीकार गर्ने फिल्टर थपेर ब्लकिङ लागू गर्छन्। Windows मा ती connect-redirect र transport तहका WFP फिल्टर हुन्, र केही स्थायी हुन्छन्: ती Base Filtering Engine नीति भण्डारमा लेखिन्छन् र कुनै पनि VPN सफ्टवेयर चल्नुअघि मेसिन बुट हुँदा पुनर्स्थापित हुन्छन्। क्लाइन्टहरू कहिले सफा गर्ने भन्नेमा फरक पर्छन्। केहीले विच्छेद हुँदा फिल्टर हटाउँछन्, केहीले सफा बन्द हुँदा मात्र, र केहीले पहिले स्विच बन्द गरेको खण्डमा मात्र। ब्लक सक्रिय हुँदा अनइन्स्टल गर्नुहोस्, वा प्रक्रिया मार्नुहोस्, फिल्टर रहन्छन्।

Linux मा समान कुरा आउटपुट मार्गको drop वा reject नियम हो, कहिले forwarding नियम, कहिले परिवर्तित chain नीति। ती नियम थप्ने प्रक्रियाभन्दा लामो बाँच्छन् किनभने ती कर्नेल अवस्था हुन्: क्लाइन्ट मार्नुहोस्, क्र्यास गराउनुहोस् वा बिजुली काट्नुहोस् — कर्नेलले प्याकेट झार्न जारी राख्छ, र त्यसलाई रद्द गर्न केही बाँकी रहँदैन। दिगोपन प्याकेजले वर्तमान नियमसमूहको स्न्यापसट लिएर बुटमा पुनर्स्थापित गरेर दोस्रो दिगोपन तह थप्छ, त्यसैले अर्को सुरुवात ब्लक पहिले नै स्थापित अवस्थामा हुन्छ।

केही हटाउनुअघि WFP अवस्था पढ्नुहोस्

Windows सँग आवश्यक उपकरणहरू आउँछन्। प्रशासकीय प्रम्प्ट चलाउनुहोस् र प्लेटफर्मको अवस्था डम्प गर्नुहोस्; डम्प कार्य निर्देशिकामा wfpstate.xml को रूपमा आउँछ।

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

XML मा गएको विक्रेताको नाम, Block कार्य र तह खोज्नुहोस्। सामान्य ट्राफिक बिगार्ने connect-redirect र transport फिल्टर हुन्; 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 ले प्याकेट काउन्टर थप्छ, र ती काउन्टरले नियम तपाईंका असफल अनुरोधसँग साँच्चै मिल्छ कि chain मा मात्र बस्छ भन्ने बताउँछन्।

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

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

असफलता व्याख्या गर्ने सबैभन्दा साँघुरो वस्तु हटाउनुहोस्

Windows मा पहिलो कदम अझै विक्रेताकै हटाउने मार्ग हो: इन्स्टलर फेरि चलाउनुहोस् र repair वा uninstall प्रयोग गर्नुहोस्, वा विक्रेताले प्रकाशित गरेको खण्डमा सफाइ उपकरण चलाउनुहोस्। बाँकी सेवा र अनुसूचित कार्यहरू सामान्य हुन्, र लगइनमा क्लाइन्ट सुरु गर्ने कार्यले अर्को बुटमा यसका फिल्टर फेरि स्थापना गर्छ। क्लाइन्टको रजिस्ट्री कुञ्जी पढ्दा असफल हुने अनइन्स्टलले सामान्यतया सेवा वा कार्यले त्यसलाई अझै समातिरहेको देखाउँछ, रजिस्ट्री बिग्रिएको होइन।

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 ले बदल्नुहोस्। पहिचान गरेको एउटै नियम हटाउनु chain खाली गर्नुभन्दा राम्रो हो, किनभने तपाईंको आफ्नै नीति अक्षत रहन्छ।

sudo iptables -D OUTPUT -p udp -j REJECT

drop प्रयोगकर्ता-परिभाषित chain मा छ भने, पहिले त्यो chain मा जाने जम्प हटाउनुहोस् र पछि -X ले chain हटाउनुहोस्। drop नियम अझै हुँदा chain नीति ACCEPT बनाउनुले नीति निर्णयसम्म पुग्ने प्याकेटलाई मात्र मद्दत गर्छ। हरेक तालिका खाली गर्नु अन्तिम उपाय हो: यसले अन्य कारणले थपेका नियम पनि हटाउँछ, र ufw सक्रिय भए सेवालाई अब नभएका chain आफ्नै हुन् भन्ने भ्रम पार्छ।

त्यसलाई फेरि राख्ने मालिक खोज्नुहोस्

तत्काल मर्मतपछि अवस्था पुनर्स्थापित गर्ने कुरा खोज्नुहोस्। Linux मा दिगोपन इकाइ सक्रिय छ कि, क्लाइन्टसँग लगइनमा फायरवाल पुनर्स्थापना सेटिङ छ कि, र /etc मुनि सुरक्षित नियम फाइल छ कि जाँच्नुहोस्। Windows मा स्टार्टअप प्रविष्टि, सेवा र अनुसूचित कार्य फेरि जाँच्नुहोस्, अनि रिबुट गरेर अघिकै जस्तै तीही आदेशले अवस्था फेरि पढ्नुहोस्।

ब्लक फर्कियो भने हटाउनु समाधान थिएन; मालिक नै समाधान थियो। कुन क्लाइन्ट वा सेवाले त्यो स्थापना गर्छ लेख्नुहोस् र त्यहीँ सुविधा निष्क्रिय गर्नुहोस्, हरेक विच्छेदपछि फायरवाल तहमा लड्नुभन्दा।

एउटा ping होइन, वास्तविक ट्राफिकले प्रमाणित गर्नुहोस्

नाम रिजोल्युसन, TCP जडान र नयाँ ब्राउजर सत्र परीक्षण गर्नुहोस्, अनि रिबुट गरेर तीही तीन जाँच दोहोर्याउनुहोस्। HTTPS असफल हुँदा ping चल्छ भने त्यो नेटवर्कतर्फ होइन, transport तहको फिल्टरतर्फ संकेत गर्छ, र रिबुटपछि मात्र फेरि देखिने ब्लकले तपाईंले अझै नभेटेको मालिकतर्फ संकेत गर्छ।

प्रमाण राख्नुहोस्: निर्यात गरिएको BFE कुञ्जी, वा परिवर्तनअघि लिइएको iptables -S आउटपुट। मर्मत भयो भन्नुअघि वस्तु कुन तहबाट हटाउनुभयो, त्यसलाई फेरि स्थापना गर्न सक्ने मालिक, एउटा सफा रिबुटपछिको अवस्था, र VPN प्रक्रिया नचलेको अवस्थामा सामान्य ब्राउजिङ चल्छ भन्ने पुष्टि गर्नुहोस्। iptables(8) म्यानुअल पृष्ठमा सफाइ स्क्रिप्ट बनाउँदा ठ्याक्कै हटाउने र नीति वाक्यरचना छ।