Pembaruan server VPN tanpa pengawasan memerlukan jalur pemulihan yang teruji

Pembaruan tanpa pengawasan adalah kebijakan yang wajar untuk server yang Anda capai melalui VPN-nya sendiri, dan sekaligus menjadi satu titik kegagalan yang Anda buat sendiri. Operasi paket memulai ulang layanan, terowongan putus, dan jalur administratif yang Anda gunakan ikut hilang bersamanya. Ada dua model pemulihan, dan pilihan di antara keduanya bergantung pada satu syarat: apakah Anda memiliki jalur masuk yang tidak melewati hal yang sedang diperbarui.

Dua model pemulihan, satu syarat penentu

Model pertama memercayai pembaruan dan menganggap Anda dapat menyambung kembali sesudahnya. Model ini berhasil ketika VPN adalah salah satu dari beberapa cara mencapai host dan ketika kegagalan terowongan tidak menghilangkan kemampuan Anda mendiagnosisnya. Model kedua menempatkan lebih dahulu jalur independen, biasanya konsol penyedia hosting, dan memperlakukan terowongan sebagai hal yang paling mungkin dirusak oleh pemeliharaan. Kedua model dapat dipertahankan, dan hanya satu di antaranya memerlukan kerja lebih dahulu.

Syarat penentu itu mudah diucapkan dan mudah dilewati. Jika setiap jalur administratif ke mesin melewati layanan yang sedang diperbarui, Anda tidak punya model pemulihan sama sekali, hanya harapan. Katakan itu dengan lantang dalam tinjauan perubahan.

Menguji syarat itu memerlukan sepuluh menit dan harus terjadi sebelum pembaruan tanpa pengawasan pertama, bukan saat insiden. Buka konsol selagi semuanya berjalan, pastikan kredensial masih berlaku, lalu tutup kembali. Pastikan konsol terbuka pada host yang Anda maksud. Kemudian pastikan login yang benar-benar akan Anda gunakan pada pukul 3 pagi masih berfungsi.

Bagian terakhir itu lebih penting daripada kedengarannya. Akun konsol yang kata sandinya dirotasi enam bulan lalu dan tidak pernah diverifikasi bukanlah jalur pemulihan; itu dokumen yang menjelaskan jalur semacam itu.

Apa yang tidak dipulihkan cadangan

Arsip konfigurasi adalah catatan berkas, dan pembaruan mengubah lebih dari berkas. Status paket, modul kernel, tautan unit yang diaktifkan, dan aturan firewall yang diterapkan melalui alat terpisah semuanya hidup di luar direktori konfigurasi, dan pemulihan yang mengabaikannya menghasilkan mesin yang tampak terkonfigurasi dan tidak meneruskan.

Otorisasi layak mendapat barisnya sendiri. Cadangan yang diambil sebelum perangkat yang disusupi dihapus akan dengan senang hati memulihkan akses perangkat itu. Kembali ke sana saat gangguan adalah cara satu insiden menjadi dua, dan keputusan untuk memulihkan harus diambil tentang rekan sejawat sejelas tentang berkas.

Mekanisme pengembalian juga penting. Menyalin berkas eksekusi lama di atas berkas yang dikelola paket bukanlah pembalikan perubahan paket yang didukung, dan itu membiarkan basis data paket menjelaskan keadaan yang tidak cocok dengan sistem berkas. Gunakan jalur penurunan versi pengelola paket itu sendiri atau snapshot yang ditawarkan penyedia. Penurunan versi yang dicatat basis data paket adalah yang dapat Anda ulangi.

Tidak satu pun dari ini menentang cadangan. Ini mendukung mengetahui lapisan mana yang dicakup setiap artefak, karena cara kegagalan pemulihan sebagian lebih membingungkan daripada gangguan awal. Tuliskan lapisannya di samping setiap cadangan di runbook.

Titik pemeriksaan, pembaruan, lalu verifikasi dari luar

Catat keadaan sebelum perubahan dalam bentuk yang dapat Anda bandingkan nanti: versi yang terpasang, unit layanan yang terlibat, soket yang mendengarkan, dan daftar rekan sejawat saat ini. Empat perintah mencakup sebagian besar itu pada host Linux.

systemctl list-units --type=service | grep -E 'openvpn|wg-quick'
ss -lunp | grep -E ':51820|:1194'
journalctl -u wg-quick@wg0 --since '-10 min'

Yang pertama menunjukkan unit mana yang ada dan apakah berjalan, yang kedua memastikan pendengar benar-benar terikat, dan yang ketiga memberi Anda keterangan layanan itu sendiri tentang beberapa menit terakhir. Tidak satu pun membuktikan klien dapat tersambung, karena itu langkah berikutnya dilakukan dari luar host. Simpan pembacaan itu sebagai garis dasar perbandingan Anda.

Verifikasi dari jaringan yang tidak menggunakan terowongan: autentikasi satu klien yang diizinkan, selesaikan satu nama, dan capai satu aplikasi yang dimaksud. Baris status lokal yang menyatakan antarmuka aktif adalah pernyataan tentang antarmuka, bukan tentang perutean, kunci, atau kebijakan yang menerima rekan sejawat.

Lalu uji jalur penyambungan ulang dengan sengaja. Mulai ulang layanan satu kali dan pastikan terowongan kembali tanpa campur tangan manual, karena layanan yang hanya mulai dengan benar saat boot adalah layanan yang akan mengejutkan Anda pada saat terburuk.

Ketika gagal, gunakan jalur yang sudah Anda uji

Urutan pemulihan tidak glamour dan berhasil: capai host melalui jalur independen, baca log layanan itu sendiri, dan pulihkan titik pemeriksaan tertentu yang sesuai dengan kegagalan. Ubah satu hal per percobaan agar pembacaan log berikutnya berarti sesuatu.

Lawan dorongan untuk membuat beberapa perubahan tanpa catatan agar konektivitas kembali. Mesin yang diperbaiki dengan lima suntingan serentak tidak dapat dijelaskan sesudahnya, dan pembaruan berikutnya akan memasukkan kembali mana pun yang sebenarnya menanggung beban.

Lalu putuskan kebijakan permanen dengan bukti. Jika pembaruan menyingkap ketergantungan yang tidak didokumentasikan siapa pun, perbaikannya adalah dokumentasi dan pengujian, bukan mematikan pembaruan. Jika itu menyingkap layanan yang tidak dapat dimulai ulang dengan bersih, perbaikannya ada di unit, bukan di jadwal.

Perbandingan selesai dengan bersih begitu syaratnya diberi nama. Jalur independen menjadikan pembaruan tanpa pengawasan risiko yang dapat dikelola. Ketiadaannya menjadikan kebijakan yang sama gangguan terjadwal dengan waktu pemulihan tidak diketahui, dan tidak ada jumlah otomatisasi yang mengubah aritmetika itu.