OpenVPN tidak menemui ca.crt walaupun profil dimuatkan

Perkhidmatan bermula, membaca profil tanpa aduan dan kemudian mati pada baris yang kelihatan tidak berkaitan: ia tidak dapat membuka ca.crt. Tiada apa-apa pada sijil berubah, dan laluan profil dalam fail unit adalah mutlak. Gabungan itulah petunjuknya. Laluan yang anda berikan menempatkan satu fail, dan nama di dalam fail itu diselesaikan di tempat lain sama sekali, jadi pelancaran yang kelihatan layak sepenuhnya masih boleh membaca kuncinya dari direktori yang tiada siapa niatkan.

Kegagalan ini mempunyai beberapa punca, dan wajar dipisahkan mengikut urutan: direktori asas yang sebenarnya dimiliki proses, konteks pelancaran perkhidmatan, serta kebenaran atau sandbox di sekeliling fail apabila laluan sudah betul. Setiap satu meninggalkan jejak berbeza — dalam unit, dalam proses dan pada sistem fail.

Laluan profil bukan direktori asas

Bayangkan proses yang bermula di /tmp dan diberi /etc/vpn/prod/tenant-a.ovpn. Di dalam profil itu, baris ca ca.crt menamakan laluan relatif. Tiada apa-apa pada argumen yang menemui profil itu menulis semula nama tersebut, jadi proses mencari /tmp/ca.crt dan melaporkan fail yang hilang.

Yang mengelirukan ialah urutan ralat. OpenVPN menghuraikan konfigurasi terlebih dahulu dan membuka fail yang dirujuk apabila mencapainya, jadi salah taip dalam profil dilaporkan sebelum sebarang kunci disentuh, manakala sijil yang hilang hanya muncul apabila penghuraian sampai ke situ. Oleh itu profil yang dimuatkan ialah bukti sintaksnya betul, bukan bukti fail yang dinamakannya ditemui.

Apa yang manual pisahkan: --config dan --cd

Manual OpenVPN 2.6 menerangkan dua pilihan berbeza. Satu memuatkan fail konfigurasi. Satu lagi menukar direktori proses sebelum konfigurasi, kunci, skrip dan fail lain dibaca, dan memerlukan direktori mutlak tanpa rujukan kepada yang semasa.

openvpn --cd /etc/vpn/prod --config tenant-a.ovpn

Seruan itu ialah satu bentuk, bukan arahan untuk melancarkan profil orang lain. Apa yang diberikannya ialah keazaman: asas bagi setiap nama relatif dalam rantaian dinyatakan dalam arahan dan bukan diwarisi daripada mana-mana shell atau pengurus yang memulakan proses. Alternatifnya sama sah dan selalunya lebih baik untuk perkhidmatan: biarkan direktori kerja dan jadikan setiap fail yang dirujuk mutlak di dalam profil.

Apa pun pilihan anda, audit seluruh rantaian dan bukan kegagalan pertama. Profil boleh menarik masuk fail konfigurasi lain, dan nama relatif fail yang disertakan diselesaikan terhadap direktori proses yang sama, bukan direktori fail yang menyertakannya. Laluan log, fail pengesahan dan skrip pembantu mengikut peraturan yang sama.

Perkhidmatan bermula di tempat lain

Shell interaktif dalam direktori profil tidak membuktikan apa-apa tentang unit yang dipakejkan. Pengurus menetapkan direktori kerja mereka sendiri, dan skrip pembalut mungkin mengubahnya semula sebelum binari dijalankan. Unit yang gagal ialah satu-satunya pelancaran yang wajar difikirkan.

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 hidup, dan itu lebih boleh dipercayai daripada fail unit apabila pembalut terlibat. Jika kedua-duanya tidak sependapat, pembalut ialah jawapan anda dan unit ialah jejak yang mengelirukan.

Selepas pencarian: kebenaran, chroot dan sandbox

Direktori asas yang betul masih boleh menghasilkan mesej yang sama, kerana penyelesaian dan akses ialah langkah berasingan. Proses memerlukan kebenaran laksana pada setiap direktori induk dan kebenaran baca pada fail, dan unit perkhidmatan yang menyembunyikan sebahagian sistem fail mengubah apa yang boleh dilihat proses itu.

Tiga variasi biasa menghasilkan ralat yang sama. Fail hanya boleh dibaca oleh root manakala perkhidmatan melepaskan keistimewaan sebelum membukanya. Unit menetapkan pandangan sistem fail yang melindungi yang tidak merangkumi direktori profil. Daemon berjalan dengan chroot, jadi laluan yang wujud pada hos tidak wujud dalam pandangan itu.

Diagnosis dengan pemilikan fail dan identiti proses, bukan dengan melonggarkan kebenaran. Menjadikan kunci persendirian boleh dibaca semua orang untuk mendiamkan ralat ini menukar kegagalan yang nyaring dengan yang senyap, dan kunci ialah bahagian direktori yang paling kurang ingin anda dedahkan.

Buktikan pembetulan dengan pelancaran milik anda

Mulakan semula unit sebenar dari direktori yang tidak berkaitan dengan profil dan perhatikan baris permulaan yang sama. Kemudian sahkan proses memegang direktori yang dimaksudkan semasa berjalan, dan sijil yang dimuatkan ialah yang anda jangkakan.

systemctl restart openvpn@tenant-a
systemctl status openvpn@tenant-a --no-pager
journalctl -u openvpn@tenant-a -n 20 --no-pager

Apabila pemuatan laluan berjaya, pengesahan dan penghalaan masih peringkat berasingan dengan kegagalan masing-masing, dan sambungan yang naik tetapi tidak melepasi trafik ialah siasatan lain. Pembetulan di sini hanya tentang dari direktori mana fail itu datang, dan ia sepatutnya kelihatan dalam seruan dan bukan diingati oleh orang yang terakhir menjalankannya secara manual.

Jika profil itu digunakan oleh pengurus konfigurasi, letakkan direktori asas atau nama fail mutlak di sana juga. Pembetulan manual pada satu hos ialah versi masalah ini yang kembali selepas pembinaan semula seterusnya.