VPN-এ SSH ServerAliveInterval: প্রোবটি কোন প্রান্ত পাঠায়?

SSH সেশন সচল রাখার বেশিরভাগ পরামর্শ «ServerAliveInterval 30 যোগ করুন» বলেই থেমে যায় এবং কাজের অংশগুলো বাদ দেয়। কীওয়ার্ডটি ক্লায়েন্ট প্রান্তের একটি টাইমার যা কেবল তখনই চলে যখন চ্যানেল নীরব থাকে, এটি সেকেন্ড নয় বরং উত্তরহীন প্রোব গোনে, এবং এটি এমন একটি ফাইলে থাকে যেখানে প্রথম মিলে যাওয়া মান জেতে। এই তিনটি বৈশিষ্ট্য ভুল করলে একটি সুস্থ VPN সেশনও ঝরে পড়বে, আর একটি মৃত সেশন ঝুলে থাকবে।

দুটি দিক দুটি ভিন্ন ডিমনের

ServerAliveInterval আপনার ssh ক্লায়েন্ট পড়ে। ClientAliveInterval দূর প্রান্তের sshd পড়ে এবং উল্টো দিকে, সার্ভার থেকে ক্লায়েন্টের দিকে প্রোব পাঠায়। এরা সমার্থক নয় এবং একসাথে কাজ করে না, তাই একটি সেট করলে অন্য প্রান্তের আচরণে কোনো প্রভাব পড়ে না। এদের গুলিয়ে ফেলা সাধারণত এমন একটি কারণ যে একটি ফিক্স এক হোস্টে কাজ করে আর পরেরটিতে করে না।

দুটোই শূন্য গ্রহণ করে। শূন্যে ক্লায়েন্ট কিছুই পাঠায় না, আর সার্ভার প্রান্তে শূন্য ClientAliveCountMax উত্তরহীন চেকের পরে যে সংযোগ বিচ্ছিন্ন হওয়ার কথা তা নিষ্ক্রিয় করে দেয়।

প্রোব কী প্রমাণ করে, আর কী করে না

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

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

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

ক্রম ঠিক করে কোন মান টিকে থাকবে

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

কমান্ড-লাইনের অপশন ফাইলের উপরে জেতে, যা একটি সাময়িক পরীক্ষা সস্তা করে তোলে:

ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=4 office-shell

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

ssh -G office-shell | grep -i alive

টানেলের উপর কীওয়ালিভগুলো কী করে

পর্যায়ক্রমিক ট্রাফিক একটি স্টেটফুল NAT বা ফায়ারওয়াল ম্যাপিংয়ের মেয়াদ শেষ হওয়া আটকায়, যা এমন VPN-এ সত্যিকারের সুবিধা যার গেটওয়ে কয়েক মিনিট পরে নিষ্ক্রিয় প্রবাহ ফেলে দেয়। প্রতি 60 সেকেন্ডে আসা প্রোব কোনো অ্যাপ্লিকেশন ডেটা না নিয়েই সেই ম্যাপিং সতেজ করে।

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

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

সেটিংটি শুরু থেকে শেষ পর্যন্ত নিশ্চিত করা

সার্ভারে ফাইল পড়ে কোন ইনক্লুড জিতেছে তা অনুমান করার বদলে কার্যকর ডেমন কনফিগ ডাম্প করুন:

sshd -T | grep -i clientalive

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

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