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

একটি নয়, দুটি রেকর্ড

নিচের সংযোগের কী হয়েছে আর টানেল নিজে কী করেছে তা আলাদা করে লিখুন। তারপর অ্যাপ্লিকেশনের বিরতিকে দুই রেকর্ডের পাশে রাখুন। এগুলো স্বাধীন ঘটনাপ্রবাহ যা মাঝে মাঝে মিলে যায়, আর তিনটিকেই বিচ্ছিন্নতা বলা মানে শুরুতেই উত্তর ধরে নেওয়া।

মিনিটে একবার পরীক্ষা করা মনিটর দুই সেকেন্ডের বাধা দেখতে পায় না। সেদিনকে সুস্থ বলে রিপোর্ট করা কারিগরিভাবে সঠিক আর বাস্তবে অকেজো। আপনি যে ফলাফল উদ্ধৃত করেন তার পাশে স্যাম্পলিং ব্যবধান লিখুন।

অ্যাপ জমে থাকার সময় অ্যাক্সেস লিংক কী করেছিল

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

প্রথমে রুট নিশ্চিত করুন, কারণ একটি পাবলিক লক্ষ্য নিজেই টানেল দিয়ে রাউট হতে পারে এবং তখন টানেল মাপে, অ্যাক্সেস পথ নয়। যে প্রমাণ সত্যিই বিভ্রাটের তারিখ ঠিক করে তা এক স্তর নিচে: রাউটারে লিংক ইভেন্ট, মডেমে রিসিঙ্ক রেকর্ড আর বদলে যাওয়া WAN ঠিকানা। ক্রমপুঞ্জিত ত্রুটি কাউন্টার বলে কিছু ভুল হয়েছে, কখনও বলে না কখন। সেই রেকর্ডগুলো একা পড়ার বদলে ঘটনার সময়-জানালার সঙ্গে মিলিয়ে দেখুন।

ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address show

গতকাল বেড়ে যাওয়া কাউন্টার আজ সকালের জমাট সম্পর্কে কিছুই ব্যাখ্যা করে না। সম্পর্ক নির্ণয় ব্যবহারকারীর জানানো জানালার মধ্যে সীমাবদ্ধ রাখুন।

রিস্টার্ট রেকর্ড খুঁজুন

হারানো UDP ডেটাগ্রাম নিজে থেকে Community OpenVPN-কে নতুন TLS সমঝোতা শুরু করায় না। রিস্টার্টের আচরণ ping-restart অনুসরণ করে, আর বলবৎ মান সার্ভার থেকে চাপিয়ে দেওয়া হতে পারে; 2.6 ম্যানুয়াল সেই টাইমারগুলো সংজ্ঞায়িত করে। ডেলিভারি এক মুহূর্তের জন্য ভাঙে, থ্রেশহোল্ড কখনও পার হয় না, আর লগ খালি থাকে। তাই বিরতির আশপাশে লগে রিস্টার্ট লাইন, নতুন সংযোগ বা বদলে যাওয়া সেশন শনাক্তকারী খুঁজুন। তিনটির একটিও না মিললে টানেল সম্ভবত কিছুই করেনি আর টাইমারই কখনও সমস্যা ছিল না।

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

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

কী সারাতে হবে তা তুলনাই ঠিক করুক

দুই রেকর্ড পাশাপাশি থাকলে দায়িত্ব বণ্টন সাধারণত নিজেই লেখা হয়ে যায়। দুই পথেই রাউটার লিংক ইভেন্ট মানে অ্যাক্সেস সংযোগই বিষয়। নিঃশব্দ টানেল আর ব্যবহারযোগ্য সাধারণ পথ মানে সমঝোতাই বিষয়।

What you observedTunnel log at that secondWhere to look next
two-second pause, plain path answers throughoutnothingthe monitor's resolution, then a loss burst
pause plus a router link event, plain path stops and returnsno restart linethe access link, not the tunnel timer
pause, then a new session identifierrestart linethe restart threshold and what triggered it
one application freezes while both paths answernothingthat application and its server-side work

প্রতিটি সারি সূত্র, রায় নয়: প্রান্তবিন্দু ICMP-কে কম অগ্রাধিকার দেয়, আর দুটি গন্তব্য অগত্যা একই পথ ভাগ করে না। তুলনা আদৌ সম্ভব হতে ক্লায়েন্ট, গেটওয়ে আর অ্যাপ্লিকেশনের ঘড়ি মিলিয়ে রাখুন। যে সারি দুই কলামে মেলে তার আরেকটি পর্যবেক্ষণ দরকার, সিদ্ধান্ত নয়।

পর্যালোচনা টিকিয়ে দেওয়া প্রতিবেদন চারটি প্রশ্নের উত্তর দেয়: জমাট কতক্ষণ ছিল, কোন পথগুলো উত্তর দিতে থাকে, সেই সেকেন্ডে টানেল কী লগ করেছে আর মনিটর কত ঘন ঘন নমুনা নেয়। এই চারটি তথ্য পরের পাঠককে সারাংশে ভরসা করার বদলে পর্যবেক্ষণটি পুনরুৎপাদন করতে দেয়। আপটাইম শতাংশ ঠিক যে ব্যবধানটি আপনার দরকার সেটিই লুকায়, আর "VPN পড়ে গেছে" বাক্যটিও।

সম্পর্কিত নিবন্ধ