خط زمانی یک حادثه 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 وجود دارد. بپرسید هر فیلد چه نوشته و وقتی این کار را کرده چه رخ داده، و خط زمانی به مجموعه‌ای از مشاهدات برچسب‌خورده تبدیل می‌شود، نه به تناقض.

مقالات مرتبط