journalctl untuk log VPN: unit manakah yang memiliki sambungan?

Mulakan dengan unit systemd yang benar-benar memiliki sambungan VPN, bukan dengan arahan log yang anda ingat. Perkhidmatan OpenVPN langsung, unit wg-quick dan profil NetworkManager meletakkan mesej berguna mereka dalam unit yang berbeza, dan pertanyaan terhadap unit yang salah menghasilkan keputusan kosong yang kelihatan seperti kesenyapan. Bandingkan tiga pemilik biasa, sempitkan tetingkap, kemudian baca peringkat mengikut urutan.

Bandingkan tiga pemilik biasa

Perkhidmatan klien OpenVPN biasanya unit instans yang dinamakan sempena profil, seperti [email protected]. Mesejnya merangkumi laluan konfigurasi, penghuraian pilihan, jabat tangan TLS dan pemasangan laluan yang dilakukan oleh klien.

Unit wg-quick lebih senyap secara reka bentuk. Konfigurasi antara muka berlaku semasa permulaan, jabat tangan dikendalikan oleh kernel, dan penjanaan semula kunci rutin tidak dilog secara lalai, jadi wg show selalunya lebih bermaklumat daripada jurnal. Perbezaan itu penting apabila anda membandingkan protokol yang merekod rundingan dengan protokol yang tidak berbuat demikian.

NetworkManager memiliki profil yang diciptakannya, dan mesejnya berada di bawah NetworkManager.service walaupun pemalam dasarnya ialah pembantu VPN. Tanya pengurus dan unit pembantu kedua-duanya apabila profil diurus dengan cara itu.

Sempitkan pertanyaan kepada satu unit dan satu tetingkap

Tanya unit yang anda kenal pasti, dan hadkan masa kepada percubaan yang anda siasat. Satu hari biasanya mencukupi, dan tetingkap yang lebih pendek lebih baik apabila mesin sering menyambung semula.

journalctl -u [email protected] --since today
systemctl list-units --type=service | grep -i vpn
systemctl cat [email protected]

Sahkan nama yang dipasang sebelum anda mempercayai pertanyaan. Pembungkusan pengedaran menukar nama unit, dan profil yang wujud sebagai fail mungkin tidak pernah didayakan sebagai perkhidmatan. Jika unit itu tiada, jurnal kosong memberitahu anda tentang penggunaan, bukan tentang terowong.

Baca peringkat pertama yang gagal

Baca peristiwa mengikut urutan ia berlaku: carian titik akhir, pengangkutan, identiti, pengesahan, pemasangan laluan dan kegagalan aplikasi selepasnya. Kegagalan khusus yang pertama ialah yang wajar disiasat, kerana segala-galanya selepasnya ialah akibat.

Perkhidmatan yang bermula dengan jayanya tidak membuktikan setiap sumber yang diperlukan boleh dicapai. Gelung sambung semula boleh menghasilkan beberapa rundingan berasingan, jadi simpan nama profil dan masa percubaan bersama peristiwa, dan baca satu percubaan dan bukannya aliran bergabung. Satu percubaan ialah urutan dengan sebab, manakala aliran bergabung ialah dinding baris berulang. Tulis kesilapan pertama dalam tiket sebelum anda membaca lebih lanjut.

Jangan campurkan perkhidmatan yang gagal dengan klien manual

Jika anda memulakan klien secara manual selepas perkhidmatan gagal, outputnya pergi ke tempat lain dan tingkah lakunya mungkin berbeza. Rakamkan keputusan baharu daripada pemilik yang sama dan permintaan yang sama selepas pembetulan yang disokong, supaya perbandingan menunjukkan apa yang berubah dan bukannya mencampurkan dua program berbeza.

Jangan ubah cap masa asal untuk menjajarkannya dengan hos lain. Catat zon waktu dan sebarang perbezaan jam yang diketahui secara berasingan, kerana garis masa yang anda sunting bukan lagi bukti.

Kongsi petikan, bukan eksport

Entri jurnal boleh mengandungi nama pengguna, alamat titik akhir, topologi peribadi dan maklumat persekitaran skrip. Semak petikan sebenar dan tutup bahagian sensitif daripada menerbitkan eksport penuh tanpa had. Petik baris yang membuktikan kegagalan dan ringkaskan selebihnya. Petikan pendek yang disemak lebih mudah diambil tindakan daripada fail yang tiada siapa baca.

Hantar tetingkap sempit, nama unit dan peringkat pertama yang gagal, dan nyatakan perkara yang telah anda ketepikan. manual systemd journalctl mendokumentasikan pemilih dan pilihan output jika anda memerlukan bentuk yang disokong oleh versi pengedaran anda.