Runtime VPN di RAM tidak mengatakan apa pun tentang log

Server VPN yang boot dari image hanya-baca dan menyimpan status runtime-nya di tmpfs adalah desain nyata dan berguna. Desain itu juga mudah digambarkan sebagai tanpa log, yang tidak dibuktikan oleh desainnya. Lokasi penyimpanan menentukan tempat salinan hidup; pengumpulan dan retensi menentukan apakah catatan ada sama sekali, dan reboot hanya memengaruhi yang pertama. Memisahkan keduanya adalah seluruh tinjauan.

Mulailah dengan mendaftar setiap proses yang dapat menulis status: daemon, layanan autentikasi, jurnal, agen pemantauan apa pun, dan alat manajemen.

Penyimpanan dan pengumpulan adalah pertanyaan berbeda

Setiap penulis punya tujuan dan kebijakannya sendiri. Daemon VPN menulis berkas status, backend autentikasi menulis peristiwa akun, jurnal mengumpulkan keluaran layanan, dan agen pemantauan mengirim metrik ke tempat yang sama sekali lain. Desain yang membuat salah satunya menghilang saat reboot tidak mengatakan apa pun tentang tiga lainnya. Ikuti setiap penulis ke tujuannya dan catat apakah tujuan itu ada di mesin sama sekali.

Berkas khusus aplikasi, diagnostik yang diunggah, dan layanan eksternal memerlukan perlakuan yang sama. Tidak adanya log lokal yang dikenal tidak membuktikan bahwa catatan koneksi atau akun tidak ada di mana pun; itu membuktikan Anda belum menemukan ke mana perginya.

tmpfs bukan jaminan

Linux tmpfs bukan disk RAM fisik. Dokumentasi kernel menyatakan dengan jelas bahwa halaman dapat ditulis ke swap bila mount mengizinkannya, sehingga berkas tmpfs dapat mencapai disk tanpa aplikasi pernah menyalinnya ke sana. mount menunjukkan apakah tmpfs berbasis swap sedang dipakai, dan sistem berkas memori lain berperilaku lain lagi. Baca opsi mount yang sebenarnya alih-alih menganggap jalur di bawah /run berarti volatilitas.

Lalu inventarisasikan hal-hal yang bertahan melewati reboot dengan cara yang orang lupakan: lapisan atas persisten, penyimpanan terpasang, image hibernasi, dump crash, dan snapshot infrastruktur seluruh VM. Masing-masing adalah tujuan kandidat bagi status yang Anda kira sementara. Daftar itu adalah sesuatu untuk diperiksa, bukan klaim bahwa setiap host memiliki semuanya.

Journald punya dua tujuan dan satu penerus

Journald menggambarkan pemisahan itu dengan rapi. Penyimpanan volatil menyimpan entri di bawah /run/log/journal, penyimpanan persisten di bawah /var/log/journal, dan mode otomatis memilih di antara keduanya; mode yang berlaku berasal dari sistem yang berjalan, bukan dari deskripsi image. Beralih ke volatil tidak menghapus apa yang sudah ditulis secara persisten. Penerusan juga saluran terpisah: bahkan pengaturan penyimpanan yang tidak menyimpan apa pun secara lokal dapat menyerahkan pesan ke target lain.

Baca mode efektif dari jurnal itu sendiri atau berkas konfigurasinya, lalu periksa target penerusan secara terpisah, karena satu pengaturan tidak mengendalikan yang lain.

Apa yang harus bertahan melewati reboot

Runtime tanpa status mendukung penggantian berulang, dan memerlukan sumber yang disengaja untuk konfigurasi, otorisasi, dan materi pemulihan yang tidak dapat diciptakan layanan sendiri. Kehilangan satu-satunya status pendaftaran atau pencabutan yang berfungsi demi menghilangkan tulisan lokal adalah pertukaran buruk, dan umum. Putuskan apa yang harus bertahan dengan sengaja, lalu verifikasi bahwa itu bertahan.

Penalaran yang sama berlaku untuk catatan operasional. Putuskan peristiwa mana yang benar-benar dibutuhkan keamanan dan manajemen layanan, dengan cakupan dan retensi yang wajar, dan minimalkan sisanya. Meminimalkan bukan sama dengan menonaktifkan semua diagnostik.

Bandingkan konfigurasi penyimpanan dan penerusan yang efektif dengan beberapa peristiwa tak berbahaya, lalu reboot atau ganti mesin dan periksa lagi apa yang tersisa dan dari mana layanan memulihkan statusnya.