Binari pppd tidak ditemui: baiki runtime, bukan pengesahan

Tiada apa-apa sampai ke gateway, kerana klien tidak menemui binari yang diperlukannya dahulu. Mesej itu menamakan pembantu runtime, dan tindak balas semula jadi ialah menganggap hujung jauh menolak sesuatu. Ia tidak menolak. Integrasi berasaskan PPP memerlukan pembantu itu pada mesin setempat, dan ia hilang, tidak boleh dibaca atau tiada di tempat yang dilihat pemanggil.

Menu dan daemon ialah perkara berbeza

Editor desktop boleh menyimpan profil walaupun pembantu yang sepatutnya membinanya tiada, kerana penyimpanan mengesahkan medan, bukan keupayaan. Kedua-dua komponen dihantar dalam pakej berbeza dan gagal pada masa berbeza. Profil yang disimpan bersih dan sambungan yang gagal serta-merta sepenuhnya konsisten.

Kesilapan sebaliknya sama biasa: fail boleh laku di suatu tempat pada cakera tidak membuktikan bahawa integrasi yang dipilih menemui salinan yang disokong. Salinan dalam direktori rumah boleh memuaskan shell dan masih kekal tidak kelihatan kepada perkhidmatan.

Baca pakej, bukan fail

Periksa keadaan pakej yang dipasang, kebergantungan yang diisytiharkan dan senarai fail yang dijangka sebelum menyentuh apa-apa. Pembungkusan distribusi mendokumenkannya secara eksplisit, dan pakej NetworkManager PPTP Debian ialah contoh berguna, kerana ia bergantung secara berasingan pada pakej daemon PPP dan pada klien PPTP. Ini integrasi lama, bukan cadangan untuk menggunakan PPTP hari ini. Ia menunjukkan bagaimana pembantu datang sebagai kebergantungan sendiri, bukan di dalam klien.

Asingkan tiga mod kegagalan: pakej yang gagal dipasang, repositori yang tidak menawarkan calon, dan binari yang dipasang secara manual di luar pemilikan pakej. Ketiganya memerlukan pembaikan berbeza, dan hanya yang pertama dibetulkan dengan memasang semula pakej yang sama.

Pemeriksaan fail boleh laku dalam shell hanya menerangkan laluan carian shell itu dan tidak lebih. Pembantu pengurus boleh berjalan dengan laluan lain, dalam persekitaran lain, atau dengan lokasi fail boleh laku yang dikonfigurasikan secara eksplisit.

dpkg -s network-manager-pptp | grep -E "Status|Depends"
dpkg -L ppp | grep -E "bin/pppd$"
command -v pppd; ls -l /usr/sbin/pppd

Baiki runtime tanpa merosakkan yang lain

Apabila runtime terbukti tidak lengkap, gunakan transaksi pakej distribusi yang telah disemak dan baca dahulu apa yang akan diubahnya. PPP dikongsi oleh beberapa integrasi rangkaian akses, jadi mengalih keluar atau memasang semulanya boleh membawa bersama pengguna yang berfungsi. Membersihkan setiap pakej berkaitan untuk membaiki satu yang rosak ialah cara sebuah komputer riba kehilangan dua sambungan yang berfungsi.

Memasang klien VPN lain juga bukan pembaikan. Ia mencipta keperluan keserasian baharu sambil membiarkan profil asal tanpa penjelasan.

Jika organisasi telah memutuskan protokol itu sendiri harus pergi, itu keputusan migrasi yang mempunyai pemilik. Ia bukan langkah penyelesaian masalah, dan ia tidak sepatutnya dibuat pada saat sambungan gagal.

Anggap ralat seterusnya sebagai peringkat baharu

Sebaik sahaja pembantu bermula, jangkakan kegagalan seterusnya berbeza. Rundingan pautan PPP, pengesahan pengguna, peruntukan alamat, laluan dan penyelesaian nama masing-masing boleh gagal secara bebas, dan setiap satu mempunyai buktinya sendiri.

Jangan jawab penolakan kemudian dengan membatalkan pembaikan kebergantungan atau dengan menghidupkan semua pilihan pengesahan dan pemampatan lama dalam profil. Itu mengubah satu masalah yang boleh didiagnosis menjadi beberapa yang saling mempengaruhi. Tukar satu tetapan pada satu masa dan catat apa yang diubahnya.

Catat versi pakej dan mesej tepat yang anda lihat. Laporan yang menamakan binari yang hilang dan pakej yang sepatutnya menyediakannya boleh diambil tindakan dengan cara yang tidak dimiliki aduan umum tentang VPN.