OpenVPN menunjukkan active (exited)? Cari instance yang anda mulakan

Anda memeriksa tunnel, menjalankan systemctl status openvpn dan mendapat active (exited) tanpa Main PID serta dengan senarai proses kosong. Bacaan semula jadi ialah perkhidmatan bermula lalu mati, jadi anda membuka unit, menemui /bin/true dan menyimpulkan pakej itu rosak. Dalam pakej Debian, keadaan itu ialah wrapper yang bekerja seperti direka, dan tunnel hidup dalam salah satu unit instance yang dimulakannya. Unit agregat tidak akan memberitahu anda instance mana yang membinanya.

Apa maksud active (exited) sebenarnya pada unit ini

Unit yang dipakejkan ialah tugas sekali jalan: ExecStart-nya /bin/true, dan RemainAfterExit=yes ialah yang mengekalkan unit selesai dilaporkan sebagai active (exited). Buang direktif itu dan tugas /bin/true yang berjaya sama akan berakhir dalam inactive (dead), iaitu tepat keadaan yang orang jangkakan dan salah baca ke arah bertentangan. Perintah itu hanya pemegang tempat, dan unit melaporkan kerja yang dilakukan unit lain. Tiada apa dalam susunan itu rosak, dan menggantikan /bin/true mengubah kontrak pemakejan, bukan tunnel.

Wrapper mewakilkan. Ia memulakan unit instance yang dibekalkan oleh konfigurasi pakej atau penjana systemd-nya, sebab itu senarai proses kosong tidak membuktikan apa-apa tentang tunnel. Apabila tiada instance dipilih, wrapper tetap berjaya dan tetap tidak memulakan apa-apa. Keadaan itu menjawab sama ada wrapper berjalan, bukan sama ada tunnel wujud.

Baca tiga baris output status, bukan perkataan dalam kurungan. Loaded menamakan fail unit yang dibaca systemd, Active membawa cap masa larian berjaya terakhir, dan Main PID yang tiada sepadan dengan tugas sekali jalan yang telah selesai. Tiga baris itu juga cara membezakan wrapper ini daripada perkhidmatan yang tumbang sesaat selepas bermula.

Senaraikan unit sebelum anda membaca status lagi

Tanya systemd apa yang wujud sebelum bertanya apa yang berjalan. Templat boleh dipasang tanpa sebarang instance dicipta, dan hanya unit yang dicipta membawa tunnel. Mulakan dengan set yang dimuatkan:

systemctl list-units 'openvpn*'

Senarai itu ialah apa yang systemd muatkan pada saat ini, dan itulah yang paling hampir dengan inventori tunnel. Fail unit yang dipasang menjawab soalan lain, dan senarai itu masih menunjukkan templat apabila tiada apa dicipta:

systemctl list-unit-files 'openvpn*'

Baca kedua-dua senarai bersama, kerana templat dalam yang kedua dan instance dalam yang pertama ialah dua jawapan berbeza. Templat yang wujud dan instance yang berjalan bukan fakta yang sama, dan hanya yang kedua bermaksud tunnel. Susun atur pakej juga berbeza antara distribusi dan versi OpenVPN. Templat openvpn@ yang lebih lama, pasangan client dan server yang berasingan, dan wrapper distribusi semuanya boleh sah dalam pemakejan masing-masing.

Sesuaikan dengan mesin anda, bukan tutorial yang anda temui. Nama instance dalam output orang lain mungkin office sementara anda home atau work. Yang dipindahkan ialah kaedah, bukan rentetan.

Ikut nama instance ke fail yang dibacanya

Dalam templat client upstream, direktori kerja unit ialah /etc/openvpn/client dan perintahnya mengambil %i.conf dari situ, jadi openvpn-client@office membaca /etc/openvpn/client/office.conf. Sahkan pemetaan itu pada unit yang dipasang dan bukan mempercayai contoh, kerana templat anda mungkin lebih lama atau tulisan semula distribusi:

systemctl cat [email protected]

Baca drop-in yang muncul di bahagian bawah output itu, kerana fail di bawah .d/ boleh mengubah ExecStart, direktori kerja atau laluan konfigurasi. Profil yang anda muat turun sebagai office.ovpn bukan fail yang dibuka instance. Jurang itulah sebab biasa sesuatu ralat menamakan laluan yang tidak pernah anda sunting.

Laluan relatif dalam profil ialah perangkap seterusnya. Memindahkan fail utama sementara rujukan ca, cert dan key kekal relatif menukar ralat fail hilang dengan ralat fail hilang yang lain. Yang kedua menunjuk fail yang anda yakin wujud, dan sebab itu direktori profil lebih penting daripada nama fail.

Mulakannya, kemudian baca jurnal instance itu

Mulakan instance yang baru anda periksa, kerana log unit agregat tidak akan mengandungi ralat tunnel. Kemudian baca jurnal but ini dan cari dalam urutan itu ralat konfigurasi, ralat akses fail dan ralat sambungan, kerana setiap satu gagal pada peringkat permulaan yang berbeza.

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

Memulakan dan mendayakan ialah keputusan berasingan: start menjalankan unit sekarang, enable menyediakan but seterusnya, dan enable --now melakukan kedua-duanya dalam satu langkah. daemon-reload membaca semula definisi unit dan tidak memulakan semula proses yang berjalan dan tidak menggunakan profil yang disunting. Selepas anda menukar profil, mulakan semula instance, kerana itulah yang membaca semula fail.

Jangan letak pengurus kedua pada tunnel yang sama

NetworkManager dan pengurus sesi OpenVPN 3 mempunyai keadaan sambungan mereka sendiri, dan instance systemd di sebelah salah satunya meletakkan dua pemilik pada tunnel yang sama. Gejalanya ialah tunnel yang naik lalu diganti beberapa saat kemudian, atau yang enggan kekal berhenti. Pilih pengurus yang didokumenkan distribusi anda untuk desktop, dan gunakan systemd dengan sengaja pada pelayan.

Periksa sama ada sudah ada pemilik sebelum memulakan instance. Apabila applet desktop menunjukkan sambungan, instance yang anda mulakan bersaing dengannya dan bukannya melengkapkannya. Lumpuhkan pengurus yang tidak anda gunakan dan bukannya menjalankan kedua-duanya sambil berharap urutan bertahan. Konflik itu juga menjelaskan jurnal di mana tunnel dibina lalu dirobohkan oleh proses yang tidak pernah anda mulakan.

Jawab soalan asal dengan nama instance, fail yang dibacanya dan baris jurnal yang gagal. Nota OpenVPN tentang integrasi systemd menerangkan susun atur templat dan pemetaan fail yang melaluinya nama instance diselesaikan.