OpenVPN gagal mulai tanpa error? Lihat journal

Perintahnya kembali, layanan tampil gagal, dan tidak ada yang mirip penjelasan sampai ke terminal. Keheningan itu adalah gejala yang orang sebut «OpenVPN tidak mau mulai», dan hampir tidak pernah berarti programnya mati tanpa mengatakan apa pun. Artinya pesannya pergi ke kanal yang tidak Anda baca, atau yang Anda jalankan bukan yang Anda konfigurasi. Kedua kasus bisa didiagnosis dalam waktu kurang dari satu menit begitu Anda berhenti menganggap profil sebagai tersangka.

Empat tempat menyerap keluaran: journal unit, plugin yang memiliki koneksi, ujung lain terowongan, dan biner yang berbeda dari yang Anda kira sedang berjalan. Masing-masing punya pemeriksaannya sendiri.

Keheningan berarti Anda tidak memantau kanal yang benar

Pemanggilan di latar depan mencetak ke terminal Anda. Unit mencetak ke journal, dan unit yang gagal bisa keluar sebelum menulis apa pun jika kegagalannya ada pada cara ia dijalankan, bukan pada apa yang diperintahkan kepadanya. Perbedaan ini penting: tidak ada entri journal berarti prosesnya tidak pernah benar-benar berjalan, sedangkan satu entri yang diikuti keluarnya proses berarti ia berjalan dan menolak sesuatu.

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

Tambahkan systemctl show -p Result -p ExecMainStatus openvpn-client@office untuk memisahkan keluar bersih dari sinyal. Status 1 dengan Result=exit-code adalah keputusan program; Result=signal atau timeout justru menunjuk ke lingkungan, dan tidak ada penyuntingan profil yang akan mengubahnya. Catat kedua nilai sebelum memulai ulang apa pun, karena mulai ulang menghapus keadaan sementara yang menghasilkannya.

Nama instance adalah bagian dari jalurnya

Unit templat yang dipaketkan tidak menerima jalur berkas. Ia menerima nama instance, dan nama itu ditambahkan ke sebuah direktori untuk menemukan profil: office diselesaikan menjadi /etc/openvpn/client/office.conf pada paket Debian dan Ubuntu. Berkas bernama office-v2.conf yang dijalankan sebagai @office tidak pernah dibaca, dan unit keluar dengan tenang karena dari sudutnya tidak ada yang perlu dilakukan. Direktori pencarian berbeda antara mode klien dan server, jadi kesalahan yang sama menunjuk ke tempat yang sama sekali lain saat Anda mengganti templat.

Ketidakcocokan itulah sumber paling umum dari kegagalan senyap, dan tidak terlihat di profil karena profilnya baik-baik saja. Daftar apa yang benar-benar ada dan bandingkan kedua nama karakter demi karakter, termasuk ekstensi apa pun yang diharapkan paket.

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

Jika unit diaktifkan tetapi tidak ada instance yang terdaftar, pengaktifannya sendiri mungkin merujuk ke nama yang kemudian diganti. Mengaktifkan kembali instance yang benar biasanya cukup, dan berkas unit lama yang tertinggal layak dihapus agar tidak membingungkan orang berikutnya. Berkas unit yang tertinggal adalah hal kecil yang membuat seseorang kehilangan satu jam nanti.

Saat plugin memiliki terowongan, terminal tidak melihat apa pun

Koneksi yang dimulai dari applet desktop dimiliki oleh NetworkManager, dan keluaran OpenVPN-nya masuk ke journal layanan itu, bukan ke shell yang Anda buka. Menjalankan klien dengan tangan dan tidak melihat apa pun adalah hal yang wajar dalam susunan itu, karena proses yang dijalankan dengan tangan bukan yang membawa koneksi.

Cari layanan yang memilikinya di journal, lalu reproduksi penguraian dengan tingkat detail yang bisa Anda baca. Dua perintah di bawah ini melihat pemilik berbeda dari kegagalan yang sama.

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

Jalur mandiri adalah untuk membaca pesan, bukan untuk menggantikan koneksi terkelola, dan keduanya berbeda setelahnya: integrasi DNS, rute, dan masa pakai dimiliki plugin. Memperbaiki kesalahan penguraian di jalur mandiri tidak otomatis memperbaiki resolusi nama setelah applet mengambil alih, jadi pisahkan kedua pengamatan.

Dua biner, satu PATH

Build manual yang dipasang di bawah /usr/local menang pada pemanggilan shell, karena /usr/local/sbin mendahului /usr/sbin pada PATH Ubuntu bawaan. Unit tidak memakai PATH Anda; ia menjalankan jalur absolut yang tertulis di ExecStart. Jadi versi yang bekerja di terminal Anda dan versi yang gagal sebagai layanan bisa benar-benar program yang berbeda.

Bandingkan keduanya sebelum membangun ulang apa pun. Perintah ketiga adalah yang menentukan argumennya.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

Satu lagi perbedaan lingkungan bersembunyi di tempat yang sama. Unit terpaket bergantung pada direktori runtime di bawah /run yang dibuat systemd untuknya; unit pengganti yang ditulis tangan dan mengabaikan pengaturan itu bisa gagal sebelum membuka satu berkas pun, dan kegagalannya tampak seperti penolakan umum tanpa pesan OpenVPN.

Kegagalan yang tidak bisa dilaporkan klien

Sebagian hasil diputuskan di ujung jauh. Gateway yang menjawab dengan status HTTP dan menutup koneksi sudah memberi tahu Anda keadaannya sendiri, dan langkah berikut yang berguna adalah log-nya atau akun di balik kredensial, bukan berkas lokal Anda. Tidak ada yang rusak secara lokal dalam skenario itu, dan menyunting profil untuk mengimbanginya membuat diagnosis berikutnya lebih sulit. Baca log itu sebelum Anda menyentuh konfigurasi klien.

Kasus senyap lainnya adalah klien yang bekerja dengan benar. Terowongan mode klien tidak pernah mendengarkan di port, jadi pemeriksaan yang mengharapkan pendengar terbuka tidak akan melaporkan apa pun dan tampak seperti kegagalan. Pastikan mode mana yang Anda jalankan sebelum menarik kesimpulan dari daftar port yang kosong.

Kerjakan lapisannya secara berurutan: apakah unit ada dan nama instance benar, apakah ada yang mencapai journal atau berkas --log, biner dan profil mana yang benar-benar berjalan, dan apakah kegagalannya lokal atau jarak jauh. Setiap jawaban menghilangkan satu lapisan. Mulai dari profil berarti menulis ulang berkas yang mungkin tidak pernah dibuka.