Patuloy na hinaharangan ng kill switch ang trapiko matapos humiwalay ang VPN

Wala na ang tunnel, mukhang normal ang icon ng network, at walang naglo-load. Nag-disconnect ka ng VPN, nag-uninstall, o nag-reboot, at nakatayo pa rin ang block na dapat sana ay protektahan ka kapag bumagsak ang koneksyon. Hindi ito maipaliwanag ng client window, dahil hindi ang client ang humaharang sa iyo: isinulat ang desisyon sa kernel sa iyong pangalan, at walang naiwan para alisin iyon. Sa Windows nasa Windows Filtering Platform ang estadong iyon; sa Linux ito ay set ng patakaran sa iptables o nftables, kadalasan may snapshot na muling inilalapat sa boot. Ito ang pagkakasunod-sunod na ginagamit ko: basahin ang estado, tanggalin ang pinakamakitid na bagay na nagpapaliwanag ng pagkabigo, pagkatapos hanapin ang anumang patuloy na nagbabalik nito.

Ang kill switch ay estado ng kernel, hindi setting

Hinaharangan ng mga desktop client sa pamamagitan ng pagdaragdag ng mga filter na tumatanggi sa trapiko sa labas ng tunnel. Sa Windows, mga WFP filter iyon sa connect-redirect at transport layer, at ang ilan ay permanente: nakatala sila sa policy store ng Base Filtering Engine at ibinabalik kapag nag-boot ang makina, bago tumakbo ang anumang VPN software. Nagkakaiba ang mga client sa kung kailan sila naglilinis. May nag-aalis ng filter kapag nag-disconnect, may sa malinis na paglabas lang, at may kapag pinatay muna ang switch. Mag-uninstall habang aktibo ang block, o patayin ang proseso, at mananatili ang mga filter.

Ang katumbas sa Linux ay drop o reject na patakaran sa output path, kung minsan forwarding rule, kung minsan binagong chain policy. Nabubuhay ang mga patakarang iyon nang mas matagal kaysa sa prosesong nagdagdag sa kanila dahil estado sila ng kernel: patayin ang client, i-crash ito, o putulin ang kuryente, at patuloy na nagtatapon ang kernel ng packet na wala nang natitira para bawiin iyon. Ang persistence package ay nagdadagdag ng ikalawang layer ng pagiging permanente sa pamamagitan ng pagkuha ng snapshot ng kasalukuyang rule set at pagbalik nito sa boot, kaya ang susunod na simula ay nagsisimula nang naka-install na ang block.

Basahin ang WFP state bago magbura ng anuman

May kasamang kagamitan ang Windows na kailangan mo. Magpatakbo ng elevated prompt at i-dump ang platform state; lalabas ang dump bilang wfpstate.xml sa working directory.

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

Hanapin sa XML ang pangalan ng umalis na vendor, isang Block action, at ang layer. Ang mga filter sa connect-redirect at transport ang sumisira sa ordinaryong trapiko; ang filter sa receive-accept layer ay kadalasan hindi ang dahilan mo. Kung hindi talaga tumatakbo ang Base Filtering Engine, tumingin sa ibang lugar, dahil wala nang ibang makakapagpatupad ng mga filter na iyon.

I-cross-check din ang ordinaryong firewall view, dahil karamihan ay isa lang sa dalawa ang sinisiyasat:

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

Kapag naka-on ang built-in profile at walang patakarang tumutugma sa bumabagsak na trapiko, galing ang block sa third-party provider at hindi sa Windows Firewall. Ang pagkakaibang iyon ang nagtatakda kung aling kagamitan ang gagamitin mo sa pag-aayos.

Basahin ang Linux rule sa syntax na gagamitin mo sa pagbura

iptables -S ay nagpi-print ng patakaran sa parehong anyo na ginamit sa pagdagdag, kaya direktang magagamit muli ang output sa pagbura. iptables -L -v -n ay nagdaragdag ng packet counter, at sinasabi ng counter na iyon kung talagang tumutugma ang patakaran sa mga nabigong kahilingan mo o nakaupo lang sa chain.

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

