Always-on VPN vs kill switch: mana yang sebenarnya Anda aktifkan?

Always-on dan kill switch hanya berjarak dua baris di layar pengaturan yang sama, jadi orang membacanya sebagai dua nama untuk satu fitur. Padahal bukan. Always-on adalah kebijakan sambung ulang: nyalakan tunnel saat boot, hidupkan kembali setelah crash atau perubahan jaringan, dan terus coba selama gagal. Kill switch adalah kebijakan lalu lintas: ia menyebut paket mana yang masih boleh meninggalkan mesin saat tunnel mati. Anda bisa mengaktifkan yang pertama tanpa yang kedua, dan di sebagian besar platform hasil bawaannya tetap meloloskan lalu lintas selama jeda itu.

Pemeriksaan 1: apakah blokirnya saklar tersendiri?

Di Android 10 dan versi setelahnya, profil VPN tersimpan membuka dua tombol independen di balik ikon roda gigi: Always-on VPN dan Block connections without VPN. Hanya yang kedua adalah kill switch. Dengan always-on saja, tunnel memang kembali setelah putus, dan aplikasi apa pun yang sedang dalam permintaan bisa mencapai jaringan lewat Wi-Fi atau data seluler sampai itu terjadi.

Perangkat terkelola mempertahankan pemisahan yang sama di API kebijakan. setAlwaysOnVpnPackage() menerima nama paket dan flag lockdownEnabled; administrator yang menyetel paket dan membiarkan flag itu false telah membangun tunnel yang menetap, bukan perangkat yang tertutup. Kata-kata di konsol jarang membuat perbedaan itu terlihat.

Baca statusnya dari perangkat, bukan dari konsol: adb shell settings get global always_on_vpn_app dan adb shell settings get global always_on_vpn_lockdown. Jika yang pertama mengembalikan null, tidak ada paket yang dipaksakan di tingkat platform; jika yang kedua mengembalikan 0, platform tidak memblokir apa pun. Panduan VPN Android mendokumentasikan keduanya sebagai kemampuan terpisah, bukan satu mode.

Pemeriksaan 2: lapisan mana yang memiliki blokirnya?

Label tinggal di klien dan blokir biasanya tinggal di firewall, itulah sebabnya kata yang sama berarti berbeda di tiap platform. Baris di bawah adalah yang layak dipastikan sebelum Anda memercayai salah satunya.

Windows adalah contoh paling jelas dari label yang tidak memblokir. Di sana Always On menggambarkan kegigihan tunnel: tunnel perangkat untuk autentikasi mesin, tunnel pengguna untuk akun yang masuk, dikonfigurasi lewat XML profil atau Add-VpnConnection. Tidak ada apa pun di profil itu yang menghentikan paket keluar saat tunnel tidak ada, dan penyaringan keluar tidak aktif secara bawaan, jadi laptop di Wi-Fi tetap berjalan saat VPN mati.

WireGuard terbelah dengan cara yang sama, tetapi per klien. WireGuard for Windows membawa opsi Block untunneled traffic per tunnel yang memasang aturan filter; perkakas Linux tidak punya saklar setara. wg-quick menambahkan rute untuk setiap entri AllowedIPs plus aturan fwmark, dan wg-quick down menghapus keduanya, sehingga rute default fisik mengambil alih lagi tanpa satu paket pun terbuang.

Di platform Apple, always-on hadir sebagai fitur profil manajemen untuk perangkat yang diawasi dan diungkapkan sebagai aturan on-demand, bukan kotak centang. Pertanyaan yang harus dijawab dari payload adalah apakah tunnel yang gagal menolak lalu lintas atau hanya meminta koneksi lain. Judul menu tidak akan memberi tahu Anda.

Pemeriksaan 3: ukur jedanya, bukan ikonnya

Empat transisi penting, dan semuanya gagal dengan cara berbeda: boot sebelum ada yang masuk, tidur dan bangun, perubahan dari Wi-Fi ke data seluler, dan crash klien yang meninggalkan antarmuka tunnel setengah terkonfigurasi. Sambung ulang yang bersih pada salah satunya tidak membuktikan apa pun tentang tiga lainnya.

Tes termurah sengaja menghentikan tunnel lalu mencoba keluar. Saat tunnel mati, curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com yang mengembalikan 200 berarti kebijakannya fail-open; timeout atau koneksi yang ditolak berarti masih ada sesuatu yang memblokir. ip route get 1.1.1.1 menyebut antarmuka yang akan membawa paket, yang biasanya lebih informatif daripada ikon baki, dan systemctl status wg-quick@wg0 menunjukkan apakah antarmuka dihapus dengan bersih.

Jalankan pemeriksaan yang sama di jendela kedua saat jaringan sedang berubah, bukan hanya setelahnya. Selang antara putus dan sambung ulang adalah bagian yang penting, dan pencarian nama adalah cara tercepat untuk menyadari lalu lintas lolos: jika resolver lokal menjawab saat tunnel mati, blokirnya tidak lengkap.

Pemeriksaan 4: putuskan pengecualian sebelum mengunci

Dua pengecualian bersifat struktural. Klien harus mencapai server VPN itu sendiri, jadi seperangkat aturan yang menjatuhkan semuanya juga mencegah sambung ulang yang akan memulihkan perlindungan. Captive portal juga tidak bisa dicapai lewat tunnel yang belum menyala, jadi perangkat terkunci di Wi-Fi hotel butuh cara terdokumentasi untuk membuka portal, bukan cara improvisasi.

Bentuk minimal, endpoint diizinkan dan sisanya dijatuhkan:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

Perlakukan baris endpoint itu sebagai variabel, bukan konstanta. Penyedia merotasi alamat, dan pengecualian yang basi adalah alasan biasa sebuah kill switch yang berfungsi berubah menjadi perangkat yang tidak bisa menyambung ulang. Printer lokal, berbagi NAS, dan layanan pengembangan termasuk dalam daftar tertulis yang sama, atau semuanya ditemukan satu tiket dukungan demi satu tiket.

Pemeriksaan 5: catat apa yang benar-benar Anda buktikan

Simpan tabel empat kolom dan isi dengan pengujian: status, perilaku yang diharapkan, perilaku yang diamati, bukti. Barisnya adalah transisi dari pemeriksaan 3 ditambah satu kegagalan yang disengaja. Baris yang tidak bisa Anda isi dengan keluaran perintah adalah baris yang belum diuji, dan perangkat yang lolos baris sambung ulang tetapi gagal di baris boot cukup umum sehingga sepuluh menit tambahan itu layak.

Sebelum menyebutnya selesai:

• Pastikan pengaturan pemblokiran terpisah dari pengaturan sambung ulang, dan baca nilainya di perangkat.
• Ketahui lapisan mana yang menegakkan blokir - opsi klien, kebijakan perangkat, atau firewall - dan di mana lapisan itu dikonfigurasi.
• Simpan satu perintah pemeriksaan yang membuktikan blokir, dan jalankan saat transisi, bukan sesudahnya.
• Tuliskan daftar pengecualian, termasuk endpoint, dan catat siapa yang menyegarkannya.
• Di perangkat keras terkelola, biarkan kebijakan yang ditegakkan; menghapus blokir mengubah persyaratan, bukan memperbaiki tunnel.