OpenVPN 3 Linux: baca kesalahan D-Bus sebelum Anda melakukan rollback

Kegagalan OpenVPN 3 Linux datang sebagai kesalahan metode D-Bus dengan nama asing yang menempel, dan godaannya adalah menurunkan versi paket lalu berharap. Klien bukan satu program: sebuah frontend baris perintah berbicara lewat bus dengan layanan yang memiliki profil, sesi, mesin VPN, dan perubahan jaringan yang berhak istimewa. Memutuskan mana dari kelima layanan itu yang memiliki panggilan yang gagal adalah sebagian besar diagnosis, dan biayanya satu perintah alih-alih satu rollback. Berikut ini adalah keputusan itu, dalam urutan kemunculan kegagalan yang biasa terjadi.

Lima pemilik di balik satu perintah

Lima proses berperan, dan masing-masing punya nama bus sendiri: frontend yang menerima perintah Anda, pengelola konfigurasi yang menyimpan profil dan kebijakan aksesnya, pengelola sesi yang memiliki masa hidup sesi, backend yang menjalankan koneksi melalui OpenVPN 3 Core Engine, dan layanan konfigurasi jaringan yang memasang antarmuka, rute, dan pengaturan DNS. Kesalahan yang menyebut objek konfigurasi karena itu bukan kesalahan backend, dan backend yang tidak mau mulai bukan kegagalan autentikasi. Menempatkan pesan itu ke salah satu baris harus terjadi sebelum apa pun diubah, karena setiap langkah berikutnya bergantung pada baris mana yang benar. Menebak barisnya adalah cara sebuah perbaikan singkat berubah menjadi seharian mengurus paket.

Tanyakan ke bus sistem layanan mana yang ada sebelum menanyakan hal lain, lalu pastikan bagian yang terpasang sepakat soal versi. OpenVPN 3 Linux mendaftarkan layanan itu sebagai unit sistem, jadi bus yang harus ditanyai adalah bus sistem, kueri versi memerlukan wewenang administratif, dan daftar yang dibuat dengan --user membaca sesi login Anda, tempat unit itu tidak pernah muncul. Layanan aktif sesuai permintaan dan sebagian keluar saat menganggur, jadi layanan yang hilang sebelum permintaan pertama Anda memang belum pernah dimintai apa pun. Tiga perintah di bawah menjawab keberadaan, versi, dan status unit tanpa membuka sesi VPN.

sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'

Apa yang sebenarnya dibuktikan setiap daftar

Tampilan milik klien sendiri adalah bukti termurah yang tersedia, dan masing-masing membuktikan lebih sedikit daripada kelihatannya. Profil dalam daftar konfigurasi menunjukkan bahwa sebuah profil diimpor dan tidak menunjukkan apa pun tentang apakah ada yang boleh terhubung dengannya. Sesi dalam daftar sesi menunjukkan bahwa objek sesi ada dan tidak menunjukkan apa pun tentang apakah autentikasi jarak jauh sudah selesai.

openvpn3 configs-list
openvpn3 sessions-list

Jalur objek dalam keluaran itu menandai objek terkelola di bus dan bukan berkas, jadi tidak bisa diedit, dan jalur yang dicatat sebelumnya menjadi usang begitu sesi itu terputus. Memakai ulang satu jalur dari catatan Anda menghasilkan kesalahan "no such object" yang tidak ada hubungannya dengan VPN. Tabel tahap di bawah memisahkan apa yang dibangun setiap langkah koneksi dari apa yang dibiarkannya terbuka, dan justru perbedaan itulah yang menjadi tumpuan keputusan rollback. Bacalah baris yang cocok dengan bukti Anda, lalu baca lagi teks kesalahannya.

Panggilan koneksi kembali sebelum terowongan ada

Panggilan koneksi menyerahkan sesi untuk Anda pantau lalu kembali, karena itu panggilan yang tampak berhasil diikuti keheningan adalah keadaan perantara yang normal dan bukan pertentangan. Frontend tetap harus mengikuti perubahan status dan menjawab setiap permintaan interaksi. Profil yang memerlukan kredensial dan tidak mendapat jawaban menunggu dalam keadaan yang tampak persis seperti backend yang macet. Keadaan menunggu itu pantas dikenali, karena ia mengirim orang ke komponen yang salah.

Selagi percobaan berjalan, pantau daftar sesi dan log milik frontend untuk profil itu. Sesi yang tidak pernah meninggalkan keadaan awalnya menunjuk komponen yang berhenti, dan log biasanya menyebutnya dalam beberapa baris pertama. Simpan nama profil di tangan, sebab perintah log menerima profil dan bukan jalur sesi, yang merupakan satu alasan lagi untuk membaca ulang daftar alih-alih memakai ulang jalur.

openvpn3 sessions-list
openvpn3 log --config <profile> --level 6

Membaca log satu komponen tanpa membuka sesi

Ketika frontend tidak melaporkan apa pun yang berguna, pergilah ke komponen yang mencatat kegagalan itu alih-alih memulai koneksi lain. Dengan pencatat systemd-journald yang dikonfigurasi, tampilan jurnal terbatas milik administrator membaca peristiwa satu komponen tanpa menyentuh kebijakan bus atau membuka sesi, yang penting karena diagnosis yang mengubah sistem yang sedang diukurnya membuktikan sangat sedikit. Saring per unit, bukan per tag syslog: unit layanan individual tidak menjamin pengenal bersama, jadi kueri tag bisa mengembalikan halaman kosong sementara unit itu sendiri mencatat kegagalannya.

Catat empat bidang sebelum meminta bantuan siapa pun: nama kesalahan lengkap, layanan dan objek yang terlibat, cap waktu, dan versi paket yang terpasang. Itulah yang dibutuhkan seorang pemelihara, dan tidak satu pun memerlukan penempelan profil atau kredensial ke dalam tiket. Memperluas kebijakan akses bus untuk membungkam kesalahan bukan diagnosis, itu menghapus batas yang sedang menunjuk komponennya untuk Anda. Isi profil yang bersifat pribadi tetap di luar laporan bersama dengan alasan yang sama seperti kredensial.

journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>

Memperbaiki batas yang menolak

Setiap baris peta punya perbaikannya sendiri, dan baris-baris itu tidak saling menggantikan. Operasi yang ditolak pada profil adalah pertanyaan tentang kebijakan dan kepemilikan, sedangkan backend yang tidak mau aktif adalah pertanyaan tentang layanan dan pengemasan. Server yang menolak autentikasi bukan keduanya, jadi perubahan kata sandi berulang tidak bisa memperbaiki masalah aktivasi lokal. Memilih perbaikan yang salah adalah cara masalah kebijakan berubah menjadi pemasangan ulang.

Setelah perubahan paket, pastikan ada pemasangan yang koheren dan didukung alih-alih menyalin satu biner lama ke tempatnya. Rollback terkendali adalah jawaban yang sah untuk regresi yang sudah dipastikan, asalkan paket tetap kompatibel dan ada jalur kembali ke pemeliharaan yang didukung. Bangun jalur itu sebelum layanan berhenti mau mulai, bukan sesudahnya.

Platform lain bisa berbagi pustaka VPN inti yang sama tanpa berbagi layanan bus Linux, jadi kegagalan yang tampak serupa di Windows tidak mengatakan apa pun tentang yang ini. Ikhtisar D-Bus mendokumentasikan jalur objek yang disediakan untuk konfigurasi dan sesi, dan itulah bagian arsitektur yang menjadi tumpuan diagnosis ini. Bacalah sekali, dan kesalahan berikutnya akan datang dengan komponen yang sudah menempel padanya.