journalctl vir VPN-logboeke: watter eenheid besit die verbinding?

Begin met die systemd-eenheid wat werklik die VPN-verbinding besit, nie met die logopdrag wat jy onthou nie. ’n Direkte OpenVPN-diens, ’n wg-quick-eenheid en ’n NetworkManager-profiel plaas hul nuttige boodskappe in verskillende eenhede, en ’n navraag teen die verkeerde een lewer ’n leë resultaat wat soos stilte lyk. Vergelyk die drie algemene eienaars, vernou die venster en lees dan die fases in volgorde.

Vergelyk die drie algemene eienaars

’n OpenVPN-kliëntdiens is gewoonlik ’n instansie-eenheid wat na die profiel vernoem is, soos [email protected]. Sy boodskappe sluit die konfigurasiepad, die ontleding van opsies, die TLS-handdruk en die roete-installasie wat die kliënt uitvoer in.

’n wg-quick-eenheid is ontwerp om stiller te wees. Die koppelvlakkonfigurasie gebeur by die begin, die handdruk word deur die kern hanteer, en roetine-herleutelings word nie by verstek gelog nie, so wg show is dikwels meer insiggewend as die joernaal. Daardie verskil maak saak wanneer jy ’n protokol wat onderhandeling log met een wat dit nie doen nie, vergelyk.

NetworkManager besit profiele wat hy geskep het, en sy boodskappe woon onder NetworkManager.service selfs wanneer die onderliggende inprop ’n VPN-hulp is. Vra beide die bestuurder en die hulpeenheid wanneer die profiel so bestuur word.

Vernou die navraag tot een eenheid en venster

Vra die eenheid wat jy geïdentifiseer het, en beperk die tyd tot die poging wat jy ondersoek. ’n Dag is gewoonlik genoeg, en ’n korter venster is beter wanneer die masjien dikwels weer koppel.

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

Verifieer die geïnstalleerde naam voordat jy die navraag vertrou. Distribusieverpakking hernoem eenhede, en ’n profiel wat as ’n lêer bestaan, is dalk nooit as ’n diens geaktiveer nie. As die eenheid nie bestaan nie, vertel die leë joernaal jou van die ontplooiing eerder as van die tonnel.

Lees die eerste mislukte fase

Lees die gebeurtenisse in die volgorde waarin hulle plaasvind: eindpuntsoek, vervoer, identiteit, verifikasie, roete-installasie en die toepassing se latere mislukking. Die eerste spesifieke mislukking is die een wat die moeite werd is om te ondersoek, want alles daarna is ’n gevolg.

’n Diens wat suksesvol begin, bewys nie dat elke vereiste hulpbron bereikbaar is nie. ’n Herkoppel-lus kan verskeie afsonderlike onderhandelinge lewer, so hou die profielnaam en die pogingstyd by die gebeurtenisse, en lees een poging eerder as ’n saamgevoegde stroom. ’n Enkele poging is ’n reeks met ’n oorsaak, terwyl ’n saamgevoegde stroom ’n muur van herhaalde reëls is. Skryf die eerste fout in die kaartjie voordat jy verder lees.

Moenie ’n mislukte diens met ’n handmatige kliënt meng nie

As jy ’n kliënt met die hand begin het nadat die diens misluk het, gaan sy uitvoer elders heen en sy gedrag kan verskil. Neem die nuwe resultaat van dieselfde eienaar en dieselfde versoek nadat ’n ondersteunde regstelling gedoen is, sodat die vergelyking wys wat verander het eerder as om twee verskillende programme te meng.

Moenie oorspronklike tydstempele verander om by ’n ander gasheer te pas nie. Teken die tydsone en enige bekende klokverskil afsonderlik aan, want ’n tydlyn wat jy geredigeer het, is nie meer bewyse nie.

Deel ’n uittreksel, nie ’n uitvoer nie

Joernaalinskrywings kan gebruikersname, eindpuntadresse, private topologie en skripomgewingsinligting bevat. Hersien die werklike uittreksel en redigeer wat sensitief is eerder as om ’n volledige onbeperkte uitvoer te publiseer. Haal die reëls aan wat die mislukking bewys en som die res op. ’n Kort nagegane uittreksel is makliker om op te tree as ’n lêer wat niemand lees nie.

Stuur die nou venster, die eenheidsnaam en die eerste mislukte fase, en sê wat jy reeds uitgesluit het. Die systemd journalctl-handleiding dokumenteer die keurders en uitvoeropsies as jy ’n vorm nodig het wat die distribusie se weergawe ondersteun.