journalctl por VPN-protokoloj: kiu unuo posedas la konekton?

Komencu per la systemd-unuo, kiu efektive posedas la VPN-konekton, ne per la logkomando, kiun vi memoras. Rekta OpenVPN-servo, wg-quick-unuo kaj NetworkManager-profilo metas siajn utilajn mesaĝojn en malsamaj unuoj, kaj mendado al la malĝusta unuo donas malplenan rezulton, kiu aspektas kiel silento. Komparu la tri ordinarajn posedantojn, mallarĝigu la fenestron, poste legu la etapojn laŭorde.

Komparu la tri ordinarajn posedantojn

OpenVPN-klienta servo estas kutime instanca unuo nomita laŭ la profilo, ekzemple [email protected]. Ĝiaj mesaĝoj inkluzivas la konfiguran vojon, la analizon de opcioj, la TLS-manpremon kaj la instaladon de itineroj, kiun la kliento plenumas.

wg-quick-unuo estas pli silenta laŭdezajne. La interfaca konfigurado okazas ĉe starto, la manpremon pritraktas la kerno, kaj rutinaj ŝlosilaj renovigoj ne estas protokolitaj defaŭlte, do wg show ofte estas pli informa ol la protokolo. Tiu diferenco gravas, kiam vi komparas protokolon, kiu protokolas la intertraktadon, kun unu, kiu ne faras tion.

NetworkManager posedas la profilojn, kiujn ĝi kreis, kaj ĝiaj mesaĝoj loĝas sub NetworkManager.service eĉ kiam la suba kromaĵo estas VPN-helplo. Demandu kaj la administrilon kaj la helpan unuon, kiam la profilo estas administrata tiel.

Mallarĝigu la mendon al unu unuo kaj unu fenestro

Demandu la unuon, kiun vi identigis, kaj limigu la tempon al la provo, kiun vi esploras. Unu tago kutime sufiĉas, kaj pli mallonga fenestro estas pli bona, kiam la maŝino ofte rekonektiĝas.

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

Kontrolu la instalitan nomon antaŭ ol fidi la mendon. Distribuaj pakaĵoj renomas unuojn, kaj profilo, kiu ekzistas kiel dosiero, eble neniam estis ŝaltita kiel servo. Se la unuo ne ekzistas, la malplena protokolo parolas al vi pri la deplojo, ne pri la tunelo.

Legu la unuan malsukcesan etapon

Legu la okazaĵojn laŭ la ordo, en kiu ili okazas: serĉo de finpunkto, transporto, identeco, aŭtentigo, instalado de itineroj kaj la posta malsukceso de la aplikaĵo. La unua konkreta malsukceso estas tiu, kiun indas esplori, ĉar ĉio post ĝi estas sekvo.

Servo, kiu sukcese startas, ne pruvas, ke ĉiu bezonata rimedo estas atingebla. Rekonekta buklo povas produkti plurajn apartajn intertraktadojn, do tenu la profilan nomon kaj la provan tempon kun la okazaĵoj, kaj legu unu provon anstataŭ kunfanditan fluon. Unuopa provo estas sinsekvo kun kaŭzo, dum kunfandita fluo estas muro de ripetitaj linioj. Skribu la unuan eraron en la bileton antaŭ ol legi plu.

Ne miksu malsukcesan servon kun permana kliento

Se vi lanĉis klienton permane post kiam la servo malsukcesis, ĝia eligo iras aliloken kaj ĝia konduto povas malsami. Kaptu la novan rezulton de la sama posedanto kaj la sama peto post subtenata korekto, por ke la komparo montru, kio ŝanĝiĝis, anstataŭ miksi du malsamajn programojn.

Ne ŝanĝu la originalajn tempomarkojn por vicigi ilin al alia gastiganto. Notu la horzonon kaj eblan konatan horloĝdiferencon aparte, ĉar templinio, kiun vi redaktis, jam ne estas pruvo.

Diskonigu eltiraĵon, ne eksporton

Protokolaj eroj povas enhavi uzantnomojn, finpunktajn adresojn, privatan topologion kaj informojn pri la skripta medio. Kontrolu la faktan eltiraĵon kaj kaŝu tion, kio estas sentema, anstataŭ publikigi plenan nelimigitan eksporton. Citu la liniojn, kiuj pruvas la malsukceson, kaj resumu la reston. Mallonga kontrolita eltiraĵo estas pli facile uzebla ol dosiero, kiun neniu legas.

Sendu la mallarĝan fenestron, la nomon de la unuo kaj la unuan malsukcesan etapon, kaj diru, kion vi jam ekskludis. La manlibro de systemd journalctl dokumentas la elektilojn kaj eligajn opciojn, se vi bezonas formon, kiun subtenas la versio de la distribuo.