Kill Switch Masih Memblokir Lalu Lintas Setelah VPN Terputus

Tunnel sudah hilang, ikon jaringan tampak normal, dan tidak ada yang termuat. Anda memutus VPN, menghapusnya, atau mem-booting ulang, dan blokir yang seharusnya melindungi Anda saat koneksi drop masih berdiri. Jendela klien tidak bisa menjelaskannya, karena klien bukan yang memblokir Anda: keputusan itu ditulis ke dalam kernel atas nama Anda, dan tidak ada yang tertinggal untuk menghapusnya. Di Windows status itu berada di Windows Filtering Platform; di Linux itu adalah kumpulan aturan di iptables atau nftables, sering kali dengan snapshot yang diputar ulang saat boot. Berikut urutan yang saya gunakan: baca status, hapus objek paling sempit yang menjelaskan kegagalan, lalu temukan apa pun yang terus memasangnya kembali.

Kill switch adalah status kernel, bukan pengaturan

Klien desktop menerapkan pemblokiran dengan menambahkan filter yang menolak lalu lintas di luar tunnel. Di Windows itu adalah filter WFP pada lapisan connect-redirect dan transport, dan sebagian bersifat persisten: tercatat di penyimpanan kebijakan Base Filtering Engine dan dipulihkan saat mesin boot, sebelum perangkat lunak VPN apa pun berjalan. Klien berbeda dalam kapan mereka membersihkan. Sebagian menghapus filter saat terputus, sebagian hanya saat keluar bersih, dan sebagian hanya jika tombol kill-switch dimatikan lebih dulu. Hapus pemasangan saat blokir aktif, atau bunuh prosesnya, dan filternya tetap ada.

Padanan di Linux adalah aturan drop atau reject di jalur output, kadang aturan forwarding, kadang kebijakan chain yang diubah. Aturan itu hidup lebih lama daripada proses yang menambahkannya karena merupakan status kernel: bunuh kliennya, buat crash, atau putus dayanya, dan kernel tetap menjatuhkan paket tanpa apa pun yang tersisa untuk membatalkannya. Paket persistensi menambahkan lapisan permanen kedua dengan mengambil snapshot kumpulan aturan saat ini dan memulihkannya saat boot, sehingga mulai berikutnya dimulai dengan blokir yang sudah terpasang.

Baca status WFP sebelum menghapus apa pun

Windows menyertakan perkakas yang Anda butuhkan. Jalankan prompt dengan hak administrator dan buang status platform; hasilnya muncul sebagai wfpstate.xml di direktori kerja.

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

Telusuri XML untuk nama vendor yang sudah pergi, untuk aksi Block, dan untuk lapisannya. Filter pada connect-redirect dan transport adalah yang merusak lalu lintas biasa; filter pada lapisan receive-accept biasanya bukan penyebab Anda. Jika Base Filtering Engine sama sekali tidak berjalan, cari di tempat lain, karena tidak ada yang lain yang dapat menegakkan filter tersebut.

Periksa juga tampilan firewall biasa, karena kebanyakan orang hanya memeriksa salah satu dari keduanya:

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

Ketika profil bawaan aktif dan tidak ada aturan yang cocok dengan lalu lintas yang gagal, blokir berasal dari penyedia pihak ketiga, bukan dari Windows Firewall. Perbedaan itulah yang menentukan alat mana yang akan Anda gunakan untuk perbaikan.

Baca aturan Linux dalam sintaks yang akan Anda pakai untuk menghapus

iptables -S mencetak aturan dalam bentuk yang sama dengan saat ditambahkan, sehingga outputnya bisa langsung dipakai ulang untuk penghapusan. iptables -L -v -n menambahkan penghitung paket, dan penghitung itu memberi tahu apakah suatu aturan benar-benar cocok dengan permintaan Anda yang gagal atau hanya duduk di chain.

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

