VPN-এ SSH প্রতি মিনিটে বিচ্ছিন্ন হয়? সমস্যা keepalive নয়

SSH সংযোগ হয়, প্রায় এক মিনিট কাজ করে, তারপর প্রতিবারই মোটামুটি একই বিরতিতে থেমে যায়। সাধারণ ব্যাখ্যা হলো নিষ্ক্রিয় টাইমআউট, তাই মানুষ MTU কমায় আর ক্লায়েন্ট keepalive সেট করে। আমি যে WireGuard লিঙ্কে কাজ করেছি সেটি ইতিমধ্যে সবই পার হয়েছিল: ছোট টানেল MTU, client-alive সেটিংস, কনফিগার করা টানেল keepalive। বিচ্ছিন্নতা অপরিবর্তিত চলতে থাকে। কারণটি ছিল একটি অসমমিত LAN রুট, আর প্যাটার্নটি চেনার মতো, কারণ এটি টাইমারভিত্তিক প্রতিটি সমাধানকে হারিয়ে দেয়।

keepalive প্রমাণ করে আপনার হোস্ট এখনও পাঠাতে ইচ্ছুক। এটি কোনো স্টেট-রক্ষাকারী ডিভাইসকে এমন উত্তর দেখাতে পারে না যা কখনও তার মধ্য দিয়ে যায় না।

কল্পকাহিনি: keepalive নীরব বিচ্ছিন্নতা সারায়

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

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

লক্ষণ হলো নিয়মিততা, সঙ্গে এমন সেশন যা ওই বিরতির ভেতরে ব্যবহারযোগ্য থাকে। নিষ্ক্রিয় টাইমআউট আঘাত করে যখন কিছুই ঘটে না; এটি আঘাত করে যখন আপনি টাইপ করছেন।

বাড়তি গেটওয়ে আসলে কী করে

ল্যাপটপ ও VPN গেটওয়ে একই LAN-এ রাখুন, আর একটি আলাদা LAN ফায়ারওয়ালকে ডিফল্ট গেটওয়ে বানান। ল্যাপটপ VPN-গামী ট্রাফিক ফায়ারওয়ালে পাঠায়, ফায়ারওয়াল তা গেটওয়েতে পাঠায়, এবং গেটওয়ের উত্তরগুলো সোজা LAN পার হয়ে ল্যাপটপে ফিরে আসে। ওই দ্বিতীয় পা কখনও ফায়ারওয়াল পার হয় না, তাই এর স্টেট টেবিল আধা সংযোগ ধরে রাখে।

নিচের ঠিকানাগুলো ওই বিন্যাসই দেখায়:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

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

এর কিছুই ক্লায়েন্ট কনফিগারেশনে দেখা যায় না, তাই এর খোঁজ সাধারণত ভুল ফাইলে শুরু হয়।

একটি ইচ্ছাকৃত পথ বেছে নিন

উপরের বিন্যাসের জন্য, দূরবর্তী সাবনেটকে সরাসরি VPN গেটওয়েতে রাউট করলে আধা সংযোগটি সরে যায়:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

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

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

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

দুই প্রান্ত থেকেই পরীক্ষা করুন

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

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

কখন অসমমিতি ঠিক আছে

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

টেকসই উত্তরটি দুই পথের নাম বলে, যে ডিভাইসটিকে দুটোই দেখতে হবে তার নাম বলে, এবং যে রুট এটা সম্ভব করে তার নাম বলে। আপনি যদি ডিভাইসটির নাম বলতে না পারেন, তবে আপনি এখনও কারণ খুঁজে পাননি।