Kill switch menyekat pelayan VPN sebelum sebarang trafik mengalir
Peringkat mana yang disekat kill switch: carian titik akhir, laluan luar, laluan pulang dan pengecualian rakan sebaya yang lapuk — dengan pembilang, bukan tekaan.
Kill switch gagal ke arah yang orang tidak jangkakan: ia dibina untuk menyekat trafik semasa terowong turun, dan paket yang membina terowong itu sendiri ialah trafik. Itulah keseluruhan pepijat. Set peraturan yang menggugurkan semua yang tidak keluar melalui terowong juga menggugurkan jabat tangan yang sepatutnya menaikkannya, jadi klien mencuba semula dalam gelung dan ralat itu dikaitkan dengan peringkat yang diperiksa dahulu. Sebelum meluaskan tembok api, ketahui peringkat mana antara tiga yang ditolak: carian nama, paket luar ke rakan sebaya, atau balasan yang kembali.
Bagaimana terowong dan pengangkutannya sendiri saling bergantung
Baca klien VPN sebagai dua keadaan rangkaian yang berkongsi satu laluan soket. Sebelum terowong wujud, klien membuka soket pada penyesuai fizikal dan menghantar bingkai tersulit ke alamat dan port rakan sebaya. Hanya selepas pertukaran itu berjaya ia mencipta peranti terowong dan memasang laluan. Kill switch ialah dasar tentang keadaan kedua, ditulis begitu luas sehingga terpakai pada kedua-duanya.
Peraturan berasaskan antara muka ialah bentuk biasa: terima apa yang keluar melalui tun0 atau wg0, gugurkan baki laluan keluar. Perumusan itu tidak boleh mengecualikan sambungan klien sendiri ke pelayan, jadi pelaksanaan yang betul menambah pengecualian itu secara jelas, dan anda juga apabila menulis peraturan dengan tangan. Peraturan setiap aplikasi pada Windows dan macOS mengelakkan sebahagian daripada ini dengan memadankan proses dan bukannya antara muka, tetapi proses itu masih perlu keluar sebelum terowong wujud.
Tiga peringkat, mengikut urutan ia berlaku
Peringkat pertama ialah penyelesaian. Apabila profil menyimpan nama hos dan bukannya alamat harfiah, klien memerlukan jawapan DNS sebelum boleh menghantar apa-apa. Profil yang menghala DNS ke penyelesai terowong mencipta kebuntuan: penyelesai hanya boleh dicapai melalui terowong yang carian itu sepatutnya dayakan. Menyelesaikan di luar terowong, atau memakukan titik akhir pada alamat, menghapuskan kekaburan itu.
Peringkat kedua ialah paket luar, yang mesti bertahan dahulu penghalaan dan kemudian tembok api, dalam urutan itu. wireguard-tools mengendalikan separuh penghalaan ini untuk WireGuard dengan menanda paketnya sendiri dan menambah peraturan dasar supaya ia melangkau laluan lalai yang baru dipasangnya; halaman manual wg-quick menerangkan peraturan itu dan jadual yang digunakannya. Bina semula penghalaan itu dengan tangan, atau biarkan alat kedua menulis semula peraturan, dan paket bertanda boleh dihantar kembali ke dalam terowong yang sepatutnya mereka bina.
Peringkat ketiga ialah laluan pulang. Jabat tangan tanpa jawapan bukan bukti pengguguran keluar; ia sama konsisten dengan peraturan masuk pelayan atau peranti NAT yang terlupa pemetaan. Asingkan itu 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 merekodkan gejala yang dikesannya, bukan peringkat yang gagal, jadi jadual biasanya lebih pantas daripada log.
Pembilang memutuskan lebih pantas daripada log
Pada Linux, nft list ruleset atau iptables -vnL OUTPUT mencetak pembilang paket bagi setiap peraturan. Sambung sekali, biarkan ia gagal, kemudian baca pembilang itu semula. Peraturan yang pembilangnya bergerak ialah peraturan yang dilanggar jabat tangan; jika tiada apa bergerak di mana-mana, paket itu tidak pernah sampai ke tembok api. Saya pernah melihat set peraturan menggugurkan jabat tangannya sendiri, dan hanya pembilang yang mengatakannya.
Untuk memisahkan tidak pernah sampai ke tembok api daripada tidak pernah meninggalkan hos, perhatikan antara muka itu sendiri. ip -s link show dev wlan0 melaporkan paket yang dihantar, dan tcpdump -ni wlan0 udp port 51820 menunjukkan bingkai. Jika ia kekal rata semasa klien mencuba semula, kerosakan berada di atas netfilter: laluan rakan sebaya yang hilang, peraturan dasar yang menunjuk ke peranti yang belum wujud, atau ralat soket yang ditelan klien.
Uji pengecualian terhadap alamat dokumentasi seperti 203.0.113.10, supaya kealpaan tidak dapat menyiasat hos orang lain.
Pengecualian titik akhir yang lapuk dibaca sebagai pelayan mati
Versi paling mengelirukan muncul selepas alamat rakan sebaya berubah: perkhidmatan alamat dinamik memindahkannya, hos dibina semula, atau alamat keluar rangkaian anda berbeza. Pengecualian itu masih menamakan alamat lama, jadi paket ke alamat baharu terkena peraturan pengguguran. Konfigurasi yang sama berfungsi semalam, dan itulah sebabnya orang mula menyiasat pelayan.
Nama hos di dalam peraturan tembok api tidak menyelamatkan anda. Dalam nftables nama itu diselesaikan apabila set peraturan dimuatkan, jadi ia memakukan alamat yang wujud pada saat itu dan menjadi lapuk seperti alamat harfiah. Pembetulan yang tahan lama ialah mengemas kini pengecualian apabila titik akhir berubah dan mengekalkannya sempit: satu alamat rakan sebaya, satu port pengangkutan. Julat yang cukup lebar untuk menahan perubahan alamat juga cukup lebar untuk melepaskan trafik tidak berkaitan.
Apabila kill switch berjalan pada hos pelayan
Kebergantungan yang sama wujud di hujung yang lain, dan di sana lebih mudah terlepas pandang. Jika mesin yang berperanan sebagai pelayan VPN anda juga menjalankan klien desktop dengan kill switch, atau profil tembok api yang disalin daripada komputer riba, peraturan penggugurannya terpakai pada perkhidmatan yang menamatkan terowong. Balasan kepada jabat tangan klien digugurkan, jadi setiap klien gagal menyambung sementara pelayan kelihatan sihat dan antara muka terowongnya duduk tanpa digunakan.
Hos itu memerlukan tiga penerimaan sempit sebelum pengguguran: port mendengar pada antara muka fizikal, antara muka terowong untuk trafik dinyahsulit, dan pemajuan dari terowong ke arah apa yang perlu dicapai klien. Baca set yang dipasang dengan nft list ruleset, iptables -S, atau pfctl -sr sebelum mengubah apa-apa, dan ingat bahawa set peraturan yang disimpan bertahan selepas but semula, jadi kesilapan di sana hidup lebih lama daripada proses yang membuatnya.
Urutan pemulihan yang memastikan mesin kekal tertutup
Bekerja dari profil ke luar. Baca alamat dan port rakan sebaya yang digunakan klien, sahkan bahawa nama hos diselesaikan tanpa terowong, kemudian tambah satu pengecualian untuk alamat dan port itu hanya pada penyesuai fizikal. Sambung semula dan perhatikan pembilang hantaran; jabat tangan yang selesai ialah isyarat bahawa peringkat kedua sudah dibaiki.
Biarkan baki dasar pengguguran di tempatnya semasa menguji. Pemeriksaan tidak berbahaya ialah cuba sambungan ke alamat dokumentasi tidak berkaitan dan sahkan ia masih tamat masa, yang menunjukkan kill switch berfungsi dan bukan dimatikan. Ketatkan pengecualian apabila terowong stabil, dan jangan tinggalkan kebenaran kekal untuk semua bagi program klien hanya kerana ia mudah.
Jika terowong naik dan aplikasi masih gagal, peringkat selebihnya bukan ini: DNS berpecah, MTU dan penghalaan setiap aplikasi masing-masing menghasilkan terowong bersambung dengan trafik rosak, dan masing-masing mempunyai pemeriksaan pertama yang berbeza.