एका 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 वेळ असतो हे। प्रत्येक क्षेत्राने काय लिहिले आणि तसे करताना काय घडले हे विचारा, मग कालरेषा विरोधाभास नव्हे तर लेबल केलेल्या निरीक्षणांचा संच बनते।