journalctl VPN-lokeille: mikä yksikkö omistaa yhteyden?

Aloita systemd-yksiköstä, joka todella omistaa VPN-yhteyden, älä lokikomennosta, jonka muistat. Suora OpenVPN-palvelu, wg-quick-yksikkö ja NetworkManager-profiili sijoittavat hyödylliset viestinsä eri yksiköihin, ja väärään yksikköön kohdistuva kysely antaa tyhjän tuloksen, joka näyttää hiljaisuudelta. Vertaa kolmea tavallista omistajaa, kavenna aikaväliä ja lue sitten vaiheet järjestyksessä.

Vertaa kolmea tavallista omistajaa

OpenVPN-asiakaspalvelu on yleensä profiilin mukaan nimetty instanssiyksikkö, esimerkiksi [email protected]. Sen viesteihin kuuluvat kokoonpanopolku, valintojen jäsentäminen, TLS-kättely ja asiakkaan tekemä reittien asennus.

wg-quick-yksikkö on suunnittelultaan hiljaisempi. Liitännän kokoonpano tapahtuu käynnistyksessä, kättelyn hoitaa ydin, eikä rutiininomaisia avainten uusintoja kirjata oletuksena, joten wg show on usein valaisevampi kuin loki. Tämä ero on merkityksellinen, kun vertaat protokollaa, joka kirjaa neuvottelun, sellaiseen, joka ei kirjaa.

NetworkManager omistaa luomansa profiilit, ja sen viestit ovat NetworkManager.service-yksikön alla myös silloin, kun taustalla oleva liitännäinen on VPN-apuri. Kysy sekä hallintapalvelua että apuyksikköä, kun profiilia hallitaan tällä tavalla.

Kavenna kysely yhteen yksikköön ja aikaväliin

Kysy yksikköä, jonka tunnistit, ja rajaa aika tutkittavaan yritykseen. Yksi päivä riittää yleensä, ja lyhyempi aikaväli on parempi, kun kone yhdistyy usein uudelleen.

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

Varmista asennettu nimi ennen kuin luotat kyselyyn. Jakelujen paketointi nimeää yksiköitä uudelleen, eikä tiedostona olevaa profiilia ehkä ole koskaan otettu käyttöön palveluna. Jos yksikköä ei ole, tyhjä loki kertoo käyttöönotosta eikä tunnelista.

Lue ensimmäinen epäonnistunut vaihe

Lue tapahtumat siinä järjestyksessä kuin ne tapahtuvat: päätepisteen haku, siirto, identiteetti, todennus, reittien asennus ja sovelluksen myöhempi epäonnistuminen. Ensimmäinen konkreettinen epäonnistuminen on se, jota kannattaa tutkia, koska kaikki sen jälkeen on seurausta.

Onnistuneesti käynnistyvä palvelu ei todista, että jokainen tarvittava resurssi on tavoitettavissa. Uudelleenyhdistämisen silmukka voi tuottaa useita erillisiä neuvotteluja, joten pidä profiilin nimi ja yrityksen aika tapahtumien mukana ja lue yksi yritys yhdistetyn virran sijaan. Yksittäinen yritys on syyn sisältävä jakso, kun taas yhdistetty virta on toistuvien rivien seinä. Kirjoita ensimmäinen virhe tikettiin ennen kuin luet pidemmälle.

Älä sekoita epäonnistunutta palvelua käsin käynnistettyyn asiakkaaseen

Jos käynnistit asiakkaan käsin palvelun epäonnistuttua, sen tuloste menee muualle ja sen käyttäytyminen voi poiketa. Tallenna uusi tulos samalta omistajalta ja samasta pyynnöstä tuetun korjauksen jälkeen, jotta vertailu näyttää mikä muuttui sen sijaan että sekoittaisi kaksi eri ohjelmaa.

Älä muuta alkuperäisiä aikaleimoja toiseen isäntään kohdistaaksesi. Kirjaa aikavyöhyke ja tiedossa oleva kellon ero erikseen, koska muokkaamasi aikajana ei ole enää todiste.

Jaa ote, älä vientiä

Lokimerkinnät voivat sisältää käyttäjänimiä, päätepisteiden osoitteita, yksityistä topologiaa ja tietoa skriptiympäristöstä. Tarkista varsinainen ote ja peitä arkaluonteinen sen sijaan että julkaisisit täyden rajoittamattoman viennin. Lainaa rivit, jotka osoittavat epäonnistumisen, ja tiivistä loput. Lyhyt tarkistettu ote on helpompi käsitellä kuin tiedosto, jota kukaan ei lue.

Lähetä kapea aikaväli, yksikön nimi ja ensimmäinen epäonnistunut vaihe ja kerro, mitä olet jo sulkenut pois. systemd journalctl -käsikirja dokumentoi valitsimet ja tulostusvalinnat, jos tarvitset muotoa, jota jakelun versio tukee.