ষাট সেকেন্ডের TLS টাইমআউট: কোন প্রান্তটি আসলে থেমে গিয়েছিল?

ক্লায়েন্ট ষাট সেকেন্ড পর কী-সমঝোতা নিয়ে একটি বার্তা দিয়ে হাল ছেড়ে দেয়, আর ল্যাপটপ কেন তা নিয়ে কোনো মত দেয় না। ওই বাক্যটি ক্লায়েন্টের ধৈর্যের বর্ণনা, সার্ভারের আচরণের নয়। তিনটি সম্পূর্ণ ভিন্ন পরিস্থিতি এটি ঘটায়: প্যাকেটটি কখনো সঠিক সেবায় পৌঁছায়নি, সেবাটি কিছু লগ করার আগেই তা ফেলে দিয়েছে, অথবা সেবাটি তা প্রত্যাখ্যান করেছে এবং এমন জায়গায় জানিয়েছে যা ক্লায়েন্ট দেখতে পায় না। দুটি প্রান্তে একটি প্রচেষ্টার মিলকরণই এদের আলাদা করে।

একটি প্রচেষ্টাকে এমন পরিচয় দিন যা আপনি খুঁজে পাবেন

শুরুর সময় তার সময় অঞ্চলসহ লিখে রাখুন, প্রোফাইলের নাম, ক্লায়েন্ট যে গন্তব্য আসলে সমাধান করেছে, পোর্ট, এবং সংযোগটি UDP না TCP। প্রোফাইলে যদি একাধিক দূরবর্তী এন্ট্রি থাকে, ওই প্রচেষ্টা কোনটি বেছে নিয়েছিল তা টুকে রাখুন, কারণ পুনরায় চেষ্টা আপনি যে ফাইল পড়ছেন তা না বদলেই পরের এন্ট্রিতে চলে যেতে পারে।

প্রান্তবিন্দুটি আপনার মনে থাকা ডাউনলোড থেকে নয়, সক্রিয় লগ থেকে নিন। ব্যক্তিগত ঠিকানায় নির্দেশ করা প্রোফাইল সম্পূর্ণ বৈধ এবং এমন নেটওয়ার্ক থেকে সম্পূর্ণ অব্যবহারযোগ্য যা সেখানে রুট করতে পারে না, আর সেই অবস্থাটি বন্ধ সার্ভারের মতোই দেখায়।

তারপর অপারেটরের কাছে উদ্দিষ্ট ইনস্ট্যান্সে একই সময়-জানালা চান। ঘড়ির ব্যবধান এতই সাধারণ যে কয়েক মিনিটের পার্থক্য একটি মিলে যাওয়া ঘটনাকে অনুপস্থিত দেখাতে পারে, তাই কোনো ঘটনা ছিল না বলে সিদ্ধান্তে আসার বদলে পার্থক্যটি লিখে রাখুন।

চারটি পর্যবেক্ষণ, চারটি ভিন্ন পরবর্তী পদক্ষেপ

সার্ভার কী রেকর্ড করে তা শাখাটি নির্ধারণ করে। কোনো প্রচেষ্টার অনুপস্থিতি ঠিকানা, পরিবহন বা সেবার পথের দিকে ইঙ্গিত করে। সাধারণ বিনিময়ের আগে হারিয়ে যাওয়া আগত প্যাকেটগুলি প্রকৃত সেবার নিয়ন্ত্রণ-চ্যানেলের প্রয়োজনীয়তার দিকে ইঙ্গিত করে। নামসহ প্রত্যাখ্যান তার নাম দেওয়া বস্তুর দিকে ইঙ্গিত করে। যে উত্তরগুলি সার্ভার ছেড়ে যায় কিন্তু ক্লায়েন্টে কখনো পৌঁছায় না, সেগুলি ফেরার পথের দিকে ইঙ্গিত করে।

