تبدأ الخط الزمني لحادث 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 واحد. اسأل ما الذي كتب كل حقل وما حدث عندما فعل ذلك، فيصبح الخط الزمني مجموعة ملاحظات موسومة بدلًا من تناقض.

مقالات ذات صلة