OpenVPN 3 Linux: baca ralat D-Bus sebelum anda membuat gulung balik

Kegagalan OpenVPN 3 Linux tiba sebagai ralat kaedah D-Bus dengan nama asing terlekat, dan godaan ialah menurunkan taraf pakej lalu berharap. Klien bukan satu program: sebuah frontend baris arahan bercakap melalui bas dengan perkhidmatan yang memiliki profil, sesi, enjin VPN dan perubahan rangkaian yang berkeistimewaan. Memutuskan yang mana antara lima itu memiliki panggilan yang gagal ialah sebahagian besar diagnosis, dan kosnya satu arahan dan bukannya satu gulung balik. Berikut ialah keputusan itu, mengikut susunan kegagalan biasanya muncul.

Lima pemilik di sebalik satu arahan

Lima proses penting, dan setiap satu mempunyai nama bas sendiri: frontend yang menerima arahan anda, pengurus konfigurasi yang menyimpan profil dan dasar aksesnya, pengurus sesi yang memiliki jangka hayat sesi, backend yang menjalankan sambungan melalui OpenVPN 3 Core Engine, dan perkhidmatan konfigurasi rangkaian yang memasang antara muka, laluan dan tetapan DNS. Ralat yang menamakan objek konfigurasi kerana itu bukan ralat backend, dan backend yang tidak mahu bermula bukan kegagalan pengesahan. Meletakkan mesej itu ke dalam salah satu baris mesti berlaku sebelum apa-apa diubah, kerana setiap langkah berikutnya bergantung pada baris mana yang benar. Meneka barisnya ialah cara pembetulan pendek bertukar menjadi sehari bekerja dengan pakej.

Tanya bas sistem perkhidmatan mana yang hadir sebelum bertanya apa-apa yang lain, kemudian sahkan bahawa bahagian yang dipasang bersetuju tentang satu versi. OpenVPN 3 Linux mendaftarkan perkhidmatan itu sebagai unit sistem, jadi bas yang perlu ditanya ialah bas sistem, pertanyaan versi memerlukan kuasa pentadbiran, dan senarai yang dibuat dengan --user membaca sesi log masuk anda, tempat unit itu tidak pernah muncul. Perkhidmatan diaktifkan atas permintaan dan sesetengahnya keluar apabila melahu, jadi perkhidmatan yang tiada sebelum permintaan pertama anda memang belum pernah diminta apa-apa. Tiga arahan di bawah menjawab kehadiran, versi dan keadaan unit tanpa membuka sesi VPN.

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

Apa yang sebenarnya dibuktikan oleh setiap senarai

Paparan milik klien sendiri ialah bukti paling murah yang ada, dan setiap satunya membuktikan lebih sedikit daripada yang kelihatan. Profil dalam senarai konfigurasi menunjukkan bahawa sesuatu profil telah diimport dan tiada apa-apa tentang sama ada seseorang boleh menyambung dengannya. Sesi dalam senarai sesi menunjukkan bahawa objek sesi wujud dan tiada apa-apa tentang sama ada pengesahan jauh sudah selesai.

openvpn3 configs-list
openvpn3 sessions-list

Laluan objek dalam keluaran itu menandakan objek terurus pada bas dan bukan fail, jadi ia tidak boleh diedit, dan laluan yang dicatat lebih awal menjadi usang pada saat sesi itu terputus. Menggunakan semula satu daripadanya daripada nota anda menghasilkan ralat "no such object" yang tiada kaitan dengan VPN. Jadual peringkat di bawah memisahkan apa yang dibina oleh setiap langkah sambungan daripada apa yang dibiarkannya terbuka, dan itulah perbezaan yang menjadi tunjang keputusan gulung balik. Baca baris yang sepadan dengan bukti anda, kemudian baca semula teks ralat itu.

Panggilan sambung kembali sebelum terowong wujud

