একটি 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 সময় আছে। প্রতিটি ক্ষেত্র কী লিখেছে এবং তা করার সময় কী ঘটেছে জিজ্ঞাসা করুন, তাহলে সময়রেখা বিরোধ নয়, চিহ্নিত পর্যবেক্ষণের সমষ্টি হয়ে ওঠে।