एउटै 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 समय हुन्छ भन्ने हो। हरेक क्षेत्रले के लेख्यो र त्यसो गर्दा के भयो भनी सोध्नुहोस्, अनि समयरेखा विरोधाभास होइन, लेबल गरिएका अवलोकनहरूको समूह बन्छ।