Panggilan sambung menyerahkan sesi untuk anda pantau lalu kembali, sebab itulah panggilan yang kelihatan berjaya diikuti kesunyian ialah keadaan perantaraan yang normal dan bukan percanggahan. Frontend masih perlu mengikut perubahan status dan menjawab setiap permintaan interaksi. Profil yang memerlukan kelayakan dan tidak menerima jawapan menunggu dalam keadaan yang kelihatan tepat seperti backend tersangkut. Keadaan menunggu itu wajar dikenali, kerana ia menghantar orang ke komponen yang salah.

Sementara percubaan berjalan, pantau senarai sesi dan log milik frontend untuk profil itu. Sesi yang tidak pernah meninggalkan keadaan awalnya menamakan komponen yang berhenti, dan log biasanya menamakannya dalam beberapa baris pertama. Simpan nama profil di tangan, kerana arahan log mengambil profil dan bukan laluan sesi, yang merupakan satu lagi sebab untuk membaca semula senarai daripada menggunakan semula laluan.

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

Membaca log satu komponen tanpa membuka sesi

Apabila frontend tidak melaporkan apa-apa yang berguna, pergilah ke komponen yang mencatat kegagalan itu daripada memulakan sambungan lain. Dengan pencatat systemd-journald yang dikonfigurasikan, paparan jurnal terbatas pentadbir membaca peristiwa satu komponen tanpa menyentuh dasar bas atau membuka sesi, yang penting kerana diagnosis yang mengubah sistem yang sedang diukurnya membuktikan sangat sedikit. Tapis mengikut unit dan bukan mengikut tag syslog: unit perkhidmatan individu tidak menjamin pengenal bersama, jadi pertanyaan tag boleh mengembalikan halaman kosong sementara unit itu sendiri mencatat kegagalannya.

Catat empat medan sebelum meminta bantuan sesiapa: nama penuh ralat, perkhidmatan dan objek yang terlibat, cap masa, dan versi pakej yang dipasang. Itulah yang diperlukan oleh penyelenggara, dan tiada satu pun memerlukan penampalan profil atau kelayakan ke dalam tiket. Meluaskan dasar akses bas untuk menyenyapkan ralat bukan diagnosis, ia memadam sempadan yang sedang menamakan komponen itu untuk anda. Kandungan profil yang bersifat peribadi kekal di luar laporan berkongsi atas sebab yang sama seperti kelayakan.

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

Membetulkan sempadan yang menolak

Setiap baris peta mempunyai pembetulannya sendiri, dan baris-baris itu tidak menggantikan satu sama lain. Operasi yang dinafikan pada profil ialah persoalan dasar dan pemilikan, manakala backend yang tidak mahu aktif ialah persoalan perkhidmatan dan pembungkusan. Pelayan yang menolak pengesahan bukan kedua-duanya, jadi pertukaran kata laluan berulang tidak dapat membaiki masalah pengaktifan setempat. Memilih pembetulan yang salah ialah cara masalah dasar bertukar menjadi pemasangan semula.

Selepas perubahan pakej, sahkan pemasangan yang koheren dan disokong daripada menyalin satu binari lama ke tempatnya. Gulung balik terkawal ialah jawapan sah kepada regresi yang telah disahkan, asalkan pakej kekal serasi dan ada laluan balik kepada penyelenggaraan yang disokong. Bina laluan itu sebelum perkhidmatan berhenti bermula, bukan selepasnya.

Platform lain boleh berkongsi pustaka VPN teras yang sama tanpa berkongsi perkhidmatan bas Linux, jadi kegagalan yang kelihatan serupa pada Windows tidak berkata apa-apa tentang yang ini. Gambaran keseluruhan D-Bus mendokumenkan laluan objek yang didedahkan untuk konfigurasi dan sesi, dan itulah bahagian seni bina yang menjadi tunjang diagnosis ini. Bacalah sekali, dan ralat seterusnya akan tiba dengan komponen yang sudah terlekat padanya.