Skrip down atau aturan firewall: mana yang menghentikan kebocoran?

Dua rancangan menjanjikan hal yang sama: ketika terowongan putus, tidak ada yang keluar secara terbuka. Satu menjalankan skrip saat pembongkaran dan memotong antarmuka. Yang lain membiarkan aturan firewall berlaku dan tidak meminta apa pun dari klien VPN. Keduanya berbeda dalam siapa yang punya hak istimewa untuk bertindak, apa yang terjadi selama celah, dan bagaimana mesin kembali daring sesudahnya. Membandingkan keduanya pada tiga titik itu lebih berguna daripada berdebat mana yang lebih ketat.

Pekerjaan yang sama lewat dua mekanisme

Klien dapat menjalankan kait saat terowongan naik dan saat dibongkar, asalkan profil mengizinkan eksekusi skrip. Kait itu berjalan di dalam siklus hidup klien, pada saat koneksi menutup. Aturan firewall, sebaliknya, dimiliki sistem dan tidak peduli apakah klien berjalan, mogok, atau dibunuh.

Tabel itu adalah seluruh argumennya. Skrip yang hanya berjalan pada penutupan rapi mencakup kasus yang paling tidak Anda khawatirkan; kasus yang penting adalah mogok atau jaringan yang menghilang, dan keduanya tidak menghasilkan pembongkaran bersih.

Apa yang bisa dan tidak bisa dilakukan kait pembongkaran

Pola yang didokumentasikan menelusuri antarmuka jaringan dan menurunkan semua kecuali loopback. Dengan perangkat fisik turun, tidak ada yang bisa lolos ke luar terowongan, dan itulah maksudnya.

#!/bin/sh
for dev in /sys/class/net/*; do
  name=$(basename "$dev")
  [ "$name" = lo ] || ip link set dev "$name" down
done

Ini juga menurunkan jaringan lokal, layanan apa pun yang dihosting mesin, dan jalur yang akan Anda pakai untuk memperbaiki masalah. Di laptop perangkat nirkabel kadang perlu diaktifkan ulang secara manual sesudahnya, sehingga gangguan singkat menjadi sesi perbaikan. Lebih buruk lagi, kait itu mungkin tidak diizinkan melakukan semua itu: ketika klien melepaskan hak istimewa, skrip pembongkaran berjalan sebagai akun tanpa hak istimewa, dan setiap perubahan antarmuka gagal dengan galat izin yang ditulis pada saat tidak ada yang membaca log.

Periksa bagaimana klien dijalankan sebelum memercayai kait itu. Skrip yang bekerja saat dijalankan manual sebagai root tidak membuktikan apa pun tentang layanan yang mulai saat boot.

Apa yang dilakukan aturan firewall secara berbeda

Aturan yang hanya mengizinkan lalu lintas terowongan tetap bekerja ketika proses klien hilang, karena kernel tidak bergantung pada proses itu. Aturannya juga lebih sempit: ia memblokir tepat aliran yang cocok dan membiarkan loopback, subnet lokal, dan jalur pemulihan, itulah sebabnya ia tidak membuat mesin terdampar.

Harganya adalah aturan itu harus ditulis dan dipelihara oleh pemilik firewall host, dan aturan itu harus menyebut perangkat terowongan yang benar-benar dibuat klien. Artinya aturan dan profil harus dipelihara bersama; antarmuka yang diganti nama meninggalkan firewall yang memblokir semuanya dan tidak menjelaskan apa pun.

Tidak ada mekanisme yang membuat yang lain mubazir. Aturan firewall yang tidak pernah dimuat ulang setelah diedit sama fiktifnya dengan skrip yang tidak pernah berjalan.

persist-tun menentukan apakah ada celah

Ketika perangkat terowongan bertahan setelah terputus, rute yang menunjuk ke sana juga bertahan. Lalu lintas kemudian dibuang alih-alih dialihkan, sehingga rute default tidak jatuh kembali ke gateway fisik. Perilaku inilah yang membuat kebocoran kecil kemungkinannya bahkan sebelum aturan firewall mana pun terlibat.

Tanpa pengaturan itu, perangkat dihapus bersama rutenya, dan rute default bisa kembali menunjuk ke gateway fisik. Apakah itu terjadi bergantung pada platform dan klien, dan justru itu sebabnya keadaan harus diamati, bukan diasumsikan. Perlakukan pengaturan itu sebagai bagian dari kill switch, bukan opsi kinerja.

Jaga jalur penyambungan ulang tetap hidup, lalu uji empat keadaan

Pemblokiran ketat juga dapat mencegah klien menyambung ulang, karena klien masih perlu rute ke server melalui gateway fisik sementara semua yang lain ditolak. Pasang rute host untuk satu alamat itu sebelum terowongan naik, dan selesaikan nama lebih dulu, karena DNS mungkin sudah diblokir pada saat Anda membutuhkannya.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Lalu verifikasi keadaannya, bukan labelnya. Latih empat momen dengan sengaja: mulai dingin tanpa terowongan, sesi sehat, putus yang tidak diminta siapa pun, dan sesi setelah pulih. Di setiap momen baca rute default dan buat satu permintaan yang alamat keluarnya terlihat. Aplikasi yang menyerah saat terowongan turun tidak mengatakan apa pun tentang klien surel atau pembaru, jadi ulangi pemeriksaan terakhir dengan satu aplikasi latar belakang. Tuliskan aturan, nama antarmuka, dan langkah pemulihan, karena kill switch yang tidak dapat diverifikasi siapa pun hanyalah kabar burung.