OpenVPN menampilkan active (exited)? Temukan instance yang Anda jalankan

Anda memeriksa tunnel, menjalankan systemctl status openvpn, dan mendapat active (exited) tanpa Main PID serta dengan daftar proses kosong. Bacaan alamiahnya adalah layanan mulai lalu mati, jadi Anda membuka unit, menemukan /bin/true, dan menyimpulkan paketnya rusak. Pada paket Debian, keadaan itu adalah wrapper yang bekerja sesuai rancangan, dan tunnel hidup di salah satu instance unit yang diluncurkannya. Unit agregat tidak akan pernah memberi tahu instance mana yang membangunnya.

Apa arti active (exited) sebenarnya pada unit ini

Unit yang dipaketkan adalah tugas sekali jalan: ExecStart-nya /bin/true, dan RemainAfterExit=yes-lah yang membuat unit selesai tetap dilaporkan sebagai active (exited). Cabut direktif itu dan tugas /bin/true yang sukses sama akan berakhir di inactive (dead), yang justru keadaan yang orang harapkan dan salah baca ke arah sebaliknya. Perintahnya hanya pengganti, dan unit melaporkan pekerjaan yang dilakukan unit lain. Tidak ada yang rusak dalam susunan itu, dan mengganti /bin/true mengubah kontrak pemaketan, bukan tunnel.

Wrapper mendelegasikan. Ia menjalankan instance unit yang disediakan konfigurasi paket atau generator systemd-nya, karena itu daftar proses kosong tidak membuktikan apa pun tentang tunnel. Saat tidak ada instance yang dipilih, wrapper tetap berhasil dan tetap tidak menjalankan apa pun. Keadaan itu menjawab apakah wrapper berjalan, bukan apakah ada tunnel.

Baca tiga baris keluaran status, bukan kata di dalam tanda kurung. Loaded menyebut file unit yang dibaca systemd, Active membawa stempel waktu jalannya yang terakhir berhasil, dan Main PID yang tidak ada cocok dengan tugas sekali jalan yang sudah selesai. Ketiga baris itu juga cara membedakan wrapper ini dari layanan yang tumbang satu detik setelah mulai.

Daftar unit sebelum Anda membaca status lagi

Tanyakan kepada systemd apa yang ada sebelum bertanya apa yang berjalan. Templat bisa terpasang sementara tidak ada instance yang dibuat, dan hanya unit yang dibuat yang membawa tunnel. Mulailah dari kumpulan yang dimuat:

systemctl list-units 'openvpn*'

Daftar itu adalah yang telah dimuat systemd saat ini, dan itulah yang paling mirip inventaris tunnel. File unit yang terpasang menjawab pertanyaan lain, dan daftar itu masih menampilkan templat saat tidak ada yang dibuat:

systemctl list-unit-files 'openvpn*'

Baca kedua daftar bersama-sama, karena templat di daftar kedua dan instance di daftar pertama adalah jawaban berbeda. Templat yang ada dan instance yang berjalan bukan fakta yang sama, dan hanya yang kedua berarti tunnel. Tata letak paket juga berbeda antar distribusi dan versi OpenVPN. Templat openvpn@ yang lebih tua, pasangan client dan server yang terpisah, dan wrapper distribusi semuanya bisa sah dalam pemaketannya masing-masing.

Sesuaikan dengan mesin Anda, bukan tutorial yang Anda temukan. Nama instance di keluaran orang lain bisa office sementara milik Anda home atau work. Yang berpindah adalah metodenya, bukan stringnya.

Ikuti nama instance ke file yang dibacanya

Pada templat client upstream, direktori kerja unit adalah /etc/openvpn/client dan perintahnya mengambil %i.conf dari sana, jadi openvpn-client@office membaca /etc/openvpn/client/office.conf. Konfirmasikan pemetaan itu pada unit yang terpasang alih-alih memercayai contohnya, karena templat yang Anda miliki bisa lebih tua atau ditulis ulang oleh distribusi:

systemctl cat [email protected]

Baca drop-in yang muncul di bagian bawah keluaran itu, karena file di bawah .d/ dapat mengubah ExecStart, direktori kerja, atau jalur konfigurasi. Profil yang Anda unduh sebagai office.ovpn bukan file yang dibuka instance. Jarak itulah alasan biasa sebuah galat menyebut jalur yang tidak pernah Anda sunting.

Jalur relatif di dalam profil adalah jebakan berikutnya. Memindahkan file utama sementara referensi ca, cert, dan key tetap relatif menukar galat file hilang dengan galat file hilang yang lain. Yang kedua menunjuk file yang Anda yakin ada, dan karena itu direktori profil lebih penting daripada nama file.

Jalankan, lalu baca jurnal instance itu

Jalankan instance yang baru Anda periksa, karena log unit agregat tidak akan memuat galat tunnel. Kemudian baca jurnal untuk boot ini dan cari dalam urutan itu galat konfigurasi, galat akses file, dan galat koneksi, karena masing-masing gagal pada tahap yang berbeda dari proses mulai.

sudo systemctl start [email protected]
journalctl -u [email protected] -b

Menjalankan dan mengaktifkan adalah keputusan terpisah: start menjalankan unit sekarang, enable mengatur boot berikutnya, dan enable --now melakukan keduanya dalam satu langkah. daemon-reload membaca ulang definisi unit dan tidak menjalankan ulang proses yang sedang berjalan maupun menerapkan profil yang disunting. Setelah Anda mengubah profil, jalankan ulang instance-nya, karena itulah yang membaca ulang file.

Jangan pasang pengelola kedua pada tunnel yang sama

NetworkManager dan pengelola sesi OpenVPN 3 memiliki keadaan koneksinya sendiri, dan instance systemd di samping salah satunya menaruh dua pemilik pada tunnel yang sama. Gejalanya adalah tunnel yang naik lalu diganti beberapa detik kemudian, atau yang menolak tetap berhenti. Pilih pengelola yang didokumentasikan distribusi Anda untuk desktop, dan gunakan systemd dengan sengaja di server.

Periksa pemilik yang sudah ada sebelum menjalankan instance. Saat applet desktop menampilkan koneksi, instance yang Anda jalankan bersaing dengannya alih-alih melengkapinya. Nonaktifkan pengelola yang tidak Anda pakai alih-alih menjalankan keduanya dan berharap urutannya bertahan. Konflik itu juga menjelaskan jurnal yang tunnel dibangun lalu dibongkar oleh proses yang tidak pernah Anda jalankan.

Jawab pertanyaan awal dengan nama instance, file yang dibacanya, dan baris jurnal yang gagal. Catatan OpenVPN tentang integrasi systemd menjelaskan tata letak templat dan pemetaan file yang melaluinya nama instance diselesaikan.