Apakah kill switch VPN bertahan setelah reboot? Cara memverifikasinya

Reboot adalah cara paling umum orang menguji kill switch, dan itulah uji yang paling sering berbohong. Kotak centang di klien hanyalah preferensi; yang penting adalah apakah ada sesuatu yang memaksakan blokir antara saat tumpukan jaringan naik dan saat terowongan benar-benar terbentuk. Di Windows, sesuatu itu biasanya filter di Windows Filtering Platform, di Linux kumpulan aturan yang dimuat oleh unit, di macOS jangkar pf, di Android flag always-on dan kunci milik sistem itu sendiri. Susunan ini berperilaku sangat berbeda selama reboot, dan hanya yang berada di tingkat platform yang sudah ada sebelum siapa pun dapat masuk.

Reboot mengajukan tiga pertanyaan terpisah

Pisahkan pertanyaannya. Pertama, apakah kebijakan ada di disk dalam bentuk yang dibaca sesuatu saat boot? Kedua, apakah pembaca itu berjalan sebelum ada lalu lintas yang bisa keluar? Ketiga, apakah kebijakan mencakup lalu lintas yang Anda pedulikan, yaitu setiap proses, kedua keluarga alamat, dan DNS. Ya pada yang pertama dan tidak pada yang kedua menghasilkan persis kegagalan yang dilaporkan orang sebagai kill switch yang tidak bertahan setelah reboot: lalu lintas keluar selama beberapa detik saat boot, dan tidak ada yang menyadarinya sampai seseorang memeriksa.

Pisahkan lapisannya. Kumpulan aturan firewall yang disimpan, layanan yang mulai saat boot, dan preferensi klien adalah tiga objek berbeda dengan tiga masa hidup berbeda. Preferensi bertahan dari reboot karena merupakan nilai dalam berkas konfigurasi. Aturan adalah satu-satunya hal yang memblokir paket, dan aturan itu hilang bersama kernel yang menahannya.

Temukan objek yang memulihkan blokir

Di Linux, aturan netfilter hidup di kernel. Tidak ada yang menulisnya kembali saat boot kecuali Anda mengaturnya: iptables-save plus netfilter-persistent, nftables.service memuat /etc/nftables.conf, atau unit systemd yang menjalankan skrip Anda sendiri. Periksa apa yang diaktifkan, bukan apa yang Anda ingat telah dikonfigurasi.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

Kumpulan aturan kosong beberapa detik setelah boot adalah jawaban atas pertanyaan di judul. Di Windows, tanyakan kepada layanan klien bagaimana ia mulai, lalu buang status filter platform saat terowongan mati.

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

Perintah kedua menulis wfpstate.xml ke direktori saat ini. Cari filter dengan aksi blokir yang sudah ada sebelum klien terhubung. Base Filtering Engine mulai lebih awal saat boot dan memulihkan filter yang ditambahkan dengan flag persisten, itulah sebabnya sebagian kill switch memblokir lalu lintas sebelum ada jendela klien dan sebagian lagi tidak. Di macOS, sudo pfctl -s info melaporkan apakah pf diaktifkan, sudo pfctl -s rules menunjukkan apa yang dimuat, dan klien VPN biasanya melampirkan aturannya ke jangkar alih-alih ke kumpulan aturan utama. Aturan yang menyebut utun3 dapat menunjuk ke antarmuka lain setelah boot berikutnya, karena nomor itu diberikan saat runtime.

Amati celah antara jaringan naik dan terowongan naik

Interval berbahaya bukan seluruh reboot, melainkan celahnya. Antarmuka menerima sewa dan rute default pada satu titik, layanan VPN mulai pada titik lain, dan terowongan mengautentikasi lebih lambat lagi, kadang hanya setelah pengguna masuk dan agen kredensial berjalan. Jika blokir diterapkan terakhir, semua yang ada di celah itu keluar tanpa lindung.

