Layanan OpenVPN berhenti saat meminta kata sandi kunci privat: cara memperbaikinya
Layanan tidak punya terminal, jadi kunci terenkripsi butuh askpass dan berkas yang bisa dibaca. Pisahkan frasa sandi kunci dari login server dan periksa unit.
OpenVPN meminta frasa sandi kunci privat di mesin lokal, jadi berkas login yang berfungsi tidak pernah menjawabnya. Pada layanan tidak ada terminal untuk mengetik, dan awal proses entah menggantung atau gagal dengan entri jurnal yang menyebut masukan, bukan penyebabnya. Ada dua rahasia yang terlibat, dan masing-masing butuh sumbernya sendiri yang bisa dibaca sebelum unit dijalankan ulang. Langkah di bawah memisahkan keduanya, lalu memeriksa identitas yang benar-benar membuka setiap berkas.
Bedakan dua permintaan itu
Frasa sandi kunci mendekripsi kunci privat lokal; kredensial akun mengautentikasi sesi ke server. Keduanya datang dari tempat berbeda, gagal pada saat berbeda, dan memberi pesan berbeda. Mencampuradukkannya membuat orang mencari reset kata sandi padahal akun tidak terlibat sama sekali. Bacalah teks permintaannya sebelum mengubah opsi apa pun, karena kata-katanya adalah satu-satunya petunjuk tepercaya tentang rahasia mana yang hilang.
Di Community OpenVPN 2.x, askpass menunjuk berkas yang menyimpan frasa sandi kunci pada baris pertama, dan auth-user-pass menunjuk berkas dengan nama pengguna di satu baris dan kata sandi di baris berikutnya. Tak satu pun berkas bisa memenuhi opsi lainnya. Aplikasi desktop atau profil NetworkManager dapat menyimpan keduanya di penyimpanan rahasianya sendiri, yang tidak pernah dibaca klien baris perintah, jadi catat klien mana yang sedang Anda konfigurasi sebelum menulis jalur apa pun.
Arahkan kedua opsi ke berkas yang bisa dibaca
Profil yang membutuhkan kedua masukan akhirnya punya tiga rujukan berkas: kunci terenkripsi, frasa sandi yang membukanya, dan pasangan login. Tambahkan tanpa menyentuh CA atau pemeriksaan identitas, karena keduanya menentukan siapa servernya dan bukan bagian dari masalah ini. Jika penerapan tidak memakai kredensial akun sama sekali, menambahkan auth-user-pass menciptakan masukan yang tak bisa disediakan siapa pun.
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authOpsi tanpa argumen berperilaku berbeda dari opsi dengan jalur, dan perbedaannya penting pada layanan. askpass tanpa argumen tetap membaca konsol, dan berkas auth-user-pass yang hanya berisi nama pengguna tetap menyisakan permintaan kata sandi menunggu. Begitu klien menjadi daemon, ia sama sekali tidak bisa meminta masukan dari terminal, jadi layanan yang dikonfigurasi begini tidak akan menyala.
Jalur absolut menghapus pertanyaan direktori kerja tetapi tidak memberi akses. Kepemilikan, mode, dan penelusuran menyusul, dan ketiganya diperiksa terhadap akun tempat proses berjalan.
Baca konfigurasi unit sebelum profil
Unit, bukan berkas yang Anda sunting, yang menentukan konfigurasi mana yang dimuat instans. Baca baris perintahnya dan setiap drop-in, lalu ikuti direktori kerja ke profil yang benar-benar dipakai. Rujukan frasa sandi yang ditambahkan ke berkas .ovpn lain tidak mengubah apa pun bagi instans ini.
Tiga perintah hanya-baca menjawab sebagian besarnya. Yang pertama mencetak unit dan setiap drop-in, yang kedua mencetak identitas dan pengaturan sandbox yang membatasi proses, dan yang ketiga mencetak apa yang sebenarnya dikeluhkan peluncuran terakhir. Gunakan nama instans yang ada di host:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bPerhatikan ProtectHome dan opsi milik profil sendiri user, group, dan chroot. Berkas di bawah direktori home bisa terbaca di shell Anda tetapi tak terlihat di dalam layanan setelah direktori home disembunyikan. Akun yang dipakai systemd untuk mulai tidak selalu akun yang akhirnya membuka kunci.
Buktikan identitas runtime bisa membuka kedua berkas
Membaca mode tidak cukup, karena setiap direktori di jalur harus bisa ditembus identitas yang sama. Telusuri jalur komponen demi komponen, lalu uji pembukaan sebagai akun yang dipakai proses. Berkas bermode 600 milik root hanya berfungsi selama proses masih root, yang tidak benar setelah penurunan hak istimewa yang dilakukan banyak profil. Dua perintah mencakup penelusuran dan pembukaan:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readablePerintah pertama mencetak mode setiap komponen dan gagal di tempat akun tidak bisa menembus; yang kedua menjawab satu-satunya pertanyaan penting, yaitu apakah identitas runtime bisa membuka berkas untuk dibaca. Keduanya tidak mencetak isi berkas, dan itulah intinya saat berkas menyimpan frasa sandi. Ulangi pengujian untuk berkas login, karena keduanya sering disimpan dengan kepemilikan berbeda.
Jika proses memakai chroot atau namespace terbatas, jalankan pengujian yang sama dari dalam tampilan itu, atau jawabannya menjelaskan sistem berkas yang salah. Frasa sandi yang disimpan di bawah direktori home tersembunyi adalah contoh biasa pengujian yang lolos di luar unit dan gagal di dalamnya.
Periksa peluncuran pertama, lalu penyambungan ulang
Jalankan instans sekali dan bacalah kegagalan pertama, bukan yang terakhir. Berkas masukan yang hilang, dekripsi kunci yang gagal, dan AUTH_FAILED dari server adalah tiga peristiwa berbeda dengan tiga perbaikan berbeda. Memperbaiki peringatan izin tidak membuktikan apa pun tentang apakah kunci sudah terbuka.
Baris jurnal memberi tahu yang mana dari ketiganya. Perbaikannya mengikuti masukan mana yang gagal:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
Lalu uji siklus hidup yang benar-benar Anda butuhkan: mulai saat boot dan setiap penyambungan ulang yang didukung, bukan hanya mulai manual dari shell Anda. Dengan auth-nocache masukannya dibuang setelah pemakaian pertama, jadi penyambungan ulang berikutnya tetap butuh sumber yang bisa dibaca. Keyring yang dibuka saat login desktop tidak tersedia bagi layanan yang mulai sebelum ada yang login, dan itulah alasan biasa sebuah uji manual lolos sementara reboot gagal. Jika peluncuran pertama berhasil dan penyambungan ulang berikutnya gagal, bacalah jurnal untuk peristiwa penyambungan ulang sebelum mengubah izin lagi.
Menyimpan frasa sandi di samping kunci mengurangi manfaat enkripsi, jadi batasi berkas itu dan cadangannya. Perlakukan penghapusan frasa sandi kunci sebagai keputusan kredensial tersendiri, bukan sebagai perbaikan masukan yang hilang. Penerapan yang bergantung pada persetujuan manusia atau MFA interaktif membutuhkan agen atau integrasi manajemen yang didukung; kode sekali pakai yang disimpan permanen bukan pengganti yang setara.