Cara mengunci jalur keluar Linux agar tidak ada yang bocor saat VPN putus

Bayangkan sebuah kotak media di koneksi rumah yang seharusnya hanya mencapai internet melalui terowongan. Saat terowongan putus, aplikasi seharusnya berhenti, bukan diam-diam melanjutkan lewat antarmuka fisik. Mendapatkan perilaku itu adalah masalah firewall, bukan masalah perutean, dan perbedaannya penting karena rute bisa diganti dengan memulai ulang daemon sementara filter tetap di tempat Anda menaruhnya. Berikut ini bagaimana jalur paket benar-benar memutuskan, lalu bagaimana membatasi pengecualian yang membuat terowongan bisa menyambung ulang.

Keluaran lokal adalah kait yang berbeda dari penerusan

Paket yang keluar dari aplikasi di mesin melewati kait keluaran; paket yang dirutekan mesin untuk host lain melewati penerusan. Kebijakan yang hanya menyebut forward membatasi yang kedua dan membiarkan yang pertama terbuka lebar, itulah sebabnya banyak kunci keluar tampak benar dan tidak melakukan apa pun. Pencocokan antarmuka termasuk dalam aturan yang sama: oifname "tun0" accept meloloskan lalu lintas yang sudah dirutekan keluar melalui terowongan. Perutean dan penyaringan juga tetap menjadi keputusan terpisah, sehingga rute uplink bisa ada sementara filter menolak paket. Pemisahan itulah yang Anda andalkan.

Gateway yang meneruskan untuk perangkat lain membutuhkan kedua kait. Mengunci keluaran saja melindungi mesin itu sendiri dan membiarkan setiap klien di hilir bebas bocor.

Tulis daftar pengecualian dari endpoint ke luar

Mulailah dari endpoint terowongan: satu alamat tujuan atau kumpulan kecil yang disetujui, protokol transport, dan port tujuan, misalnya udp dport 1194 ip daddr 203.0.113.7 accept. Jika klien me-resolve nama host, pertukaran DNS awal membutuhkan aturannya sendiri yang dibatasi pada resolver dan port 53, bukan izin menyeluruh ke alamat resolver itu. Setiap pengecualian sebaiknya menyebut alasan keberadaannya. Izin untuk semua lalu lintas UDP ke port VPN mencakup jauh lebih banyak daripada satu layanan terautentikasi yang Anda bayangkan.

Resolusi awal adalah tempat kunci biasanya membusuk. Kumpulan alamat yang diperbarui dengan pengatur waktu memerlukan perilaku yang jelas saat pembaruan gagal, dan perilaku itu tidak boleh membuka tautan sampai berhasil. Perbarui melalui terowongan selama terowongan hidup, dan jika tidak, kembali ke endpoint terakhir yang diketahui sehat.

Administrasi lokal membutuhkan perlakuan yang sama. Subnet manajemen tidak bisa dipercaya hanya karena alamatnya privat, dan aturan yang mempercayainya mengundang jalur kedua memutari kunci.

Pencocokan antarmuka bukan bukti terowongan yang sehat

Aturan yang menerima semua yang keluar dari tun0 mengasumsikan paket di antarmuka itu datang dari terowongan. Nama antarmuka dibuat ulang, dan nama bukan identitas kriptografis. Rekan sejawat juga bisa hilang sementara antarmuka tetap hidup, yang menjadikan aturan itu tanpa-efek yang sangat meyakinkan.

Pelacakan koneksi menambahkan jebakan terkait. Aturan luas untuk koneksi yang sudah terbentuk memutar ulang izin yang pernah didapat suatu aliran, sehingga sesi yang dimulai sebelum terowongan putus tetap berjalan setelahnya. Batasi penerimaan berbasis status pada antarmuka dan alamat yang benar-benar Anda maksud, atau Anda telah membangun kunci yang membuka dirinya sendiri. Aturan masukan dan keluaran juga menjawab pertanyaan berbeda, dan mengeraskan yang satu sambil mengabaikan yang lain membuat mesin tetap terjangkau dari arah yang tidak Anda pertimbangkan.

Apa yang bertahan saat daemon mengalami crash

Filter yang dipasang skrip yang berjalan setelah terowongan naik ikut hilang bersama terowongan, tepat pada saat filter itu dibutuhkan. Muat kunci saat boot dan biarkan daemon hanya mengelola pengecualiannya.

Menghapus rute default juga bukan pengganti. Rute adalah keadaan yang dimiliki dan ditulis ulang daemon, dan menghapusnya bisa mengambil jalur yang dibutuhkan untuk menyambung ulang. IPv6 memerlukan rencananya sendiri, karena penemuan tetangga dan pengumuman router adalah layanan tautan yang harus tetap berjalan saat lalu lintas biasa diblokir. DHCP termasuk kategori yang sama. Catat hal-hal ini sebagai pengecualian yang punya tujuan, bukan menemukannya kemudian sebagai gangguan.

Jalur pemulihan sebelum penerapan

Uji kunci seperti ia akan gagal: boot tanpa terowongan, matikan daemon, ubah endpoint, dan sambungkan ulang. Setiap kasus seharusnya menghentikan aplikasi dan membiarkan kanal pemulihan tetap bekerja. Lakukan dari konsol, karena shell jarak jauh adalah sesi yang paling mungkin terkunci oleh aturan Anda sendiri.

Lalu periksa apa yang masih bisa dijangkau aplikasi biasa, dengan tujuan yang tidak berbahaya dan permintaan yang bisa Anda verifikasi. Hasil yang Anda inginkan adalah penolakan di uplink dan keberhasilan lewat terowongan, bukan waktu tunggu ambigu yang bisa berarti keduanya. Pertahankan kumpulan aturan di bawah pemilik yang sama dengan sisa firewall, alih-alih mengganti seluruh tabel dari skrip shell. Kebijakan di mana setiap izin bisa membenarkan dirinya sendiri lebih bernilai daripada kumpulan aturan panjang yang tidak bisa dijelaskan siapa pun.