Kill switch memblokir server VPN sebelum ada lalu lintas yang mengalir
Tahap mana yang diblokir kill switch: pencarian titik akhir, rute luar, jalur pulang, dan pengecualian peer yang kedaluwarsa — dengan penghitung, bukan dugaan.
Kill switch gagal ke arah yang tidak orang duga: ia dibangun untuk memblokir lalu lintas saat terowongan mati, dan paket yang membangun terowongan itu sendiri adalah lalu lintas. Itulah seluruh bugnya. Sekumpulan aturan yang membuang semua yang tidak keluar lewat terowongan juga membuang jabat tangan yang seharusnya menaikkannya, jadi klien mencoba ulang dalam lingkaran dan galatnya jatuh ke tahap mana pun yang diperiksa lebih dulu. Sebelum melebarkan firewall, cari tahu tahap mana dari tiga yang ditolak: pencarian nama, paket luar ke peer, atau balasan yang kembali.
Bagaimana terowongan dan transportnya sendiri saling bergantung
Bacalah klien VPN sebagai dua keadaan jaringan yang berbagi satu jalur soket. Sebelum terowongan ada, klien membuka soket pada adaptor fisik dan mengirim bingkai terenkripsi ke alamat dan porta peer. Baru setelah pertukaran itu berhasil ia membuat perangkat terowongan dan memasang rute. Kill switch adalah kebijakan tentang keadaan kedua, ditulis begitu luas sehingga berlaku untuk keduanya.
Aturan berbasis antarmuka adalah bentuk yang lazim: terima apa yang keluar lewat tun0 atau wg0, buang sisa jalur keluarnya. Rumusan itu tidak dapat mengecualikan koneksi klien sendiri ke server, jadi implementasi yang benar menambahkan pengecualian itu secara eksplisit, dan Anda juga saat menulis aturan dengan tangan. Aturan per aplikasi di Windows dan macOS menghindari sebagian dari ini dengan mencocokkan proses alih-alih antarmuka, tetapi prosesnya tetap harus keluar sebelum terowongan ada.
Tiga tahap, dalam urutan terjadinya
Tahap pertama adalah resolusi. Ketika profil menyimpan nama host alih-alih alamat literal, klien membutuhkan jawaban DNS sebelum dapat mengirim apa pun. Profil yang mengarahkan DNS ke resolver terowongan menciptakan jalan buntu: resolver hanya dapat dijangkau melalui terowongan yang seharusnya diaktifkan oleh pencarian itu. Menyelesaikan di luar terowongan, atau memakukan titik akhir ke suatu alamat, menghapus kerancuan itu.
Tahap kedua adalah paket luar, yang harus bertahan dulu melewati perutean lalu firewall, dalam urutan itu. wireguard-tools menangani separuh perutean untuk WireGuard dengan menandai paketnya sendiri dan menambahkan aturan kebijakan agar melompati rute default yang baru saja dipasangnya; halaman manual wg-quick menjelaskan aturan itu dan tabel yang digunakannya. Bangun ulang perutean itu dengan tangan, atau biarkan alat kedua menulis ulang aturannya, dan paket bertanda bisa terkirim kembali ke terowongan yang seharusnya mereka bangun.
Tahap ketiga adalah jalur pulang. Jabat tangan tanpa jawaban bukan bukti pembuangan di sisi keluar; itu sama konsistennya dengan aturan masuk server atau perangkat NAT yang lupa pemetaannya. Pisahkan keduanya sebelum menyentuh klien.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
Klien mencatat gejala yang dideteksinya, bukan tahap yang gagal, jadi tabelnya biasanya lebih cepat daripada log.
Penghitung memutuskan lebih cepat daripada log
Di Linux, nft list ruleset atau iptables -vnL OUTPUT mencetak penghitung paket per aturan. Sambungkan sekali, biarkan gagal, lalu baca penghitungnya lagi. Aturan yang penghitungnya bergerak adalah aturan yang terkena jabat tangan; jika tidak ada yang bergerak di mana pun, paketnya tidak pernah mencapai firewall. Saya pernah melihat sekumpulan aturan membuang jabat tangannya sendiri, dan hanya penghitung yang mengatakannya.
Untuk memisahkan tidak pernah mencapai firewall dari tidak pernah meninggalkan host, amati antarmukanya sendiri. ip -s link show dev wlan0 melaporkan paket terkirim, dan tcpdump -ni wlan0 udp port 51820 menampilkan bingkainya. Jika tetap datar selagi klien mencoba ulang, kerusakannya di atas netfilter: rute peer yang hilang, aturan kebijakan yang menunjuk perangkat yang belum ada, atau galat soket yang ditelan klien.
Uji pengecualian terhadap alamat dokumentasi seperti 203.0.113.10, agar kekeliruan tidak dapat menyelidiki host orang lain.
Pengecualian titik akhir yang kedaluwarsa terbaca sebagai server mati
Versi paling menyesatkan muncul setelah alamat peer berubah: layanan alamat dinamis memindahkannya, host dibangun ulang, atau alamat keluar jaringan Anda berbeda. Pengecualiannya masih menyebut alamat lama, jadi paket ke alamat baru kena aturan pembuangan. Konfigurasi yang sama berfungsi kemarin, dan itulah sebabnya orang mulai menelusuri masalah di server.
Nama host di dalam aturan firewall tidak menyelamatkan Anda. Di nftables nama itu diselesaikan saat kumpulan aturan dimuat, jadi ia memakukan alamat yang ada saat itu dan menjadi kedaluwarsa seperti alamat literal. Perbaikan yang tahan lama adalah memperbarui pengecualian saat titik akhir berubah dan menjaganya sempit: satu alamat peer, satu porta transport. Rentang yang cukup lebar untuk bertahan dari perubahan alamat juga cukup lebar untuk melepas lalu lintas tak terkait.
Ketika kill switch berjalan di host server
Ketergantungan yang sama ada di ujung lain, dan di sana lebih mudah terlewat. Jika mesin yang bertugas sebagai server VPN Anda juga menjalankan klien desktop dengan kill switch, atau profil firewall yang disalin dari laptop, aturan pembuangannya berlaku pada layanan yang menamatkan terowongan. Balasan atas jabat tangan klien dibuang, jadi setiap klien gagal tersambung sementara server tampak sehat dan antarmuka terowongannya duduk tanpa dipakai.
Host itu memerlukan tiga penerimaan sempit sebelum pembuangan: porta dengar pada antarmuka fisik, antarmuka terowongan untuk lalu lintas yang didekripsi, dan penerusan dari terowongan menuju apa yang harus dicapai klien. Baca kumpulan yang terpasang dengan nft list ruleset, iptables -S, atau pfctl -sr sebelum mengubah apa pun, dan ingat bahwa kumpulan aturan yang disimpan bertahan dari reboot, jadi kesalahan di sana hidup lebih lama daripada proses yang membuatnya.
Urutan pemulihan yang menjaga mesin tetap tertutup
Bekerjalah dari profil ke luar. Baca alamat dan porta peer yang dipakai klien, pastikan nama host terselesaikan tanpa terowongan, lalu tambahkan satu pengecualian untuk alamat dan porta itu hanya pada adaptor fisik. Sambungkan lagi dan amati penghitung pengiriman; jabat tangan yang selesai adalah tanda bahwa tahap dua sudah diperbaiki.
Biarkan sisa kebijakan pembuangan tetap di tempatnya selama pengujian. Pemeriksaan yang tidak berbahaya adalah mencoba koneksi ke alamat dokumentasi tak terkait dan memastikan ia masih habis waktu, yang menunjukkan kill switch bekerja, bukan dimatikan. Perketat pengecualian begitu terowongan stabil, dan jangan tinggalkan izin permanen untuk semua bagi biner klien hanya karena praktis.
Jika terowongan naik dan aplikasi tetap gagal, tahap sisanya bukan yang ini: DNS terpisah, MTU, dan perutean per aplikasi masing-masing menghasilkan terowongan tersambung dengan lalu lintas rusak, dan masing-masing punya pemeriksaan pertama yang berbeda.