খালি অ্যাপ্লিকেশন লগ দেখতে যতটা সহজ, ততটা দুর্বল প্রমাণ নয়। লগিং বিনিময়ের একটি নির্দিষ্ট বিন্দু থেকে শুরু হয়, আর সেই বিন্দুর আগে ফেলে দেওয়া প্যাকেট আপনি যে ফাইল পড়ছেন তাতে কোনো চিহ্ন রাখে না। যেখানে অনুমোদিত, সেখানে অপারেটর সেবা ও নেটওয়ার্ক পর্যবেক্ষণ ব্যবহার করে দেখতে পারেন আদৌ কিছু পৌঁছেছে কি না।

আপনার নোটে চারটি ফলাফল আলাদা রাখুন। প্রলোভন হলো এগুলিকে “সার্ভার সাড়া দিচ্ছে না”-তে মিশিয়ে ফেলা, আর এই বাক্যাংশই মানুষকে সাইফার বদলাতে পাঠায় যখন আসল সমস্যা ফায়ারওয়াল নিয়ম। যে নোট কেবল টাইমআউট শব্দটি লিখে রাখে, সে এইমাত্র যে পার্থক্যের জন্য মূল্য দিলেন তা ফেলে দিয়েছে।

প্রমাণ যে ধাপটির নাম দেয় সেই ধাপটি ঠিক করুন

সম্পূর্ণ হওয়া একটি TCP সংযোগ কেবল প্রমাণ করে যে কিছু একটি সকেট গ্রহণ করেছে। এটি প্রমাণ করে না যে শ্রোতাটি আপনার কনফিগার করা OpenVPN সেবা, আর একই হোস্টনামের একটি ওয়েব সার্ভার ব্রাউজারকে নিখুঁতভাবে উত্তর দেয় অথচ টানেলের সঙ্গে এর কোনো সম্পর্ক নেই।

সার্ভার যদি মেয়াদোত্তীর্ণ প্রত্যাহার তালিকা রিপোর্ট করে, তবে তা ক্লায়েন্টের শেষ পর্যন্ত টাইমআউটের চেয়ে অনেক বেশি নির্দিষ্ট তথ্য, আর সমাধানটি নেটওয়ার্কের নয়, সার্টিফিকেট কর্তৃপক্ষের। দুই প্রান্ত যদি নিয়ন্ত্রণ-চ্যানেল সুরক্ষা বা ভাগ করা উপাদান নিয়ে একমত না হয়, তবে পাসওয়ার্ড রিসেট করলে কিছুই বদলায় না, কারণ কোনো শংসাপত্র যাচাই হওয়ার আগেই বাতিলটি ঘটে।

প্রমাণ সত্যিই যে একটি পরিবর্তনকে সমর্থন করে তা করুন, তারপর একই প্রোফাইল একই প্রান্তবিন্দুর বিরুদ্ধে পুনরাবৃত্তি করুন। সংযোগ আরও এগোলে প্রথম নতুন ঘটনাটি সংরক্ষণ করুন, কারণ সেই ঘটনাটি নতুন সমস্যা নয়, তদন্তের পরবর্তী ধাপ।

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

জানালা বাড়ানো আসলে কী বদলায়

ষাট সেকেন্ড হলো ক্লায়েন্টের হ্যান্ডশেক জানালা, আর কমিউনিটি ক্লায়েন্ট রেফারেন্স যে অপশনটি তা সমন্বয় করে তা নথিভুক্ত করে। এটি বাড়ালে ক্লায়েন্ট হাল ছাড়ার আগে বেশি সময় অপেক্ষা করে। এটি অনুপস্থিত সেবাকে হাজির করে না এবং প্রত্যাখ্যাত প্যাকেটকে গ্রহণযোগ্য করে না।

ধীর লিঙ্ক বা ভারী বোঝাই সার্ভারে দীর্ঘতর জানালার বৈধ ব্যবহার আছে, আর বিনিময় ধীরে এগোচ্ছে—ঘটছে না তা নয়—এমন প্রমাণ পেলে এটি একবার চেষ্টা করা উচিত। প্রথমেই এটি চেষ্টা করা একই রোগনির্ণয়কে আরও এক মিনিট দেরি করায় এবং সময়রেখা পড়া কঠিন করে তোলে। সময়রেখা যদি এমন বিনিময় দেখায় যা এগিয়ে গিয়ে থেমে যায়, তবে জানালাটি পৌঁছানোর নয়, বোঝাইয়ের উপসর্গ।