Paket terpasang bersih, aturannya diuji, dan setelah reboot berikutnya gateway terbuka lebar. Tidak ada yang gagal dalam transaksi itu; kegagalannya ada pada anggapan tentang apa yang akan bertahan. Memasang perkakas firewall, memutuskan aturan mana yang harus bertahan, dan memulihkannya pada saat yang tepat adalah tiga pekerjaan terpisah.

Apa yang sebenarnya dikatakan gejala itu

Kumpulan aturan yang hilang saat reboot punya salah satu dari tiga pemilik: tidak ada yang menyimpannya, sesuatu yang lain menggantikannya, atau ia dipulihkan sebelum hal yang menjadi dependensinya ada. Dua yang pertama terlihat di konfigurasi; yang ketiga hanya muncul dalam urutan. Itulah sebabnya reboot bisa tampak seperti kehilangan data padahal sebenarnya masalah urutan.

Mulailah dengan menuliskan apa yang benar sebelum reboot: layanan mana yang memegang aturan, berkas atau basis data mana yang dibacanya saat mulai, dan apakah sumber itu pernah ditulis. Kumpulan aturan hidup yang tidak disimpan siapa pun adalah penjelasan yang sah dan yang paling umum.

Jangan mulai dengan memasang ulang paket.

Baca alat persistensi sebelum memakainya

Perkakas Debian memperlakukan persistensi sebagai masalah plugin: setiap plugin tahu cara menulis aturannya sendiri, dan satu pembungkus memanggilnya. Aksi simpannya menyimpan apa pun yang dimuat pada saat itu, dan aksi mulainya memuat kembali potret tersebut. Tidak ada yang meninjau apa yang disimpannya dalam kedua aksi itu.

Itu potret, bukan tinjauan. Izin sisa dari sesi pengawakutuan, eksperimen yang belum selesai, atau aturan longgar yang disisipkan perkakas lain semuanya menjadi permanen bersama kebijakan yang ingin Anda pertahankan. Menyimpan keadaan dan menyetujui keadaan adalah kegiatan berbeda, dan hanya satu yang menuntut pertimbangan. Baca dulu kumpulan yang dimuat, lalu putuskan baris mana yang layak bertahan.

Simpan dengan sengaja, setelah membaca apa yang dimuat.

Putuskan apa yang harus bertahan

Sebagian aturan milik siklus hidup antarmuka dan seharusnya hilang bersamanya. Yang lain harus bertahan lebih lama dari terowongan, dan contoh paling jelas adalah pembatasan yang melarang lalu lintas klien jatuh kembali ke antarmuka fisik ketika terowongan putus. Kedua kategori itu membutuhkan pemicu pemulihan yang berbeda, bukan satu potret bersama.

Tuliskan hasil yang dimaksud untuk tiga momen: boot, aktivasi VPN, dan kehilangan terowongan. Lalu periksa apakah alat yang Anda pilih dapat menyatakan masing-masing. Paket persistensi yang memuat ulang potret statis menangani yang pertama dan mungkin tidak menangani yang lain, karena potret tidak tahu kapan keadaan terowongan berubah. Jika tidak dapat menyatakannya, celahnya milik komponen lain.

Kebijakan, bukan paket, yang menentukan jawabannya.

Periksa urutan pemulihan

Memulihkan berkas tidak sama dengan memiliki hasilnya. Pengelola lain dapat mengganti aturan, izin sebelumnya dapat menaunginya, atau klien dapat mulai mengirim sebelum pembatasan berlaku. Tinjau perilaku saat mulai dan menyambung ulang, bukan hanya keberadaan berkas yang disimpan.

systemctl status netfilter-persistent
iptables -S

Jangan menganggap menghentikan layanan persistensi tidak berbahaya, karena paket mendokumentasikan pengosongan bersyarat saat berhenti. Pastikan konfigurasi sebenarnya layanan itu sebelum memakai berhenti atau mulai ulang sebagai eksperimen pada gateway yang Anda kelola dari jauh. Sesi konsol dan pengembalian yang terdokumentasi adalah minimum sebelum uji itu.

Urutan adalah sifat sistem yang berjalan, bukan berkas di cakram.

Terima tiga hasil terpisah

Catat pemasangan paket, kumpulan aturan yang dimuat, dan kebijakan yang ditegakkan sebagai fakta terpisah. Nama paket di utas dukungan hanya menjawab yang pertama, dan itulah yang jarang penting.

nft list ruleset

Lalu uji operasi yang diizinkan dan penolakan yang diwajibkan.

Jika penolakan bertahan setelah reboot dan setelah terowongan putus, kebijakan itu bertahan. Jika hanya bertahan pada salah satu keadaan itu, Anda telah menemukan masalah urutan alih-alih memperbaikinya.

Artikel terkait