Baca kebijakan chain, bukan hanya aturannya: -P OUTPUT DROP memblokir lalu lintas bahkan ketika tidak ada aturan yang cocok. Periksa IPv6 secara terpisah, karena klien yang memasang kedua keluarga dapat meninggalkan blokir IPv6 di tempatnya setelah aturan IPv4 hilang, dan gejalanya lalu bergantung pada keluarga mana yang lebih dipilih aplikasi. Jika nftables digunakan, jalankan juga nft list ruleset; kedua alat itu hidup berdampingan lewat lapisan kompatibilitas, dan satu daftar belum tentu menunjukkan setiap aturan yang dapat menjatuhkan paket.

Hapus objek tersempit yang menjelaskan kegagalan

Di Windows langkah pertama tetap jalur penghapusan milik vendor: jalankan ulang pemasang dan gunakan repair atau uninstall, atau jalankan alat pembersih jika vendor menerbitkannya. Layanan dan tugas terjadwal sisa adalah hal umum, dan tugas yang menjalankan klien saat logon akan memasang ulang filternya pada boot berikutnya. Uninstall yang gagal saat membaca kunci registry klien biasanya berarti layanan atau tugas masih memegangnya, bukan bahwa registry rusak.

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

Filter persisten adalah jalan terakhir. Filter itu berada di bawah HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, satu nilai per filter yang dikunci oleh GUID. Ekspor kuncinya lebih dulu, catat GUID yang Anda hapus, hapus hanya nilai yang milik klien yang sudah pergi, lalu boot ulang agar mesin membangun ulang statusnya. Jangan hapus seluruh kunci dan jangan nonaktifkan Base Filtering Engine: Windows Firewall dan Defender bergantung padanya, dan Anda akan menukar satu gangguan dengan yang lebih buruk.

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

Di Linux, ambil baris yang dicetak oleh iptables -S dan ganti -A dengan -D. Menghapus satu aturan yang Anda identifikasi lebih baik daripada membuang seluruh isi chain, karena kebijakan Anda sendiri tetap utuh.

sudo iptables -D OUTPUT -p udp -j REJECT

Jika drop berada di chain yang ditentukan pengguna, hapus dulu lompatan ke chain itu dan hapus chain-nya dengan -X sesudahnya. Menetapkan kebijakan chain ke ACCEPT sementara aturan drop masih ada hanya membantu paket yang benar-benar sampai ke keputusan kebijakan. Membuang isi setiap tabel adalah jalan terakhir: itu juga menghapus aturan yang Anda tambahkan untuk alasan lain, dan dengan ufw aktif, layanan itu akan mengira memiliki chain yang sudah tidak ada.

Temukan pemilik yang memasangnya kembali

Setelah perbaikan langsung, cari apa pun yang akan memulihkan status. Di Linux, periksa apakah unit persistensi aktif, apakah klien punya pengaturan restore-firewall-at-login, dan apakah ada berkas aturan tersimpan di bawah /etc. Di Windows, periksa lagi entri startup, layanan, dan tugas terjadwal, lalu boot ulang dan baca status dengan perintah yang sama seperti sebelumnya.

Jika blokir kembali, penghapusan bukanlah perbaikannya; pemiliknya lah. Catat klien atau layanan mana yang memasangnya dan nonaktifkan fitur di sana, alih-alih melawannya di lapisan firewall setelah setiap pemutusan.

Verifikasi dengan lalu lintas nyata, bukan satu ping

Uji pencarian nama, koneksi TCP, dan sesi peramban baru, lalu boot ulang dan ulangi tiga pemeriksaan yang sama. Ping yang berhasil sementara HTTPS gagal menunjuk ke filter lapisan transport, bukan ke jaringan, dan blokir yang muncul lagi hanya setelah boot ulang menunjuk ke pemilik yang belum Anda temukan.

Simpan buktinya: kunci BFE yang diekspor, atau output iptables -S yang diambil sebelum perubahan. Sebelum menyebutnya beres, pastikan lapisan tempat Anda menghapus objek, pemilik yang bisa memasangnya kembali, status setelah satu boot ulang bersih, dan bahwa penjelajahan biasa berfungsi tanpa proses VPN berjalan. Halaman manual iptables(8) memuat sintaks hapus dan kebijakan yang tepat jika Anda menulis skrip pembersihan.