Kill Switch Masih Menyekat Trafik Selepas VPN Terputus

Tunel sudah tiada, ikon rangkaian kelihatan normal, dan tiada apa yang dimuatkan. Anda memutuskan VPN, menyahpasangnya, atau memulakan semula, dan sekatan yang sepatutnya melindungi anda semasa sambungan terputus masih berdiri. Tetingkap klien tidak dapat menjelaskannya, kerana bukan klien yang menyekat anda: keputusan itu ditulis ke dalam kernel atas nama anda, dan tiada apa yang ditinggalkan untuk mengeluarkannya. Pada Windows keadaan itu berada dalam Windows Filtering Platform; pada Linux ia ialah set peraturan dalam iptables atau nftables, selalunya dengan syot yang dimainkan semula semasa but. Berikut ialah urutan yang saya gunakan: baca keadaan, padam objek paling sempit yang menjelaskan kegagalan, kemudian cari apa sahaja yang terus memasukkannya semula.

Kill switch ialah keadaan kernel, bukan tetapan

Klien desktop melaksanakan penyekatan dengan menambah penapis yang menolak trafik di luar tunel. Pada Windows itu ialah penapis WFP pada lapisan connect-redirect dan transport, dan sesetengahnya kekal: ia direkodkan dalam stor dasar Base Filtering Engine dan dipulihkan apabila mesin but, sebelum sebarang perisian VPN berjalan. Klien berbeza dari segi bila ia membersihkan. Sesetengah mengeluarkan penapis semasa putus, sesetengah hanya semasa keluar bersih, dan sesetengah hanya apabila suis kill switch dimatikan dahulu. Nyahpasang semasa sekatan aktif, atau bunuh proses, dan penapis kekal.

Persamaan Linux ialah peraturan drop atau reject dalam laluan output, kadang-kadang peraturan forwarding, kadang-kadang dasar rantai yang diubah. Peraturan itu hidup lebih lama daripada proses yang menambahnya kerana ia keadaan kernel: bunuh klien, buat ia ranap, atau potong kuasa, dan kernel terus menggugurkan paket tanpa apa-apa yang tinggal untuk membatalkannya. Pakej kegigihan menambah lapisan kekal kedua dengan mengambil syot set peraturan semasa dan memulihkannya semasa but, jadi permulaan seterusnya bermula dengan sekatan sudah terpasang.

Baca keadaan WFP sebelum memadam apa-apa

Windows menyertakan alat yang anda perlukan. Jalankan prompt pentadbir dan buang keadaan platform; longgokan itu muncul sebagai wfpstate.xml dalam direktori kerja.

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

Cari dalam XML nama vendor yang sudah pergi, tindakan Block, dan lapisannya. Penapis pada connect-redirect dan transport ialah yang merosakkan trafik biasa; penapis pada lapisan receive-accept biasanya bukan punca anda. Jika Base Filtering Engine langsung tidak berjalan, cari di tempat lain, kerana tiada apa lagi yang boleh menguatkuasakan penapis itu.

Semak silang paparan firewall biasa juga, kerana kebanyakan orang memeriksa hanya satu daripada dua:

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

Apabila profil terbina dalam dihidupkan dan tiada peraturan sepadan dengan trafik yang gagal, sekatan datang daripada penyedia pihak ketiga dan bukan daripada Windows Firewall. Perbezaan itu menentukan alat mana yang anda gunakan untuk pembaikan.

Baca peraturan Linux dalam sintaks yang anda akan padam

iptables -S mencetak peraturan dalam bentuk yang sama seperti semasa ia ditambah, jadi output boleh digunakan semula terus untuk pemadaman. iptables -L -v -n menambah pembilang paket, dan pembilang itu memberitahu sama ada peraturan benar-benar sepadan dengan permintaan anda yang gagal atau hanya duduk dalam rantai.

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

