Tri horloĝoj en unu VPN-protokolo: kliento, pordego, kolektanto

La tempolinio de VPN-incidento kutime komenciĝas per du tempmarkoj, kiuj malsamas je kelkaj minutoj, kaj per ekrano, kiu montras alian horon. La tento estas elekti unu kiel ĝustan kaj reskribi la alian. Ambaŭ povas esti ĝustaj, ĉar skribis ilin malsamaj horloĝoj pri malsamaj eventoj. La mito estas, ke VPN havas unu horloĝon; la laboro estas trovi, kiu komponento skribis ĉiun kampon.

La mito: VPN havas unu horloĝon

Kliento skribas eventon, kiam ĝi provas konekton. Pordego skribas eventon, kiam ĝi ricevas aŭ akceptas tiun provon. Kolektanto skribas alventempon, kiam ĝi ricevas la mesaĝon de la pordego. Tiuj estas tri eventoj, kaj ĉiun stampas tiu horloĝo, kiun fidis la skribanta komponento. Kunfandi ilin en unu tempolinion estas oportuno, kiu kaŝas la malkonsenton, kiun vi provas klarigi.

La nombroj kutime malsamas je sekundoj ĝis minutoj, kaj tio estas normala. Grava estas ĉu la diferenco estas livera prokrasto, hora delokiĝo aŭ vere alia evento. Por decidi, kion vi rigardas, necesas la origino de ĉiu kampo, ne pli forta opinio pri tio, kiu maŝino pravas.

Legu la originanton antaŭ la valoro

Antaŭ ol kompari valorojn, identigu, kiu produktis ĉiun el ili kaj pri kiu kampo temas. Syslog-mesaĝo portas tempmarkon de la originanto, kiel priskribas RFC 5424, kaj la formato povas ankaŭ porti informojn pri tempokvalito priskribantajn sinkronigon kaj precizecon. La sama formato permesas al la originanto sendi tute nenian tempmarkon, kiam ĝi ne povas legi la sistemtempon, kio mem estas utila signalo.

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

Kliento povas ankaŭ sendi tempovaloron kiel aplikaĵan metadatumon, kaj servo, kiu konservas ĝin, devus etikedi ĝin kiel raportitan de la kliento anstataŭ trakti ĝin kiel sendepende kontrolitan. Tiu etikedo estas la diferenco inter pruvo kaj aserto. Kiam vi eksportas protokolojn por kazo, tenu kune la kampan nomon, la originon kaj la delokiĝon. Redukti ilin al oportuna loka tempo detruas ĝuste la informon, kiun vi bezonas.

Haltu, se vi ne povas diri, kiu komponento skribis kampon. Kompari ĝin kun io ajn alia estas konjektado.

Montro de horzono ne estas alia momento

La sama momento montrita kiel 10:00Z kaj kiel 18:00+08:00 ne estas malkohero, kaj trakti ĝin tiel perdas duonan tagon. Konvertu ambaŭ al UTC antaŭ ol kompari, kaj tenu la originalan tekston apud la konverto. Decimala frakcio unuflanke kaj tutaj sekundoj aliflanke ankaŭ ne estas konflikto. Precizeco ne estas ĝusteco: valoro kun milisekundoj povas ankoraŭ veni de horloĝo, kiu eraras je minutoj.

date -u +%FT%TZ
timedatectl

Livera prokrasto estas la alia ordinara klarigo. La pordego registras, kiam ĝi akceptis la konekton, kaj la kolektanto registras, kiam la mesaĝo atingis ĝin, do la breĉo inter ili estas transporta tempo. Tiu breĉo diras ion pri la protokola kondukilo, ne pri la VPN-sesio. Etikedu ĝin kiel alventempon kaj ĝi ĉesas konkuri kun la eventa tempo.

Korelaciu sen reskribi la pruvojn

Konservu la originalajn tempmarkojn kaj aldonu derivitan kolumnon, se vi bezonas komunan vidon. Klarigu la konverton en la notoj anstataŭ redakti la fontajn registrojn, ĉar la fonto estas tio, kion posta revizianto kontrolos. Konservu la alventempon de la kolektanto aparte, kie ajn ĝi ekzistas.

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

Ŝanĝi horloĝon de aparato ne estas privateca kontrolo kaj ne reskribas registrojn, kiujn alia sistemo jam tenas. Ĝi ankaŭ malfaciligas kompari subtenajn pruvojn, kaj ĝi povas rompi la atestilaĵajn kaj kodajn kontrolojn, kiuj dependas de la tempo. Tenu horloĝojn sinkronigitaj por ordinara funkciado, kaj traktu ĉian intencan dekliniĝon kiel difekton por esplori. Se la du registroj ŝajnas ekster ordo, rigardu horloĝan sinkronigon kaj liveron antaŭ ol konstrui novan historion.

La mito, kiun oni forlasu, estas ke ekzistas unu VPN-tempo. Demandu, kio skribis ĉiun kampon kaj kio okazis, kiam ĝi tion faris, kaj la tempolinio fariĝas aro da etikeditaj observoj anstataŭ kontraŭdiro.