openvpn3 session-start mengabaikan berkas kredensial Anda
Klien 3.x mengambil kredensial saat sesi dimulai dan tidak akan membaca berkas tersimpan. Gunakan prompt atau jalur autoload, dan pahami apa yang disimpan masing-masing.
Hubungkan dengan klien 2.x dan profilnya langsung berfungsi; serahkan berkas yang sama ke klien 3.x dan prosesnya berhenti di prompt kata sandi. Serahkan --auth-user-pass creds.txt ke openvpn3 session-start dan hasilnya sama, karena klien yang lebih baru tidak punya tahap yang membaca berkas itu. Penolakan ini disengaja: kredensial adalah milik sebuah sesi, dan sesi dibuat oleh layanan, bukan oleh proses di terminal Anda. Pilih antara prompt interaktif dan pembantu autoload, lalu pahami apa yang disimpan masing-masing.
Mengapa berkas tersimpan tidak punya tempat tujuan
Dalam desain yang lebih baru, manajemen konfigurasi dan manajemen sesi adalah layanan terpisah yang berbicara melalui bus sistem. Pemisahan itulah yang memungkinkan pengguna biasa memulai sesi tanpa daemon berhak istimewa membaca berkas kata sandi yang dilindungi atas nama mereka. Kredensial berbasis berkas tidak punya tempat dalam model itu, karena tidak ada proses mulai di sisi daemon yang akan membacanya. Penolakan ini adalah konsekuensi arsitektur, bukan fitur yang hilang.
Pola lama perlu disebut agar lebih mudah ditinggalkan: profil merujuk berkas kredensial, dan daemon membacanya saat terowongan dimulai. Dalam model baru, kredensial milik sesi dan diberikan saat sesi itu dimulai. openvpn3 session-start --config work.ovpn akan meminta kredensial tersebut, dan --auth-user-pass creds.txt ditolak karena tidak ada apa pun di jalur itu yang akan membuka berkas. Setiap resep 2.x yang Anda temukan mengasumsikan tahap yang sudah tidak ada.
Konfigurasi dan pengaturan lokal situs juga dipisahkan, yang menjelaskan kejutan kedua. Sebuah profil bisa tampak lengkap padahal koneksi yang dihasilkannya tidak memiliki konfigurasi perutean dan resolver. Bagian-bagian itu diterapkan sebagai pengaturan lokal situs, terpisah dari berkas yang diimpor.
Jalur prompt dan sesi yang ditinggalkannya
Memberikan kata sandi saat sesi dimulai adalah alur kerja yang dimaksud. Klien meminta sekali, menyerahkan kredensial ke backend sesi, lalu melanjutkan:
openvpn3 session-start --config work.ovpn
openvpn3 sessions-list
Tidak ada yang ditulis ke disk melalui jalur itu. Sesi juga tetap berjalan setelah terminal ditutup, yang mengejutkan orang yang mengira prosesnya akan mati bersama shell mereka. Itulah inti memindahkan penanganan sesi ke dalam layanan. Sesi hidup lebih lama daripada terminal yang memintanya, dan sesi harus dihentikan secara eksplisit.
Untuk workstation dengan manusia di depannya, ini juga opsi teraman, karena tidak ada rahasia tersimpan yang perlu dilindungi atau dilupakan. Opsi ini tidak cocok hanya jika tidak ada orang yang hadir untuk mengetik.
Otomasi tanpa orang di depan papan ketik
Jika sebuah mesin harus terhubung tanpa kehadiran orang, proyek menyediakan openvpn3-autoload. Alat ini membaca direktori profil dan deskriptor yang cocok untuk tiap profil, dan deskriptor memasok kredensial dalam teks biasa. Pembantu ini adalah biner terpisah, biasanya di /usr/sbin/openvpn3-autoload, bukan sebuah flag pada session-start. Menyiapkannya berarti membuat direktori, menyalin profil dengan nama yang diharapkan deskriptor, dan menulis deskriptor.
Penyiapan per pengguna terlihat seperti ini, dijalankan sebagai akun yang akan memiliki sesi. Mode direktori menjaga pengguna lokal lain tetap di luar:
mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload
Deskriptor menamai kredensial dan meminta mulai otomatis. Jauhkan nilai kata sandi dari kontrol versi:
{
"autostart": true,
"user-auth": {
"autologin": true,
"username": "svc-vpn",
"password": "change-this-value"
}
}
Lalu panggil pembantu itu sekali dan pastikan sesinya muncul. Perintah kedua adalah pemeriksaan, bukan langkah penyiapan lain:
/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list
Saat boot, unit terpaket bernama openvpn3-autoload.service memakai direktori seluruh sistem /etc/openvpn3/autoload, bukan direktori per pengguna. Lokasi itu membutuhkan kepemilikan root dan mode yang lebih ketat, dan deskriptornya masih menyimpan kata sandi dalam teks jelas. Komprominya jelas: kata sandi kini berada di disk, jadi perlakukan direktori itu sebagai rahasia, kecualikan dari cadangan di luar host, dan pilih jalur interaktif setiap kali ada orang yang hadir.
Kegagalan bus yang tampak seperti kegagalan kata sandi
Sebagian kegagalan yang dikaitkan dengan kredensial sama sekali bukan itu. Kesalahan izin yang menyebut jalur aktivasi layanan berarti salah satu dari dua hal: backend tidak berjalan, atau pemanggil tidak punya izin untuk mengaktifkannya. Tidak ada penyuntingan profil yang akan mengubah keduanya. Periksa status layanan dan kebijakan bus yang disertakan sebelum Anda menyentuh konfigurasi.
Perintah di bawah ini memisahkan keduanya. Yang pertama melaporkan apakah backend berjalan; yang kedua menampilkan kesalahan bus terbaru:
systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20
Salah baca lain yang sering terjadi adalah sesi yang muncul lalu langsung hilang. Pola itu biasanya berarti pengaturan lokal situs tidak pernah diterapkan, sehingga terowongan naik tanpa perubahan rute dan resolver yang membuatnya berguna. Bacalah urutannya, bukan baris terakhir: apakah sesi dibuat, apakah mencapai status terhubung, dan apakah bertahan adalah tiga fakta terpisah.
Ketika klien lama masih dipakai
Klien 2.x masih menerima berkas kredensial, dan keyring dapat menjawab promptnya tanpa rahasia pernah menyentuh disk. Sebuah pembungkus menyelesaikan entrinya, jadi berkas itu menamai pencariannya, bukan kata sandinya. Pengaturan ini bergantung pada keyring yang tidak terkunci, yang tidak dapat disediakan oleh kontainer tanpa sesi login atau unit yang mulai sebelum ada yang masuk. Alat pencarian lalu melaporkan koleksi yang tidak dapat ditulisinya, sehingga kesalahannya tampak seperti kesalahan kredensial padahal itu kesalahan keyring.
Sebelum membangun semua itu, periksa apakah pengaturan keepalive di profil menghapus kebutuhan untuk memulai ulang sama sekali. Sesi yang tetap hidup tidak pernah mencapai prompt yang sedang Anda coba otomatiskan.