OpenVPN tidak menemukan ca.crt meski profil berhasil dimuat
Jalur profil bukanlah dasar bagi berkas-berkas di dalamnya. Lihat mengapa --config absolut tetap gagal pada ca.crt dan bagaimana peluncuran menentukan jawabannya.
Layanan mulai berjalan, membaca profil tanpa keluhan, lalu mati pada baris yang tampak tidak berkaitan: ia tidak dapat membuka ca.crt. Tidak ada yang berubah pada sertifikat, dan jalur profil di berkas unit bersifat absolut. Kombinasi itulah petunjuknya. Jalur yang Anda berikan menunjuk satu berkas, sedangkan nama-nama di dalam berkas itu diselesaikan di tempat yang sama sekali lain, sehingga peluncuran yang tampak sepenuhnya memenuhi syarat masih bisa membaca kuncinya dari direktori yang tidak dimaksudkan siapa pun.
Kegagalan ini punya sedikit penyebab, dan sebaiknya dipisahkan menurut urutan: direktori dasar yang benar-benar dimiliki proses, konteks peluncuran layanan, serta izin atau sandbox di sekitar berkas setelah jalurnya benar. Masing-masing meninggalkan jejak berbeda — di unit, di proses, dan di sistem berkas.
Jalur profil bukan direktori dasar
Bayangkan proses yang mulai di /tmp dan diberi /etc/vpn/prod/tenant-a.ovpn. Di dalam profil itu, baris ca ca.crt menyebut jalur relatif. Tidak ada apa pun pada argumen yang menemukan profil itu yang menulis ulang nama tersebut, sehingga proses mencari /tmp/ca.crt dan melaporkan berkas yang hilang.
Yang membingungkan adalah urutan galatnya. OpenVPN mengurai konfigurasi lebih dahulu dan membuka berkas yang dirujuk saat mencapainya, sehingga salah ketik pada profil dilaporkan sebelum kunci mana pun disentuh, sedangkan sertifikat yang hilang baru muncul ketika penguraian sampai ke situ. Jadi profil yang berhasil dimuat adalah bukti sintaksnya benar, bukan bukti bahwa berkas yang disebutnya ditemukan.
Apa yang dipisahkan manual: --config dan --cd
Manual OpenVPN 2.6 menjelaskan dua opsi yang berbeda. Satu memuat berkas konfigurasi. Yang lain mengganti direktori proses sebelum konfigurasi, kunci, skrip, dan berkas lain dibaca, dan menuntut direktori absolut tanpa rujukan ke direktori saat ini.
openvpn --cd /etc/vpn/prod --config tenant-a.ovpn
Pemanggilan itu adalah bentuk, bukan perintah untuk meluncurkan profil orang lain. Yang diberikannya adalah determinisme: dasar bagi setiap nama relatif dalam rantai dinyatakan di perintah, bukan diwarisi dari shell atau manajer yang menjalankan proses. Alternatifnya sama sahnya dan sering lebih baik untuk layanan: biarkan direktori kerja apa adanya dan buat setiap berkas yang dirujuk menjadi absolut di dalam profil.
Apa pun pilihan Anda, audit seluruh rantai, bukan kegagalan pertama. Profil bisa menarik berkas konfigurasi lain, dan nama relatif berkas yang disertakan diselesaikan terhadap direktori proses yang sama, bukan terhadap direktori berkas yang menyertakannya. Jalur log, berkas autentikasi, dan skrip pembantu mengikuti aturan yang sama.
Layanan mulai di tempat lain
Shell interaktif di direktori profil tidak membuktikan apa pun tentang unit yang dipaketkan. Manajer menetapkan direktori kerjanya sendiri, dan skrip pembungkus bisa mengubahnya lagi sebelum biner dijalankan. Unit yang gagal adalah satu-satunya peluncuran yang layak ditelusuri.
systemctl show -p WorkingDirectory -p ExecStart --value openvpn@tenant-a
ls -l /proc/$(pgrep -n openvpn)/cwd
Perintah kedua menunjukkan direktori yang benar-benar dipegang proses yang hidup, dan itu lebih dapat dipercaya daripada berkas unit bila ada pembungkus. Jika keduanya tidak sepakat, pembungkus adalah jawaban Anda dan unit adalah jejak yang menyesatkan.
Setelah pencarian: izin, chroot, dan sandbox
Direktori dasar yang benar tetap bisa menghasilkan pesan yang sama, karena penyelesaian dan akses adalah langkah terpisah. Proses memerlukan izin eksekusi pada setiap direktori induk dan izin baca pada berkas, dan unit layanan yang menyembunyikan sebagian sistem berkas mengubah apa yang sama sekali bisa dilihat proses.
Tiga varian umum menghasilkan galat yang identik. Berkas hanya dapat dibaca root sementara layanan melepaskan hak istimewa sebelum membukanya. Unit menetapkan tampilan sistem berkas yang melindungi yang tidak mencakup direktori profil. Daemon berjalan dengan chroot, sehingga jalur yang ada di host tidak ada di dalam tampilan itu.
Diagnosis dengan kepemilikan berkas dan identitas proses, bukan dengan melonggarkan izin. Membuat kunci privat dapat dibaca semua orang untuk membungkam galat ini menukar kegagalan yang nyaring dengan yang senyap, dan kunci adalah bagian direktori yang paling tidak ingin Anda buka.
Buktikan perbaikannya dengan peluncuran milik Anda
Mulai ulang unit yang sebenarnya dari direktori yang tidak berkaitan dengan profil dan amati baris mulai yang sama. Lalu pastikan proses memegang direktori yang dimaksud selama berjalan, dan sertifikat yang dimuatnya adalah yang Anda harapkan.
systemctl restart openvpn@tenant-a
systemctl status openvpn@tenant-a --no-pager
journalctl -u openvpn@tenant-a -n 20 --no-pager
Ketika pemuatan jalur berhasil, autentikasi dan perutean tetap tahap terpisah dengan kegagalannya sendiri, dan koneksi yang menyala tetapi tidak melewatkan lalu lintas adalah penyelidikan lain. Perbaikan di sini hanya menyangkut dari direktori mana berkas-berkas itu berasal, dan itu seharusnya terlihat pada pemanggilan, bukan diingat oleh orang yang terakhir menjalankannya secara manual.
Jika profil disebarkan oleh manajer konfigurasi, letakkan direktori dasar atau nama berkas absolut di sana juga. Perbaikan manual pada satu host adalah versi masalah ini yang kembali setelah pembangunan ulang berikutnya.