VPN-tapauksen aikajana alkaa yleensä kahdesta aikaleimasta, jotka eroavat muutaman minuutin, ja näytöstä, joka näyttää eri tuntia. Kiusaus on valita toinen oikeaksi ja kirjoittaa toinen uudelleen. Molemmat voivat olla oikein, koska eri kellot kirjoittivat ne eri tapahtumista. Myytti on, että VPN:llä on yksi kello; työ on selvittää, mikä komponentti kirjoitti minkäkin kentän.

Myytti: VPN:llä on yksi kello

Asiakas kirjoittaa tapahtuman, kun se yrittää yhteyttä. Yhdyskäytävä kirjoittaa tapahtuman, kun se vastaanottaa tai hyväksyy yrityksen. Kerääjä kirjoittaa saapumisajan, kun se vastaanottaa yhdyskäytävän viestin. Nämä ovat kolme tapahtumaa, ja kunkin leimaa se kello, johon kirjoittava komponentti luotti. Niiden latominen yhdeksi aikajanaksi on mukavuus, joka kätkee sen ristiriidan, jota yrität selittää.

Luvut eroavat yleensä sekunneista minuutteihin, ja se on normaalia. Ratkaisevaa on, onko ero toimitusviivettä, kellon siirtymää vai todella eri tapahtuma. Sen päättäminen, mitä katsot, vaatii kunkin kentän alkuperän, ei vahvempaa mielipidettä siitä, mikä kone on oikeassa.

Lue alkuperä ennen arvoa

Ennen arvojen vertaamista selvitä, kuka kunkin tuotti ja mikä kenttä on kyseessä. Syslog-viesti kantaa alkuperän aikaleiman, kuten RFC 5424 kuvaa, ja muoto voi kantaa myös ajan laadun tietoja, jotka kuvaavat synkronointia ja tarkkuutta. Sama muoto sallii alkuperän olla lähettämättä lainkaan aikaleimaa, kun se ei voi lukea järjestelmän aikaa, mikä itsessään on hyödyllinen signaali.

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

Asiakas voi lähettää aika-arvon myös sovelluksen metatietona, ja sitä tallentavan palvelun pitäisi merkitä se asiakkaan ilmoittamaksi sen sijaan, että sitä pidettäisiin itsenäisesti vahvistettuna. Tuo merkintä on ero todisteen ja väitteen välillä. Kun viet lokeja tapausta varten, pidä kentän nimi, alkuperä ja siirtymä yhdessä. Niiden pelkistäminen mukavaksi paikallisajaksi tuhoaa juuri sen tiedon, jonka tarvitset.

Pysähdy, jos et voi sanoa, mikä komponentti kirjoitti kentän. Sen vertaaminen mihin tahansa muuhun on arvailua.

Aikavyöhykkeen näyttö ei ole eri hetki

Sama hetki muodossa 10:00Z ja muodossa 18:00+08:00 ei ole ristiriita, ja sen pitäminen ristiriitana hukkaa puoli päivää. Muunna molemmat UTC:hen ennen vertaamista ja pidä alkuperäinen teksti muunnoksen vieressä. Desimaaliluku toisella puolella ja kokonaiset sekunnit toisella eivät nekään ole ristiriita. Tarkkuus ei ole oikeellisuutta: millisekunteja sisältävä arvo voi silti tulla kellosta, joka on minuutteja pielessä.

date -u +%FT%TZ
timedatectl

Toimitusviive on toinen tavallinen selitys. Yhdyskäytävä kirjaa, milloin se hyväksyi yhteyden, ja kerääjä kirjaa, milloin viesti saapui sille, joten niiden välinen aukko on siirtoaikaa. Tuo aukko kertoo lokiputkesta, ei VPN-istunnosta. Merkitse se saapumisajaksi, niin se lakkaa kilpailemasta tapahtuma-ajan kanssa.

Korreloi kirjoittamatta todisteita uudelleen

Säilytä alkuperäiset aikaleimat ja lisää johdettu sarake, jos tarvitset yhteisen näkymän. Selitä muunnos muistiinpanoissa sen sijaan että muokkaisit lähdetietueita, koska lähde on se, minkä myöhempi tarkastaja tarkistaa. Säilytä kerääjän saapumisaika erikseen kaikkialla, missä se on olemassa.

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

Laitteen kellon muuttaminen ei ole tietosuojan hallintakeino eikä kirjoita uudelleen tietueita, jotka toinen järjestelmä jo pitää. Se myös vaikeuttaa tukitodisteiden vertaamista ja voi rikkoa varmenteiden ja koodin tarkistukset, jotka riippuvat ajasta. Pidä kellot synkronissa normaalia käyttöä varten ja käsittele kaikki tahallinen poikkeama tutkittavana vikana. Jos kaksi tietuetta näyttää olevan väärässä järjestyksessä, katso kellon synkronointia ja toimitusta ennen kuin rakennat uuden historian.

Myytti, josta on luovuttava, on se, että on olemassa yksi VPN-aika. Kysy, mikä kunkin kentän kirjoitti ja mitä tapahtui, kun se sen teki, niin aikajanasta tulee joukko merkittyjä havaintoja eikä ristiriita.

Aiheeseen liittyvät artikkelit