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) मॅन्युअल पानात स्वच्छता स्क्रिप्ट केल्यास नेमकी हटवण्याची आणि धोरणाची वाक्यरचना आहे.