Di host systemd, baca urutannya alih-alih menebaknya. Jalankan systemctl cat pada unit VPN dan firewall dan cari After= atau Before= terhadap network-pre.target dan network-online.target. Unit firewall yang diurutkan setelah network-online.target kalah dari antarmuka; yang diminta oleh dan diurutkan sebelum network-pre.target menang. Di Windows, pertanyaan setaranya adalah tipe mulai layanan dan dependensinya, karena layanan yang diatur ke Manual tidak dapat memblokir proses waktu boot. Jika kebutuhan Anda mencakup lalu lintas sebelum masuk, hanya susunan tingkat perangkat yang memenuhinya: terowongan perangkat Always On VPN mengautentikasi dengan sertifikat mesin dan terhubung sebelum pengguna masuk, dan Microsoft mendokumentasikan konfigurasi terowongan perangkat terpisah dari terowongan pengguna. Android menempuh jalur lain, memberlakukan VPN always-on dan memblokir koneksi tanpanya dari sistem dan bukan dari proses aplikasi.

Jalankan uji, lalu bandingkan dua garis waktu

Reboot dengan tujuan yang tidak memakan biaya jika bocor, dan tangkap keadaan selama celah, bukan sesudahnya. Metode paling bersih adalah probe waktu boot: unit oneshot atau tugas terjadwal yang mulai sedini yang diizinkan platform, mencatat rute default dan status firewall, mencoba satu permintaan dengan batas waktu singkat, dan menambahkan satu baris ke berkas lokal. Bandingkan catatan itu dengan waktu mulai layanan VPN dari journalctl -b -u atau log Sistem.

Lalu jalankan uji biasa: terowongan naik, putuskan koneksi, amati apakah lalu lintas langsung diblokir, pulihkan. Lulus yang kedua dan gagal yang pertama adalah hasil normal, dan itu berarti penegakan ada di sisi klien, diterapkan saat klien terhubung dan bukan saat boot. Pada mesin terakhir yang saya audit, blokir datang dari skrip dispatcher NetworkManager: ada dan benar dan tidak berguna untuk detik-detik sebelum antarmuka naik. Tuliskan kedua hasil, karena bertahan dari reboot baru bermakna ketika Anda menyebut lapisan mana yang bertahan dan sejak kapan.

Tutup celah tanpa memutus jalan pulang Anda

Jika blokir tidak ada saat boot, turunkan penegakan satu lapisan alih-alih menambahkan aturan klien kedua. Simpan kumpulan aturan dan muat dari unit yang diurutkan sebelum jaringan dapat digunakan, dan pastikan unit itu tidak memerlukan pencarian DNS atau mount jaringan yang seharusnya dilindunginya. Cakupan sama pentingnya dengan waktu: aturan yang cocok dengan ID pengguna atau cgroup membiarkan setiap daemon sistem di luar blokir, dan kumpulan aturan yang hanya menangani IPv4 membiarkan IPv6 dan DNS tetap terjangkau.

Sisakan jalan pulang untuk diri Anda. Mesin yang memblokir semuanya saat boot lalu tidak dapat mengautentikasi tidak punya jaringan sama sekali, dan perbaikannya bukan menghapus blokir melainkan memperbaiki kredensial atau urutannya. Pertahankan prosedur konsol lokal yang terdokumentasi dan pengecualian sempit yang disengaja untuk apa yang benar-benar dibutuhkan terowongan, seperti alamat server dan resolver yang dipakai sebelum terowongan ada.

Sebelum mempercayai susunan ini, pastikan empat hal secara berurutan. Kebijakan disimpan di tempat yang dibaca boot. Pembaca itu berjalan sebelum antarmuka dapat digunakan. Blokir mencakup kedua keluarga alamat dan DNS. VPN masih dapat mengautentikasi selama blokir aktif. Ketika keempatnya terpenuhi, reboot tidak mengubah apa pun.