journalctl VPN žurnāliem: kura vienība pārvalda savienojumu?

Sāciet ar systemd vienību, kurai faktiski pieder VPN savienojums, nevis ar žurnāla komandu, kuru atceraties. Tiešs OpenVPN pakalpojums, wg-quick vienība un NetworkManager profils savus noderīgos ziņojumus ievieto dažādās vienībās, un vaicājums nepareizajai vienībai dod tukšu rezultātu, kas izskatās pēc klusuma. Salīdziniet trīs ierastos īpašniekus, sašauriniet logu un pēc tam secīgi lasiet posmus.

Salīdziniet trīs ierastos īpašniekus

OpenVPN klienta pakalpojums parasti ir instances vienība, kas nosaukta pēc profila, piemēram, [email protected]. Tās ziņojumi ietver konfigurācijas ceļu, opciju analīzi, TLS rokasspiedienu un maršruta instalēšanu, ko veic klients.

wg-quick vienība pēc uzbūves ir klusāka. Saskarnes konfigurācija notiek palaišanas laikā, rokasspiedienu apstrādā kodols, un regulārās atslēgu atjaunošanas pēc noklusējuma netiek reģistrētas, tāpēc wg show bieži ir informatīvāks par žurnālu. Šī atšķirība ir svarīga, ja salīdzināt protokolu, kas reģistrē pārrunas, ar tādu, kas to nedara.

NetworkManager pārvalda tos profilus, ko tas izveidojis, un tā ziņojumi atrodas zem NetworkManager.service arī tad, ja pamatā esošais spraudnis ir VPN palīgs. Jautājiet gan pārvaldniekam, gan palīgvienībai, ja profils tiek pārvaldīts šādi.

Sašauriniet vaicājumu līdz vienai vienībai un vienam logam

Jautājiet vienībai, kuru identificējāt, un ierobežojiet laiku līdz mēģinājumam, kuru izmeklējat. Viena diena parasti ir pietiekama, un īsāks logs ir labāks, ja iekārta bieži atkārtoti pieslēdzas.

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

Pārbaudiet instalēto nosaukumu, pirms uzticaties vaicājumam. Distribūcijas pakotnes pārdēvē vienības, un profils, kas pastāv kā fails, var nekad nebūt iespējots kā pakalpojums. Ja vienības nav, tukšais žurnāls stāsta par izvietošanu, nevis par tuneli.

Lasiet pirmo neizdevušos posmu

Lasiet notikumus tādā secībā, kādā tie notiek: galapunkta meklēšana, transportēšana, identitāte, autentifikācija, maršruta instalēšana un vēlākā lietotnes kļūda. Pirmā konkrētā kļūda ir tā, ko ir vērts izmeklēt, jo viss pēc tās ir sekas.

Pakalpojums, kas veiksmīgi startē, nepierāda, ka katrs nepieciešamais resurss ir sasniedzams. Atkārtotas pievienošanās cilpa var radīt vairākas atsevišķas pārrunas, tāpēc glabājiet profila nosaukumu un mēģinājuma laiku kopā ar notikumiem un lasiet vienu mēģinājumu, nevis apvienotu plūsmu. Viens mēģinājums ir secība ar cēloni, bet apvienota plūsma ir atkārtotu rindu siena. Pirms lasīt tālāk, ierakstiet pirmo kļūdu biļetē.

Nejauciet neizdevušos pakalpojumu ar manuālu klientu

Ja pēc pakalpojuma neveiksmes palaidāt klientu ar roku, tā izvade aiziet citur un tā uzvedība var atšķirties. Pēc atbalstīta labojuma fiksējiet jauno rezultātu no tā paša īpašnieka un tā paša pieprasījuma, lai salīdzinājums parādītu, kas mainījās, nevis sajauktu divas dažādas programmas.

Nemainiet sākotnējos laikspiedolus, lai tos saskaņotu ar citu saimnieku. Atsevišķi pierakstiet laika joslu un zināmo pulksteņa starpību, jo jūsu rediģētā laika līnija vairs nav pierādījums.

Kopīgojiet izvilkumu, nevis eksportu

Žurnāla ieraksti var saturēt lietotājvārdus, galapunktu adreses, privātu topoloģiju un informāciju par skripta vidi. Pārskatiet faktisko izvilkumu un aizsedziet to, kas ir sensitīvs, nevis publicējiet pilnu neierobežotu eksportu. Citējiet rindas, kas pierāda kļūdu, un apkopojiet pārējo. Īss pārskatīts izvilkums ir vieglāk lietojams nekā fails, ko neviens nelasa.

Nosūtiet šauro logu, vienības nosaukumu un pirmo neizdevušos posmu un pasakiet, ko jau esat izslēdzis. systemd journalctl rokasgrāmata dokumentē atlasītājus un izvades opcijas, ja jums vajag formu, ko atbalsta distribūcijas versija.