কিল সুইচ চালু হলো: খোলা TCP সেশনগুলোর কী হয়?

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

ফেলে দেওয়া, প্রত্যাখ্যান ও রিসেট আলাদা

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

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

ফাঁক চলাকালে অ্যাপ্লিকেশন কী করে

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

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

পুনরুদ্ধার দরকার কি না ঠিক করুন

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

স্থিতিশীল ঠিকানা হলো সেই অংশ যা মানুষ ভুলে যায়, কারণ ভিন্ন পাবলিক ঠিকানায় গিয়ে পড়া পুনঃসংযোগ ক্লায়েন্টের সকেট সুস্থ দেখালেও সার্ভার-পক্ষের অবস্থাকে অকার্যকর করে দেয়। প্রতিটি অ্যাপ্লিকেশনে দুটি চুক্তির কোনটি প্রযোজ্য তা লিখে রাখুন, কারণ সেগুলো খুব কমই সব মেলে।

ব্লক ও পুনরুদ্ধার আলাদাভাবে পরীক্ষা করুন

লিক সুরক্ষা ও সেশন টিকে থাকাকে দুটি আলাদা বৈশিষ্ট্য ধরুন, কারণ একটি উত্তীর্ণ হলে অন্যটি সম্পর্কে কিছুই বোঝায় না। টিকে থাকা সেশন এটা প্রমাণ নয় যে সরাসরি ট্রাফিক ব্লক হয়েছিল, আর মরে যাওয়া সেশন এটা প্রমাণ নয় যে প্রতিটি সরাসরি পথ ব্লক হয়েছিল।

ss -tnp state established '( dport = :443 )'
sudo conntrack -L -p tcp --dport 443
sudo tcpdump -ni any 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

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

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