Cara mengembalikan konfigurasi server VPN dengan aman
Pengembalian memulihkan kebijakan jaringan yang diketahui baik, bukan berkas tertua yang Anda temukan. Jaga daftar pencabutan tetap mutakhir dan jalur manajemen di luar terowongan.
Mengembalikan server adalah keputusan tentang lapisan mana yang gagal, bukan latihan menyalin berkas. Konfigurasi, kredensial, dan versi paket bergerak pada jam yang berbeda, dan memulihkan satu sementara yang lain tetap mutakhir menghasilkan host yang tampak sehat dan berperilaku tidak konsisten. Urutan di bawah mengasumsikan sebuah perubahan sudah gagal dan meminta Anda memulihkan keadaan koheren terkecil. Jalankan berurutan, dan perlakukan pemeriksaan akses di luar jalur sebagai langkah yang tidak boleh dilewati siapa pun.
Ambil titik pemeriksaan yang benar-benar dapat Anda pulihkan
Catat konfigurasi yang dibaca layanan saat mulai, bersama versi yang terakhir mengurainya. Berkas yang termuat bersih pada rilis lama bisa ditolak atau diabaikan diam-diam setelah peningkatan, jadi versi itu termasuk dalam catatan yang sama. Sertakan materi yang dirujuk konfigurasi: kunci privat, jalur sertifikat, definisi pendengar, serta entri DNS dan tembok api yang membuat layanan terjangkau. Jika pemulihan membutuhkan berkas yang tidak Anda simpan, titik pemeriksaan itu belum lengkap.
Sebutkan pemilik setiap pengaturan selagi sistem masih sehat. Rute yang dipasang panel penyedia, rute yang ditambahkan tembok api host, dan rute yang didorong ke klien adalah tiga objek berbeda, dan memulihkan yang salah membiarkan dua lainnya tetap ada. Tabel singkat berisi pengaturan, pemilik, dan jalur berkas sudah cukup.
Pisahkan pencabutan dari konfigurasi
Konfigurasi lama dapat menyambungkan kembali perangkat yang sengaja Anda hapus tanpa Anda sadari, yang mengubah pemulihan menjadi kemunduran keamanan. Pertahankan daftar pencabutan terkini dan akun nonaktif selagi Anda memulihkan kebijakan jaringan, lalu terapkan kembali sebelum layanan menerima klien.
Perlakukan keadaan identitas sebagai pengembalian tersendiri dengan buktinya sendiri. Berkas pencabutan sertifikat, penonaktifan akun, dan pendaftaran MFA jarang berada di tempat yang sama dengan konfigurasi daemon, dan pemulihan konfigurasi tidak akan menyentuhnya. Periksa keadaan saat ini lebih dulu agar Anda tahu apa yang harus bertahan. Setelah pemulihan, pastikan identitas yang dihapus masih gagal tersambung.
Jangkau host saat terowongan gagal
Buka jalur ke mesin yang tidak bergantung pada komponen yang sedang diubah. Konsol hipervisor, alamat manajemen pada antarmuka terpisah, atau konsol serial semuanya memenuhi syarat; sesi SSH yang dibawa melalui terowongan tidak. Jika satu-satunya jalan masuk adalah VPN yang hendak Anda mulai ulang, rute atau aturan tembok api yang buruk menghilangkan kemampuan Anda memperbaikinya. Uji jalur alternatif sebelum perubahan, bukan sesudahnya. Masuk melaluinya sekali, pastikan sudo bekerja, dan catat alamat tepat yang Anda pakai.
Ujinya sederhana: turunkan terowongan selagi Anda tersambung lewat jalur alternatif dan lihat apakah sesi bertahan. Jika putus, Anda telah menemukan kegagalan sebelum ia dapat membuat Anda terdampar.
Terapkan satu revisi dan ketahui kapan ia berlaku
Gunakan dokumentasi reload atau restart layanan, dan cari tahu direktif mana yang dibaca pada saat apa. Sebagian nilai berlaku saat reload, yang lain hanya ketika sesi atau proses baru dimulai, jadi menyunting berkas tidak membuktikan apa pun tentang keadaan yang berjalan. Pulihkan satu revisi alih-alih mencampur berkas baru dengan keadaan runtime lama. Jika ragu, memulai ulang layanan sepenuhnya lebih mudah dinalar daripada reload sebagian.
Periksa definisi unit sebelum memilih: systemctl show -p ExecReload openvpn@server memberi tahu Anda apakah kait reload benar-benar ada. Lalu terapkan revisi itu dan baca jurnal untuk kesalahan baru pertama sebelum mengubah apa pun lagi.
Verifikasi, catat, dan selidiki setelahnya
Hubungkan satu klien yang sah dan uji untuk apa layanan ini: resolusi nama, sambungan ulang, dan aplikasi yang gagal. Pastikan identitas yang dicabut masih ditolak. Catat revisi yang Anda pulihkan, waktu, dan alasannya, karena operator berikutnya membutuhkan ketiganya. Pengembalian yang tidak didokumentasikan siapa pun menjadi misteri saat layanan berperilaku buruk berikutnya.
systemctl status openvpn@server --no-pager
journalctl -u openvpn@server -n 50 --no-pager
Setelah layanan stabil, reproduksi perubahan yang gagal pada host atau snapshot yang dapat Anda buang. Itu memisahkan konfigurasi buruk dari paket buruk atau sertifikat kedaluwarsa. Simpan konfigurasi yang dipulihkan di bawah kendali versi agar titik pemeriksaan berikutnya mulai dari commit yang dikenal. Inti latihan ini adalah titik akhir yang terdokumentasi, bukan penurunan versi permanen.