Baca dasar rantai, bukan hanya peraturan: -P OUTPUT DROP menyekat trafik walaupun tiada peraturan sepadan. Periksa IPv6 secara berasingan, kerana klien yang memasang kedua-dua keluarga boleh meninggalkan sekatan IPv6 selepas peraturan IPv4 hilang, dan gejala kemudian bergantung pada keluarga mana yang diutamakan aplikasi. Di tempat nftables digunakan, jalankan juga nft list ruleset; kedua-dua alat wujud bersama melalui lapisan keserasian, dan satu penyenaraian tidak semestinya menunjukkan setiap peraturan yang boleh menggugurkan paket.

Padam objek paling sempit yang menjelaskan kegagalan

Pada Windows langkah pertama masih laluan penyingkiran vendor sendiri: jalankan semula pemasang dan gunakan repair atau uninstall, atau jalankan alat pembersihan jika vendor menerbitkannya. Perkhidmatan dan tugas berjadual yang tertinggal adalah biasa, dan tugas yang memulakan klien semasa log masuk memasang semula penapisnya pada but seterusnya. Nyahpasang yang gagal semasa membaca kunci registri klien biasanya bermakna perkhidmatan atau tugas masih memegangnya, bukan bahawa registri rosak.

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

Penapis kekal ialah jalan terakhir. Ia berada di bawah HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, satu nilai bagi setiap penapis yang dikunci oleh GUID. Eksport kunci itu dahulu, catat GUID yang anda keluarkan, padam hanya nilai yang milik klien yang sudah pergi, kemudian but semula supaya enjin membina semula keadaannya. Jangan padam seluruh kunci dan jangan lumpuhkan Base Filtering Engine: Windows Firewall dan Defender bergantung padanya, dan anda akan menukar satu gangguan dengan yang lebih teruk.

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

Pada Linux, ambil baris yang dicetak oleh iptables -S dan gantikan -A dengan -D. Memadam satu peraturan yang anda kenal pasti lebih baik daripada mengosongkan rantai, kerana dasar anda sendiri kekal utuh.

sudo iptables -D OUTPUT -p udp -j REJECT

Jika drop berada dalam rantai yang ditakrifkan pengguna, padam lompatan ke rantai itu dahulu dan keluarkan rantai dengan -X selepas itu. Menetapkan dasar rantai kepada ACCEPT semasa peraturan drop masih ada hanya membantu paket yang benar-benar sampai ke keputusan dasar. Mengosongkan setiap jadual ialah jalan terakhir: ia juga mengeluarkan peraturan yang anda tambah atas sebab lain, dan dengan ufw dihidupkan ia meninggalkan perkhidmatan itu percaya ia memiliki rantai yang tidak lagi wujud.

Cari pemilik yang memasukkannya semula

Selepas pembaikan segera, cari apa sahaja yang akan memulihkan keadaan. Pada Linux, periksa sama ada unit kegigihan dihidupkan, sama ada klien mempunyai tetapan pulihkan firewall semasa log masuk, dan sama ada fail peraturan yang disimpan wujud di bawah /etc. Pada Windows, periksa semula entri permulaan, perkhidmatan dan tugas berjadual, kemudian but semula dan baca keadaan dengan arahan yang sama seperti sebelum ini.

Jika sekatan kembali, pemadaman bukan penyelesaiannya; pemiliknya. Catat klien atau perkhidmatan mana yang memasangnya dan lumpuhkan ciri itu di sana, bukannya bergelut dengannya di lapisan firewall selepas setiap putus.

Sahkan dengan trafik sebenar, bukan satu ping

Uji carian nama, sambungan TCP dan sesi pelayar baharu, kemudian but semula dan ulangi tiga semakan yang sama. Ping yang berfungsi sementara HTTPS gagal menunjuk kepada penapis lapisan transport dan bukan kepada rangkaian, dan sekatan yang muncul semula hanya selepas but semula menunjuk kepada pemilik yang belum anda temui.

Simpan bukti: kunci BFE yang dieksport, atau output iptables -S yang ditangkap sebelum perubahan. Sebelum menyebutnya selesai, sahkan lapisan tempat anda mengeluarkan objek, pemilik yang boleh memasangnya semula, keadaan selepas satu but semula yang bersih, dan bahawa pelayaran biasa berfungsi tanpa proses VPN berjalan. Halaman manual iptables(8) mempunyai sintaks pemadaman dan dasar yang tepat jika anda menulis pembersihan sebagai skrip.