Basahin ang chain policy, hindi lang ang patakaran: hinaharangan ng -P OUTPUT DROP ang trapiko kahit walang patakarang tumutugma. Suriin ang IPv6 nang hiwalay, dahil ang client na nag-i-install ng dalawang pamilya ay maaaring mag-iwan ng IPv6 block pagkatapos mawala ang IPv4 rule, at ang sintomas ay depende na sa kung aling pamilya ang pinipili ng application. Kung saan ginagamit ang nftables, patakbuhin din ang nft list ruleset; magkasamang umiiral ang dalawang kagamitan sa pamamagitan ng compatibility layer, at hindi laging ipinapakita ng isang listahan ang bawat patakarang makakatapon ng packet.

Tanggalin ang pinakamakitid na bagay na nagpapaliwanag ng pagkabigo

Sa Windows, ang unang hakbang ay pa rin ang sariling removal path ng vendor: patakbuhin muli ang installer at gamitin ang repair o uninstall, o patakbuhin ang cleanup tool kung naglalathala ang vendor. Karaniwan ang natirang service at naka-iskedyul na gawain, at ang gawaing nagpapasimula ng client sa logon ay muling nag-i-install ng mga filter nito sa susunod na boot. Ang uninstall na nabigo habang binabasa ang registry key ng client ay kadalasang nangangahulugang may service o gawain pang humahawak doon, hindi na sira ang registry.

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

Ang permanenteng filter ang huling paraan. Nasa ilalim sila ng HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, isang value bawat filter na may GUID na key. I-export muna ang key, itala ang mga GUID na tinatanggal, tanggalin lang ang mga value na pag-aari ng umalis na client, pagkatapos mag-reboot para muling buuin ng engine ang estado nito. Huwag burahin ang buong key at huwag i-disable ang Base Filtering Engine: umaasa rito ang Windows Firewall at Defender, at ipagpapalit mo ang isang outage sa mas malala.

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

Sa Linux, kunin ang linyang ini-print ng iptables -S at palitan ang -A ng -D. Mas mabuti ang pagbura ng isang patakarang natukoy mo kaysa pag-empty ng chain, dahil nananatiling buo ang sarili mong policy.

sudo iptables -D OUTPUT -p udp -j REJECT

Kung nasa user-defined chain ang drop, burahin muna ang pagtalon sa chain na iyon at pagkatapos alisin ang chain gamit ang -X. Ang pagtatakda ng chain policy sa ACCEPT habang naroon pa ang drop rule ay tumutulong lang sa mga packet na umaabot sa policy decision. Ang pag-empty ng bawat table ay huling paraan: tinatanggal din nito ang mga patakarang idinagdag mo para sa ibang dahilan, at kapag naka-enable ang ufw, iniiwan nito ang service na naniniwalang pag-aari nito ang mga chain na wala na.

Hanapin ang may-ari na nagbabalik nito

Pagkatapos ng agarang pag-aayos, hanapin ang anumang magbabalik ng estado. Sa Linux, tingnan kung naka-enable ang persistence unit, kung may setting ang client na magbalik ng firewall sa logon, at kung may naka-save na rule file sa ilalim ng /etc. Sa Windows, tingnan muli ang startup entry, service, at naka-iskedyul na gawain, pagkatapos mag-reboot at basahin ang estado gamit ang parehong command tulad ng dati.

Kung bumalik ang block, hindi ang pagbura ang solusyon; ang may-ari ang solusyon. Itala kung aling client o service ang nag-i-install at i-disable ang feature doon, sa halip na labanan ito sa firewall layer pagkatapos ng bawat disconnect.

I-verify gamit ang tunay na trapiko, hindi isang ping

Subukan ang name lookup, TCP connection, at bagong browser session, pagkatapos mag-reboot at ulitin ang parehong tatlong check. Ang ping na gumagana habang nabigo ang HTTPS ay tumuturo sa filter sa transport layer at hindi sa network, at ang block na bumabalik lang pagkatapos ng reboot ay tumuturo sa may-ari na hindi mo pa nahahanap.

Itago ang ebidensya: ang na-export na BFE key, o ang iptables -S output na nakuha bago ang pagbabago. Bago sabihing naayos na, kumpirmahin ang layer na tinanggalan mo ng bagay, ang may-ari na maaaring muling mag-install, ang estado pagkatapos ng isang malinis na reboot, at gumagana ang ordinaryong pag-browse nang walang tumatakbong VPN process. Ang man page ng iptables(8) ay may eksaktong syntax ng pagbura at policy kung iskrip mo ang paglilinis.