एक 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 समय होता है। पूछें कि हर फ़ील्ड ने क्या लिखा और जब उसने ऐसा किया तब क्या हुआ, और समयरेखा विरोधाभास के बजाय लेबल किए गए अवलोकनों का समूह बन जाती है।