Cara mengembalikan konfigurasi pelayan VPN dengan selamat

Mengembalikan pelayan ialah keputusan tentang lapisan mana yang gagal, bukan latihan menyalin fail. Konfigurasi, kelayakan dan versi pakej bergerak pada jam yang berbeza, dan memulihkan satu sambil yang lain kekal terkini menghasilkan hos yang kelihatan sihat tetapi berkelakuan tidak konsisten. Urutan di bawah menganggap perubahan sudah gagal dan meminta anda memulihkan keadaan koheren terkecil. Laluinya mengikut urutan, dan anggap pemeriksaan akses luar jalur sebagai langkah yang tiada siapa patut langkau.

Ambil titik pemeriksaan yang benar-benar boleh anda pulihkan

Catat konfigurasi yang dibaca perkhidmatan semasa permulaan, bersama versi yang terakhir menghuraikannya. Fail yang dimuatkan bersih pada keluaran lama mungkin ditolak atau diabaikan secara senyap selepas peningkatan, jadi versi itu tergolong dalam nota yang sama. Sertakan bahan yang dirujuk konfigurasi: kunci peribadi, laluan sijil, definisi pendengar serta entri DNS dan tembok api yang menjadikan perkhidmatan boleh dicapai. Jika pemulihan memerlukan fail yang tidak anda simpan, titik pemeriksaan itu tidak lengkap.

Namakan pemilik setiap tetapan selagi sistem masih sihat. Laluan yang dipasang panel penyedia, laluan yang ditambah tembok api hos dan laluan yang ditolak ke klien ialah tiga objek berbeza, dan memulihkan yang salah membiarkan dua lagi di tempatnya. Jadual ringkas tetapan, pemilik dan laluan fail sudah memadai.

Asingkan pembatalan daripada konfigurasi

Konfigurasi lama boleh menyambung semula peranti yang anda buang dengan sengaja secara senyap, yang menjadikan pemulihan sebagai kemunduran keselamatan. Kekalkan senarai pembatalan semasa dan akaun dilumpuhkan semasa anda memulihkan dasar rangkaian, kemudian gunakannya semula sebelum perkhidmatan menerima klien.

Anggap keadaan identiti sebagai pengembalian tersendiri dengan buktinya sendiri. Fail pembatalan sijil, pelumpuhan akaun dan pendaftaran MFA jarang berada di tempat yang sama dengan konfigurasi daemon, dan pemulihan konfigurasi tidak akan menyentuhnya. Periksa keadaan semasa dahulu supaya anda tahu apa yang mesti kekal. Selepas pemulihan, sahkan identiti yang dibuang masih gagal menyambung.

Capai hos apabila terowong gagal

Buka laluan ke mesin yang tidak bergantung pada komponen yang sedang diubah. Konsol hipervisor, alamat pengurusan pada antara muka berasingan atau konsol bersiri semuanya layak; sesi SSH yang dibawa melalui terowong tidak. Jika satu-satunya jalan masuk ialah VPN yang akan anda mulakan semula, laluan atau peraturan tembok api yang salah menghilangkan keupayaan anda membetulkannya. Uji laluan alternatif sebelum perubahan, bukan selepasnya. Log masuk melaluinya sekali, sahkan sudo berfungsi dan catat alamat tepat yang anda gunakan.

Ujiannya mudah: turunkan terowong semasa anda bersambung melalui laluan alternatif dan lihat sama ada sesi bertahan. Jika ia terputus, anda telah menemui kegagalan sebelum ia boleh meninggalkan anda terkandas.

Gunakan satu semakan dan ketahui bila ia berkuat kuasa

Gunakan dokumentasi reload atau restart perkhidmatan dan ketahui arahan mana dibaca pada saat mana. Sesetengah nilai terpakai semasa reload, yang lain hanya apabila sesi atau proses baharu bermula, jadi menyunting fail tidak membuktikan apa-apa tentang keadaan yang berjalan. Pulihkan satu semakan dan bukan mencampur fail baharu dengan keadaan masa jalan lama. Jika ragu, memulakan semula perkhidmatan sepenuhnya lebih mudah difikirkan daripada reload separa.

Periksa definisi unit sebelum memilih: systemctl show -p ExecReload openvpn@server memberitahu anda sama ada cangkuk reload wujud. Kemudian gunakan semakan itu dan baca jurnal untuk ralat baharu pertama sebelum mengubah apa-apa lagi.

Sahkan, catat dan siasat selepas itu

Sambungkan satu klien yang dibenarkan dan uji tujuan perkhidmatan: penyelesaian nama, sambungan semula dan aplikasi yang gagal. Sahkan identiti yang dibatalkan masih ditolak. Catat semakan yang anda pulihkan, masa dan sebabnya, kerana pengendali seterusnya memerlukan ketiga-tiganya. Pengembalian yang tiada siapa dokumentasikan menjadi misteri pada kali seterusnya perkhidmatan berkelakuan buruk.

systemctl status openvpn@server --no-pager
journalctl -u openvpn@server -n 50 --no-pager

Setelah perkhidmatan stabil, hasilkan semula perubahan yang gagal pada hos atau syot kilat yang boleh anda buang. Itu memisahkan konfigurasi buruk daripada pakej buruk atau sijil luput. Simpan konfigurasi yang dipulihkan di bawah kawalan versi supaya titik pemeriksaan seterusnya bermula daripada commit yang diketahui. Inti pati latihan ini ialah titik akhir yang didokumenkan, bukan penurunan versi kekal.