สามนาฬิกาในบันทึก VPN หนึ่งไฟล์: ไคลเอนต์ เกตเวย์ ตัวรวบรวม

ไทม์ไลน์ของเหตุการณ์ VPN มักเริ่มด้วยการประทับเวลาสองอันที่ต่างกันไม่กี่นาที และหน้าจอที่แสดงเวลาคนละชั่วโมง สิ่งล่อใจคือเลือกอันหนึ่งว่าถูกต้องแล้วเขียนอีกอันใหม่ ทั้งสองอาจถูกต้อง เพราะนาฬิกาคนละเรือนเขียนเกี่ยวกับเหตุการณ์คนละเหตุการณ์ ความเชื่อผิดคือ VPN มีนาฬิกาเรือนเดียว งานคือการหาว่าองค์ประกอบใดเขียนฟิลด์ใด

ความเชื่อผิด: VPN มีนาฬิกาเรือนเดียว

ไคลเอนต์เขียนเหตุการณ์เมื่อพยายามเชื่อมต่อ เกตเวย์เขียนเหตุการณ์เมื่อได้รับหรือยอมรับความพยายามนั้น ตัวรวบรวมเขียนเวลามาถึงเมื่อได้รับข้อความจากเกตเวย์ นี่คือสามเหตุการณ์ และแต่ละอันถูกประทับด้วยนาฬิกาที่องค์ประกอบผู้เขียนไว้วางใจ การยุบรวมเป็นไทม์ไลน์เดียวคือความสะดวกที่ซ่อนความไม่ตรงกันที่คุณกำลังพยายามอธิบาย

ตัวเลขมักต่างกันตั้งแต่ไม่กี่วินาทีถึงไม่กี่นาที และนั่นเป็นเรื่องปกติ สิ่งที่สำคัญคือความต่างนั้นเป็นความล่าช้าในการส่ง ความคลาดเคลื่อนของนาฬิกา หรือเหตุการณ์ที่ต่างกันจริง การตัดสินว่าคุณกำลังดูสิ่งใดต้องอาศัยแหล่งที่มาของแต่ละฟิลด์ ไม่ใช่ความเห็นที่หนักแน่นกว่าว่าเครื่องใดถูก

อ่านแหล่งที่มาก่อนค่า

ก่อนเปรียบเทียบค่า ให้ระบุว่าใครสร้างแต่ละค่าและเป็นฟิลด์ใด ข้อความ syslog มีการประทับเวลาจากแหล่งที่มา ดังที่ RFC 5424 อธิบาย และรูปแบบยังสามารถบรรจุข้อมูลคุณภาพเวลาที่อธิบายการซิงโครไนซ์และความแม่นยำได้ รูปแบบเดียวกันอนุญาตให้แหล่งที่มาไม่ส่งการประทับเวลาเลยเมื่ออ่านเวลาระบบไม่ได้ ซึ่งเป็นสัญญาณที่มีประโยชน์ในตัวมันเอง

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

ไคลเอนต์ยังสามารถส่งค่าเวลาเป็นเมทาดาทาของแอปพลิเคชันได้ และบริการที่จัดเก็บควรติดป้ายว่าเป็นข้อมูลที่ไคลเอนต์รายงาน แทนที่จะถือว่าได้รับการตรวจสอบอย่างอิสระ ป้ายนั้นคือความต่างระหว่างหลักฐานกับคำกล่าวอ้าง เมื่อส่งออกบันทึกสำหรับกรณีหนึ่ง ให้เก็บชื่อฟิลด์ แหล่งที่มา และความคลาดเคลื่อนไว้ด้วยกัน การย่อให้เป็นเวลาท้องถิ่นที่สะดวกจะทำลายข้อมูลที่คุณต้องการพอดี

หยุดถ้าคุณบอกไม่ได้ว่าองค์ประกอบใดเขียนฟิลด์ การเปรียบเทียบกับสิ่งอื่นใดคือการเดา

การแสดงเขตเวลาไม่ใช่ช่วงเวลาอื่น

ช่วงเวลาเดียวกันที่แสดงเป็น 10:00Z และเป็น 18:00+08:00 ไม่ใช่ความคลาดเคลื่อน และการถือว่าเป็นเช่นนั้นทำให้เสียเวลาครึ่งวัน แปลงทั้งสองเป็น UTC ก่อนเปรียบเทียบ และเก็บข้อความเดิมไว้ข้างการแปลง การมีเศษทศนิยมด้านหนึ่งและวินาทีเต็มอีกด้านก็ไม่ใช่ความขัดแย้ง ความละเอียดไม่ใช่ความถูกต้อง ค่าที่มีมิลลิวินาทีอาจมาจากนาฬิกาที่คลาดไปหลายนาที

date -u +%FT%TZ
timedatectl

ความล่าช้าในการส่งคือคำอธิบายปกติอีกอย่าง เกตเวย์บันทึกเวลาเมื่อยอมรับการเชื่อมต่อ และตัวรวบรวมบันทึกเวลาเมื่อข้อความมาถึง ดังนั้นช่องว่างระหว่างสองเวลาคือเวลาขนส่ง ช่องว่างนั้นบอกอะไรบางอย่างเกี่ยวกับท่อบันทึก ไม่ใช่เกี่ยวกับเซสชัน VPN ติดป้ายว่าเป็นเวลามาถึง แล้วมันจะเลิกแข่งขันกับเวลาเหตุการณ์

เชื่อมโยงโดยไม่เขียนหลักฐานใหม่

เก็บการประทับเวลาเดิมไว้ และเพิ่มคอลัมน์ที่คำนวณขึ้นหากต้องการมุมมองร่วม อธิบายการแปลงในบันทึกย่อแทนการแก้ไขระเบียนต้นฉบับ เพราะต้นฉบับคือสิ่งที่ผู้ตรวจทานภายหลังจะตรวจ รักษาเวลามาถึงของตัวรวบรวมแยกไว้ทุกที่ที่มี

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

การเปลี่ยนนาฬิกาของอุปกรณ์ไม่ใช่การควบคุมความเป็นส่วนตัว และไม่เขียนระเบียนที่ระบบอื่นถืออยู่แล้วใหม่ ยังทำให้เปรียบเทียบหลักฐานสนับสนุนได้ยากขึ้น และอาจทำให้การตรวจสอบใบรับรองและโค้ดที่ขึ้นกับเวลาพัง รักษานาฬิกาให้ซิงโครไนซ์สำหรับการทำงานปกติ และถือว่าการเบี่ยงเบนโดยเจตนาเป็นข้อบกพร่องที่ต้องสอบสวน ถ้าสองระเบียนดูเหมือนไม่อยู่ในลำดับ ให้ดูการซิงโครไนซ์นาฬิกาและการส่งก่อนสร้างประวัติใหม่

ความเชื่อผิดที่ควรทิ้งคือมีเวลา VPN เดียว ถามว่าแต่ละฟิลด์เขียนอะไรและเกิดอะไรขึ้นเมื่อเขียน แล้วไทม์ไลน์จะกลายเป็นชุดการสังเกตที่มีป้ายกำกับแทนที่จะเป็นความขัดแย้ง