Keepalive কোনো পুনঃসংযোগ নয়: যে ব্যর্থতা আছে তা দিয়েই বাছুন
একটি প্যাকেট ম্যাপিং সচল রাখে; পুনঃসংযোগ সম্পর্কটি নতুন করে গড়ে। ব্যর্থতার সঙ্গে প্রক্রিয়াটি মেলান, তারপর সত্যিকারের অনুরোধ দিয়ে যাচাই করুন।
Keepalive আর পুনঃসংযোগ একই নিশ্বাসে কনফিগার করা হয়, কিন্তু ভিন্ন সমস্যার সমাধান করে, তাই একটির টিউনিং অন্যটিকে বিরলভাবে ঠিক করে। Keepalive অল্প ট্রাফিক পাঠিয়ে একটি স্টেট এন্ট্রি সচল রাখে বা কোনো পিয়ার উত্তর দেওয়া বন্ধ করেছে তা লক্ষ করে। পুনঃসংযোগ যা ভাঙা তা গুছিয়ে ফেলে এবং সম্পর্কটি আবার গড়ে, যার মধ্যে কী, ঠিকানা ও রুট আছে। যে প্রক্রিয়াটি ব্যর্থতার সঙ্গে মেলে সেটিই বাছুন, যে নবটা আপনি আগে থেকেই জানেন সেটি নয়। দুটি প্রশ্ন এটি নির্ধারণ করে: পথটি কি মৃত, নাকি পিয়ারদের মাঝখানে কিছু এটি ভুলে যাচ্ছে?
যখন ম্যাপিংই সমস্যা
কেবল কয়েক মিনিট নীরবতার পর মরে যাওয়া টানেল সাধারণত পিয়ার নয়, একটি অনুবাদ এন্ট্রি হারায়। WireGuard-এর PersistentKeepalive NAT ও ফায়ারওয়াল স্টেটের জন্য আছে, আর প্রকল্পের নিজস্ব নোট এটিকে ঠিক এভাবেই বর্ণনা করে, স্বাস্থ্য-পরীক্ষা হিসেবে নয়। কয়েক দশ সেকেন্ডের ব্যবধান একটি এন্ট্রি উষ্ণ রাখে, আর প্রতি সেকেন্ডে একটি প্যাকেট ব্যাটারির সিদ্ধান্ত, নির্ভরযোগ্যতার নয়। OpenVPN একই জায়গায় পৌঁছায় ping ও ping-restart দিয়ে, যারা আগে নীরবতা লক্ষ করে তারপর তার উপর কাজ করে।
এই সেটিংস প্রোটোকলগুলোর মধ্যে বিনিময়যোগ্যও নয়। IKEv2-এর মৃত-পিয়ার নীতি, OpenVPN-এর ping টাইমার আর WireGuard-এর keepalive একই প্রশ্নের উত্তর দেয় তিনটি ভিন্ন সিনট্যাক্স ও তিনটি ভিন্ন ডিফল্ট দিয়ে, তাই এদের মধ্যে সংখ্যা কপি করা টিউনিংয়ের পোশাক পরা অনুমান।
যখন সম্পর্কটি আর নেই
পিয়ার ঠিকানা বদলালে, ক্রেডেনশিয়ালের মেয়াদ শেষ হলে বা অপর প্রান্ত রিস্টার্ট হলে ছোট প্যাকেট কোনো সমাধান নয়। পুনঃসংযোগকে স্টেট আবার গড়তে হবে : ঠিকানা নিন, রুট আবার ইনস্টল করুন, কী নিয়ে আবার দরকষাকষি করুন, আর কিছু ডিপ্লয়মেন্টে ব্যবহারকারীকে আবার প্রমাণীকরণ করুন।
যে ক্লায়েন্টরা নজরদারি ছাড়া পুনঃসংযোগ করে তারা একটি সার্টিফিকেট বা সংরক্ষিত গোপন তথ্য ধরে রাখে। যে ক্লায়েন্ট মানুষকে জিজ্ঞাসা করবে সে ঠিক তখনই ব্যর্থ হয় যখন কেউ উপস্থিত নেই, আর সেটাই সেই পরিস্থিতি যেখানে পুনঃসংযোগ গুরুত্বপূর্ণ ছিল। এটি মাসখানেক আগে নেওয়া একটি নকশা-সিদ্ধান্ত, আউটেজের সময় বদলানো কোনো সেটিং নয়।
দুটির কোনোটিই কী প্রমাণ করে না
টানেল পুনঃসংযুক্ত, কী-যুক্ত ও রুটযুক্ত থাকতে পারে অথচ তার পেছনের সেবাটি বন্ধ, আর keepalive একটি ম্যাপিং খোলা রাখতে পারে এমন সেশনের জন্য যার সার্ভার ঘণ্টাখানেক আগেই চলে গেছে। আপনার আসল যত্নের জিনিসটি অনুপলব্ধ থাকলেও দুটি প্রক্রিয়াই সফলতা রিপোর্ট করতে পারে।
তাই পরীক্ষাটি শেষ হয় একটি সত্যিকারের অনুরোধে। আপনার যত্নের ব্যবধানের পরে টানেল দিয়ে কিছু পাঠান, তারপর আপনি যে ব্যর্থতার জন্য নকশা করেছেন তা আলাদা করে ঘটান: ম্যাপিংয়ের ক্ষেত্রে একটি নিষ্ক্রিয় সময়কাল, পুনঃসংযোগের ক্ষেত্রে একটি রিস্টার্ট বা ঠিকানা পরিবর্তন।
সরাসরি ট্রাফিক আটকানো আলাদা সিদ্ধান্ত
একটি পুনঃসংযোগ লুপ পুরোপুরি সুস্থ থাকতে পারে অথচ একটি অ্যাপ্লিকেশন চুপচাপ সাধারণ রুট ব্যবহার করছে, আর এটি ব্যর্থতা নয়, ফাঁস। যদি শর্ত হয় যে টানেলের বাইরে কিছুই যাবে না, তবে ক্লায়েন্ট কনফিগারেশনে তা স্পষ্টভাবে বলুন এবং টানেল নামিয়ে কী এখনো সংযোগ করছে তা দেখে প্রমাণ করুন। কোনোটিই এই আচরণ বোঝায় না, আর পুনঃচেষ্টার কোনো শৃঙ্খলা এটি প্রতিষ্ঠা করে না।
কোন প্রক্রিয়া চলেছিল এবং পরে একটি নতুন অনুরোধ সফল হয়েছিল কি না তা লিখে রাখুন। পরবর্তী ইঞ্জিনিয়ারের প্রয়োজন এই দুটি তথ্য, আর কোনোটিই স্টেটাস আইকনে দেখা যায় না। ক্লায়েন্ট পুনঃসংযোগ করেছে বলে একটি লগ লাইন আর কাজ করা অনুরোধ এক নয়।
নীতি লিখুন, শুধু সংখ্যা নয়
জোড়াটিকে এক বাক্যে রাখুন: নিষ্ক্রিয়তার ব্যবধান, সচলতার সীমা, কী পুনর্নির্মাণ ঘটায় , আর পুনঃচেষ্টার সময় ক্লায়েন্ট কী করে। সেই বাক্য ছাড়া প্রতিটি ভবিষ্যৎ ঘটনা একই তর্ক আবার খোলে—keepalive খুব ছোট নাকি পুনঃসংযোগ খুব ধীর।
সীমাবদ্ধতা নিয়ে WireGuard-এর নোট একটি দরকারি মনে করিয়ে দেওয়া যে keepalive মিডলবক্সের জন্য একটি ঘুরপথ, সচলতার সাধারণ নকশা নয়। যে সমস্যা এটি সমাধান করতে পারে না তার জবাবে ফ্রিকোয়েন্সি বাড়ানোর আগে সেই সীমাবদ্ধতা পড়ুন।