Uji pemulihan server VPN setelah reboot: apa yang diperiksa lebih dulu

Reboot server tanpa ada yang masuk, lalu hubungkan dari jaringan yang tidak Anda kendalikan. Satu uji ini menjawab apakah pemulihan itu nyata, karena terowongan yang hanya berfungsi setelah seseorang menjalankan perintah secara manual bukan pemulihan, melainkan perbaikan. Sebagian besar pemeriksaan berhenti terlalu cepat: daemon tampak aktif, antarmuka muncul, dan halaman tetap tidak termuat. Kesenjangannya hampir selalu pada ketahanan bagian-bagian di sekitar terowongan, bukan pada perintah terowongannya sendiri.

Empat pemilik, empat uji berbeda

Sebelum restart, sebutkan apa yang seharusnya mengembalikan terowongan. Uji yang Anda jalankan dan perbaikan yang Anda terapkan keduanya bergantung pada jawaban itu, dan ada empat pemilik umum: unit systemd untuk daemon VPN, unit instans wg-quick untuk antarmuka WireGuard, runtime kontainer, atau profil manajer jaringan. Jika Anda tidak dapat menyebutkan pemiliknya, berhenti dan temukan, karena uji reboot tanpa jalur startup yang diharapkan hanya memberi tahu bahwa sesuatu terjadi.

Setiap pemilik menyimpan konfigurasinya di tempat berbeda. Server OpenVPN yang dikelola systemd membaca konfigurasinya saat mulai, jadi apa pun yang ada di berkas saat boot itulah yang berjalan. Antarmuka wg-quick memperoleh alamat, rute, dan DNS dari berkas yang sama, yang berarti antarmuka yang dinaikkan secara manual dari shell dan tidak pernah diaktifkan sebagai unit tidak akan kembali. Kontainer mengembalikan entrypoint-nya tetapi bukan perubahan firewall host, kecuali perubahan itu berada di luar kontainer.

Baseline dulu, kalau tidak hasilnya tidak berarti apa-apa

Catat keadaan yang berfungsi selama masih berfungsi: alamat pada terowongan, rute untuk subnet klien, aturan NAT atau penerusan, soket pendengar, dan sysctl penerusan. ip addr show wg0, ip route, nft list ruleset atau iptables-save, ss -lunp, dan sysctl net.ipv4.ip_forward cukup pada sebagian besar host.

Catat bagaimana layanan dikonfigurasi untuk mulai, bukan hanya bahwa ia berjalan. systemctl is-enabled wg-quick@wg0 dan systemctl is-active wg-quick@wg0 menjawab pertanyaan berbeda, dan status aktif-lah yang penting saat boot, seperti dijelaskan di systemctl(1). Untuk OpenVPN, periksa templat mana yang dipakai host, karena openvpn@server dan openvpn-server@server adalah unit berbeda dengan bawaan berbeda.

Jalankan restart dan baca kegagalan pertama

Reboot dengan sengaja, pada jendela yang Anda pilih, dengan konsol atau jalur out-of-band terbuka. Amati urutan peristiwa, bukan keadaan akhir: host dapat dijangkau, unit diaktifkan, antarmuka ada, rute terpasang, aturan firewall ada, pendengar terikat, klien diterima. Langkah pertama yang tidak terjadi itulah temuan; semua setelahnya hanya kebisingan.

Daemon bisa aktif sementara terowongan tidak dapat dipakai, dan itulah kelulusan palsu yang paling umum. Startup bisa selesai sebelum jaringan online jika unit hanya menunggu network.target alih-alih network-online.target. Berkas yang dirujuk seperti sertifikat, kunci, atau CRL bisa tidak terbaca pada saat itu karena mount atau jalur rahasia belum siap. Tidak satu pun masalah itu muncul di systemctl status sampai Anda membaca jurnal unit.

Uji dari luar host. Klien di LAN yang sama bisa berhasil melalui rute yang tidak akan pernah dipakai klien jarak jauh, dan sesi SSH ke mesin itu tidak membuktikan apa pun tentang terowongan. Hubungkan, selesaikan nama internal, capai sumber daya privat, lalu hubungkan sekali lagi untuk memastikan status pencabutan dan kunci masih berlaku.

Tiga kondisi yang menentukan perbaikan Anda

Jika terowongan kembali tetapi klien tidak mencapai apa pun, kegagalannya pada perutean atau ketahanan NAT. Jika klien bahkan tidak dapat menyelesaikan handshake, kegagalannya pada antarmuka atau materi autentikasi. Jika layanan tidak pernah mulai, kegagalannya pada berkas unit atau dependensinya. Ketiga cabang itu mengarah ke perbaikan berbeda, itulah sebabnya reboot buta tanpa baseline memakan lebih banyak waktu daripada yang dihemat.

Lakukan perbaikan di tempat pengaturan itu dimiliki. Letakkan penerusan di drop-in sysctl, letakkan aturan NAT di kumpulan aturan yang dimuat saat boot, aktifkan unit alih-alih memulainya, dan simpan rahasia pada jalur yang ada sebelum unit mulai. Menambahkan tidur ke unit menyembunyikan dependensi alih-alih menyatakannya.

Catat hasilnya di runbook

Tuliskan apa yang kembali sendiri, apa yang harus Anda mulai, dan berapa lama celahnya berlangsung. Sertakan perintah persis yang Anda pakai untuk memverifikasi, agar orang berikutnya mengulang uji itu alih-alih mengarang yang baru. Jika ada langkah yang memerlukan perintah manual, perintah itu milik konfigurasi, bukan runbook sebagai langkah permanen.

Lalu jadwalkan uji berikutnya untuk setelah perubahan berikutnya pada tumpukan jaringan host, bukan untuk tanggal kalender enam bulan ke depan. Mode kegagalan yang Anda cegah adalah perintah sementara yang terasa permanen, dan itu muncul tepat ketika seseorang menyunting aturan firewall atau memindahkan layanan ke unit baru.