Tre klokker i éin VPN-logg: klient, gateway, innsamlar

Tidslinja for ei VPN-hending byrjar vanlegvis med to tidsstempel som avvik med nokre minutt, og ei vising som syner ein annan time. Freistinga er å velje det eine som riktig og skrive om det andre. Begge kan vere riktige, fordi dei vart skrivne av ulike klokker om ulike hendingar. Myten er at ein VPN har éi klokke; arbeidet er å finne ut kva komponent som skreiv kvart felt.

Myten: VPN-en har éi klokke

Ein klient skriv ei hending når han prøver ei tilkopling. Ein gateway skriv ei hending når han tek imot eller godtek freistnaden. Ein innsamlar skriv eit ankomsttidspunkt når han tek imot meldinga frå gatewayen. Det er tre hendingar, og kvar av dei vert stempla av den klokka den skrivande komponenten stolte på. Å presse dei saman til éi tidslinje er eit høve som løyner usemja du prøver å forklare.

Tala avvik vanlegvis frå sekund til minutt, og det er normalt. Det avgjerande er om skilnaden er leveringsforsinking, klokkeforskyving eller ei reelt anna hending. Å avgjere kva du ser på krev opphavet til kvart felt, ikkje ei sterkare meining om kva maskin som har rett.

Les opphavet før verdien

Før du samanliknar verdiar, må du fastsetje kven som produserte kvar av dei og kva felt det er. Ei syslog-melding ber eit tidsstempel frå opphavet, slik RFC 5424 skildrar, og formatet kan også bere tidskvalitetsinformasjon som skildrar synkronisering og nøyaktigheit. Same format lèt opphavet sende ingen tidsstempel i det heile når det ikkje kan lese systemtida, noko som i seg sjølv er eit nyttig signal.

journalctl -o short-iso --utc -n 20
logger -t vpn-check "test event"

Ein klient kan også sende ein tidsverdi som applikasjonsmetadata, og ein teneste som lagrar han bør merke han som klientrapportert i staden for å handsame han som uavhengig verifisert. Den merkinga er skilnaden mellom bevis og påstand. Når du eksporterer loggar for ei sak, hald feltnamnet, opphavet og forskyvinga saman. Å redusere dei til ei bekvem lokal tid øydelegg nettopp informasjonen du treng.

Stopp om du ikkje kan seie kva komponent som skreiv eit felt. Å samanlikne det med noko anna er gissing.

Vising av tidssone er ikkje eit anna augneblink

Det same augneblinken gjengitt som 10:00Z og som 18:00+08:00 er ikkje eit avvik, og å handsame det som eitt kastar bort ein ettermiddag. Konverter begge til UTC før du samanliknar, og hald originalteksten ved sida av konverteringa. Ein desimalbrøk på den eine sida og heile sekund på den andre er heller ikkje ein konflikt. Presisjon er ikkje nøyaktigheit: ein verdi med millisekund kan framleis kome frå ei klokke som er minutt feil.

date -u +%FT%TZ
timedatectl

Leveringsforsinking er den andre vanlege forklaringa. Gatewayen registrerer når han godtok tilkoplinga, og innsamlaren registrerer når meldinga nådde han, så gapet mellom dei er transporttid. Det gapet seier noko om loggpipelinen, ikkje om VPN-økta. Merk det som ankomsttid, og det sluttar å konkurrere med hendingstida.

Korreler utan å skrive om bevisa

Hald dei opphavlege tidsstempla og legg til ein avleidd kolonne om du treng ei felles vising. Forklar konverteringa i notata i staden for å redigere kjeldeoppføringane, fordi kjelda er det ein seinare gjennomgang vil kontrollere. Bevar ankomsttida til innsamlaren separat der ho finst.

chronyc tracking
journalctl --utc -u openvpn-client@work -n 50 --no-pager

Å endre klokka på ein eining er ikkje ein personvernkontroll og skriv ikkje om oppføringar som eit anna system alt har. Det gjer også støttebevis vanskelegare å samanlikne, og det kan øydeleggje sertifikat- og kodekontrollane som er avhengige av tid. Hald klokkene synkroniserte for normal drift, og handsam kvar medvite skjeverheit som ein feil som må granskast. Om dei to oppføringane ser ut til å vere ute av rekkjefølgje, sjå på klokkesynkronisering og levering før du byggjer ei ny historie.

Myten som må leggjast bort, er at det finst éi VPN-tid. Spør kva som skreiv kvart felt og kva som hende då det gjorde det, og tidslinja vert eit sett merkte observasjonar i staden for ei motsegn.