কিল সুইচ পরীক্ষা: শুধু পুনঃসংযোগ নয়, বিরতিটুকু মাপুন

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

দুটি পর্যবেক্ষণ, দুটি আলাদা রায়

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

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

এমন একটি প্রোব তৈরি করুন যা সময় মাপা যায়

এমন একটি অনুরোধ ব্যবহার করুন যা নিরীহ, সস্তা এবং টানেলের নিজস্ব নিয়ন্ত্রণ চ্যানেল থেকে স্বাধীন। নিচের লুপটি প্রতি সেকেন্ডে একবার টাইমস্ট্যাম্প, একটি HTTP স্ট্যাটাস ও অতিবাহিত সময় ছাপে, এবং আটকে না থেকে সোচ্চারে ব্যর্থ হয়:

while true; do
  printf '%s ' "$(date +%H:%M:%S)"
  curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 2 https://example.com || echo "curl-exit-$?"
  sleep 1
done

কেবল স্ট্যাটাস নয়, curl-এর এক্সিট কোড পড়ুন। 28 মানে অনুরোধের সময় শেষ হয়েছে, ব্লক করা পথ এমনই দেখায়। 6 মানে নাম রিজলিউশন ব্যর্থ হয়েছে, এটি ভিন্ন একটি প্রাপ্তি এবং প্রায়ই বেশি আগ্রহের। বিরতির সময় অল্প অতিবাহিত সময়ে 200 মানে ট্রাফিককে বাইরে যেতে দেওয়া হয়েছিল।

আউটপুট একটি ফাইলে লিখে রাখুন। টার্মিনালের স্ক্রলব্যাক প্রমাণ নয়, আর আগ্রহের অংশটি সাধারণত মাঝখানের তিনটি লাইন।

পরিপাটি নয়, সত্যিকারের ব্যর্থতা ঘটান

ক্লায়েন্টের নিজের মেনু থেকে সংযোগ বিচ্ছিন্ন করা সহযোগিতামূলক পথ পরীক্ষা করে, যেখানে ক্লায়েন্টের ব্লকিং নিয়ম বসানোর সময় থাকে। বরং প্রসেসটি মেরে ফেলুন, বা নিচের লিঙ্কটি ছিঁড়ে ফেলুন, তখন আপনি প্রকৃত ব্যর্থতার পথটি পরীক্ষা করছেন।

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

অনুমোদিত ট্রাফিকের চেহারা জানতে লগ পড়ুন

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

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

ss -tunp | grep -E 'ESTAB|SYN-SENT'
ip route get 198.51.100.7
resolvectl status | sed -n '1,20p'

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

ফলাফল এমনভাবে লিখুন যা আপডেটের পরেও টেকে

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

ক্লায়েন্ট আপডেট বা প্রোফাইল পরিবর্তনের পরে একই পরীক্ষা আবার চালান, কারণ ব্লকিং আচরণ বাস্তবায়নের খুঁটিনাটি এবং তা সরে যায়। রেকর্ডের উদ্দেশ্য হলো সরে যাওয়াটি ঘটনার রূপ নেওয়ার আগেই লক্ষ্য করা, ক্লায়েন্টকে একবার প্রত্যয়ন করা নয়।