Log debug L2TP kosong? Kesalahannya mungkin ada di journal

Anda menjalankan helper L2TP dengan debug, menatap terminal, dan prosesnya berhenti tanpa hal berguna di layar. Ini bukan flag debug yang rusak. Koneksi NetworkManager L2TP adalah empat proses yang bekerja sama, dan hanya sebagian yang menulis ke terminal yang Anda amati. Bukti lainnya ada di journal, sejauh satu filter.

Empat proses, dua tujuan log

Koneksi dimulai dengan IPsec, yang merupakan libreswan atau strongSwan tergantung pemasangan. Lalu daemon L2TP, secara tradisional xl2tpd dan pada beberapa build kl2tpd, menjalankan tunnel. Terakhir pppd menangani autentikasi dan pengalamatan di dalamnya.

Layanan helper mengoordinasikan bagian-bagian itu dan mencetak kemajuannya sendiri. Daemon IPsec dan pppd biasanya melapor melalui journal sistem, karena itu terminal menampilkan koneksi yang gagal sementara alasannya ada di berkas yang belum Anda buka.

Pemisahan itu juga menjelaskan mengapa galat PSK dan galat kata sandi terlihat sama dari desktop: keduanya menghasilkan pemutusan generik, dan tahap yang gagal hanya terlihat pada output tiap proses. Itulah seluruh alasan journal penting di sini. Satu pesan generik di desktop, empat kemungkinan penulis di belakangnya.

Kumpulkan satu percobaan, lalu baca urutannya

Reproduksi sekali, dengan profil yang diketahui dan waktu yang diketahui, lalu baca jendela sempit alih-alih seluruh boot. Mengulang percobaan sambil mengubah setelan mengubah log menjadi campuran yang tidak bisa ditafsirkan.

Perintah ini memilih proses yang berpartisipasi untuk boot saat ini, dan jalur plugin layak dikonfirmasi pada distribusi Anda:

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

Bidang berulang dalam satu pemanggilan memilih gabungan proses tersebut, yang menjaga urutan dalam urutan waktu. Pada sistem berbasis Debian kueri yang setara adalah dpkg -L; intinya menemukan di mana helper sebenarnya berada sebelum mencoba menjalankannya secara manual.

Tiga kondisi menentukan langkah berikutnya

Baca tahap pertama yang gagal, lalu pilih sesuai itu. Jika IPsec melaporkan kegagalan proposal atau autentikasi rekan, tunnel tidak pernah terbentuk, dan mengubah kata sandi PPP tidak bisa membantu.

Jika tunnel terbentuk dan pppd menolak login, rahasia bersama sudah baik dan masalah kredensial ada satu lapis di atasnya. Jika pppd menegosiasikan alamat dan kegagalan muncul kemudian, keduanya berfungsi dan masalah yang tersisa adalah perutean, DNS, atau kebijakan server itu sendiri.

Ketiga cabang itu mencakup hampir semua pemutusan generik, dan ditentukan oleh proses mana yang mencatat galat terakhir, bukan oleh pesan galat mana yang tampak paling mengkhawatirkan.

Ada baiknya juga memastikan backend IPsec mana yang terpasang sebelum menyentuh setelan debug. Opsi pencatatan yang ditulis untuk strongSwan tidak melakukan apa pun saat libreswan berjalan, dan koneksi akan terus gagal di tempat yang sama selagi Anda menyunting berkas yang tidak dibaca siapa pun.

Mode debug meninggalkan berkas

Alur kerja debug asli menjalankan layanan secara manual dengan flag debug, dan mode itu bisa meninggalkan berkas konfigurasi runtime yang dihasilkan di tempatnya saat koneksi berakhir.

Berkas itu berisi materi autentikasi: kunci yang dibagi sebelumnya, kredensial, atau keduanya. Konfigurasi yang dihasilkan lalu disalin ke jendela obrolan adalah pengungkapan kredensial, bukan kutipan log. Hapus baris rahasia sebelum membagikan apa pun, dan hapus direktori saat penyelidikan selesai. Perlakukan sebagai rahasia, ekstrak baris tertentu yang Anda butuhkan untuk laporan, lalu hapus setelahnya alih-alih menempelkan direktori ke tiket.

Instans manual juga harus dikoordinasikan dengan yang normal. Menjalankan salinan debug saat layanan sudah memiliki plugin menghasilkan dua pemilik dan log yang mencampur keduanya, yang lebih buruk daripada tidak ada output debug sama sekali.

Setelah itu pulihkan helper normal

Saat penyelidikan selesai, hentikan instans manual, hapus berkas runtime yang disimpan, dan sambungkan kembali melalui jalur normal agar orang berikutnya melihat konfigurasi yang sesuai kenyataan.

Lalu verifikasi hasilnya pada lapisan yang gagal, bukan pada ikon desktop:

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

Sesi yang terautentikasi, menerima alamat, dan merutekan ke tujuan yang dimaksud adalah hasil yang Anda debug. Terminal yang sunyi selama percobaan gagal hanya memberi tahu Anda di mana output tidak ditulis.