Mengapa kill switch mematikan lalu lintas saat Anda mengganti server
Mengapa kill switch memblokir lalu lintas selama pergantian server, apa yang dilakukan klien di jendela itu, dan cara membedakan jeda normal dari blok yang macet.
Anda memilih server yang tampak lebih dekat, menekan sambungkan, dan peramban berhenti memuat sebelum terowongan baru siap. Ikonnya berubah ke status menyambung dan bertahan di sana sementara setiap tab kehabisan waktu. Jeda itu biasanya kill switch yang bekerja sesuai rancangan: lalu lintas diblokir selama klien belum punya terowongan untuk mengirimkannya. Apakah jeda itu wajar bergantung pada apa yang dilakukan klien dalam beberapa detik itu, dan pada apakah bloknya benar-benar dilepas saat ia mengatakannya.
Apa yang dilakukan klien di antara dua server
Pergantian titik akhir adalah beberapa langkah, bukan satu tombol. Klien membongkar terowongan saat ini, memperbarui aturan pemblokirannya, menyelesaikan dan menjangkau titik akhir baru di luar terowongan, lalu memasang rute baru dan mengangkat blok. Celah yang Anda rasakan berada di antara langkah pertama dan terakhir.
Urutan di sini lebih penting daripada kecepatan. Jika aturan pemblokiran masuk sebelum pengecualian untuk titik akhir baru, klien tidak bisa menyelesaikan handshake dan tetap di status menyambung sampai waktu habis. Jika pengecualian itu salinan dari alamat server lama, handshake baru tampak seperti paket keluar biasa dan dibuang. Kedua kasus tampak sama dari peramban, dan karena itulah pergantian yang pulih setelah enam detik dan yang tidak pernah pulih dapat berbagi penyebab yang sama.
Titik akhir baru butuh lubang di dalam blok
Untuk membangun terowongan, klien harus mengirim paket ke alamat dan port server baru lewat antarmuka fisik, misalnya UDP 51820 untuk profil WireGuard biasa atau 1194 dan 443 untuk OpenVPN, apa pun yang ditentukan profil Anda sendiri. Lalu lintas itu tidak berada di dalam terowongan yang baru akan dibuat, jadi blok untuk seluruh perangkat menelannya kecuali ada aturan izin yang cocok.
Profil berbasis nama host menambahkan syarat kedua: pencarian itu sendiri. Jika klien menyelesaikan titik akhir sebelum blok terangkat, ia bisa memakai alamat tersimpan di cache, tetapi begitu profil merotasi alamat atau entri cache menjadi basi, handshake menuju alamat yang tidak dicakup aturan izin. IPv6 membuatnya terlihat, karena titik akhir dua tumpukan dapat menerbitkan rekaman A dan AAAA sekaligus, dan aturan izin yang hanya mencakup alamat v4 membuat klien terus mencoba ulang ke alamat v6 yang diblokir.
Nama opsi dan nilai bakunya berbeda menurut klien dan versi, jadi bacalah daftar terdokumentasi untuk milik Anda daripada menebak dari tangkapan layar. Referensi pengaturan OpenVPN Connect di openvpn.net/connect-docs/app-settings-windows adalah salah satu contoh bagaimana sebuah klien menjelaskan opsi blok dan terowongan terbelahnya.
Fail-closed adalah mesin status, bukan tombol
Sebagian besar klien menyatakan blok itu sebagai kebijakan firewall dalam tiga keadaan: terowongan naik, dengan lalu lintas lewat terowongan dan tanpa blok; terowongan turun, dengan blok aktif; dan peralihan, dengan blok aktif plus pengecualian sementara untuk titik akhir. Di keadaan ketigalah bug bersarang, karena ia harus berubah dua kali dalam beberapa detik, dan gagal keluar darinya tampak persis seperti blok permanen.
Mekanismenya berbeda menurut platform, dan begitu pula kegagalannya. Filter Windows Filtering Platform memiliki bobot, jadi filter blok yang mengalahkan izin Anda terus membuang paket meski izinnya ada, dan filter yang ditinggalkan proses klien yang dimatikan dapat membuat mesin tetap luring setelah aplikasinya hilang. Klien macOS biasanya menulis aturan pf ke dalam anchor, tempat urutan aturan dan keputusan cepat menentukan aturan mana yang berlaku. Klien Linux umumnya mengelola rantai nftables atau iptables dengan kebijakan drop dan izin eksplisit untuk titik akhir, antarmuka terowongan, dan loopback. Mode selalu aktif Android dengan opsi memblokir koneksi tanpa VPN adalah yang paling ketat di kelompok ini, karena sistem operasi menerapkan blok itu untuk seluruh perangkat, bukan per aplikasi.
WireGuard perlu catatan sendiri, karena AllowedIPs adalah pemilih perutean, bukan pemblokir. Ia menentukan tujuan mana yang masuk terowongan; ia tidak melakukan apa pun untuk mencegah paket yang belum punya terowongan keluar lewat Wi-Fi. Dalam penyiapan hanya WireGuard tanpa aturan firewall, kill switch sebenarnya adalah ketiadaan rute, dan setelah handshake yang dibuang bisa menyusul paket nyata yang keluar lewat antarmuka fisik.
Ukur celahnya, bukan menonton ikonnya
Pantau paket, bukan lampu status. Di Linux, mulai ping lambat ke alamat publik di satu terminal dan tangkap port transport terowongan pada antarmuka fisik di terminal lain:
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
Ganti server di klien saat keduanya berjalan. Tiga hal penting: berapa lama ping berhenti, apakah tangkapan menunjukkan handshake mencapai titik akhir baru, dan apakah lalu lintas kembali sebelum atau sesudah status klien berubah menjadi tersambung. Jika celah ping berakhir lebih dulu, entah bloknya dilepas terlalu awal atau terowongannya sudah naik sebelum indikator mengakuinya. Jika celahnya berakhir lebih lambat, indikatornya terlalu optimistis.
Di Windows, netsh wfp show state menulis cuplikan yang bisa Anda cari filter blok yang masih ada sementara klien mengaku terputus. Di macOS, sudo pfctl -sr mendaftar aturan yang dimuat dan urutannya. Pasangkan salah satu cuplikan dengan log klien itu sendiri; garis waktu dari ping Anda memberi tahu apakah blok berakhir terlambat atau tidak pernah berakhir.
Gelap normal versus blok yang macet
Sebagian gangguan memang tujuan fiturnya, jadi lakukan triase sebelum mengubah pengaturan apa pun:
| What you see | Usually means | Next check |
|---|---|---|
| Two or three seconds of timeouts, then normal browsing | Expected fail-closed gap | Nothing to fix |
| State says connected, traffic stays dead | Block filter or route left behind | Firewall snapshot, client log |
| One app dead while others work | TCP session bound to the old exit address | Restart the app |
| LAN devices unreachable after the switch | LAN exception not reapplied | Allow-LAN or split-tunnel setting |
| New server hangs, the old one reconnects | Permit covers only the old address | Resolved address of the new host, including AAAA |
Jika Anda mendarat di baris kedua atau kelima, jangan matikan kill switch untuk menguji, karena itu mengubah bug perutean menjadi kebocoran. Mulai ulang layanan klien, atau boot ulang mesin di tempat filter bertahan setelah proses dimatikan, lalu lihat apakah bloknya hilang. Jika hilang, kesalahannya ada pada pembersihan saat pergantian, bukan pada bloknya.
Sebelum pergantian berikutnya, pastikan empat hal: izin titik akhir mencakup setiap keluarga alamat yang diselesaikan profil Anda, log klien menunjukkan peralihan selesai, uji ping Anda mengukur celahnya bukan ikonnya, dan menutup klien memulihkan konektivitas normal. Kill switch yang bertahan selama pergantian dan melepas sesudahnya menjalankan tugasnya. Yang melepas terlalu awal, atau tidak pernah, layak di-debug.