হোস্ট যখন আউটবাউন্ড VPN চালায়, তখন লোকাল SSH রাখুন

একটি ছোট Linux সার্ভার যে অ্যাপ্লিকেশনটি হোস্ট করে তার জন্য আউটবাউন্ড VPN চালায়, আর প্রশাসক এখনও পাশের ঘর থেকে SSH দিয়ে এটিতে পৌঁছাতে চান। এটি যুক্তিসঙ্গত চাহিদা, এবং সাধারণত এতে কোনো পোর্ট ফরওয়ার্ডিং, কোনো প্রোভাইডার ঠিকানা এবং টানেলে কোনো ফুটো লাগে না। যা দরকার তা হলো ইচ্ছাকৃতভাবে নকশা করা একটি ব্যবস্থাপনা পথ, যা VPN ক্লায়েন্ট রাউটিং টেবিলে যা করেছে তা থেকে উত্তরাধিকারসূত্রে পাওয়া নয়।

নিচের ধাপগুলি ধরে নেয় যে প্রশাসক একই LAN-এ আছেন।দূরবর্তী প্রশাসন ভিন্ন উত্তরসহ একটি ভিন্ন সমস্যা।

SSH-কে প্রশাসকেরা যে ঠিকানা ব্যবহার করেন সেখানে বেঁধে দিন

লিসেনার থেকে শুরু করুন।ss -ltnp | grep :22 দেখায় sshd কোথায় বাঁধা, আর 0.0.0.0-তে লিসেনার টানেলসহ প্রতিটি ইন্টারফেস থেকে সংযোগ গ্রহণ করে। LAN ঠিকানায় বাঁধা আরও সংকীর্ণ এবং উদ্দেশ্য দৃশ্যমান করে:ListenAddress 192.168.10.20 এর মধ্যেsshd_config, এর পরে একটি কনফিগারেশন পরীক্ষা ও পুনরায় লোড। ওই ঠিকানায় টাইপো একটি ওয়াইল্ডকার্ডের চেয়ে বেশি দৃশ্যমান, কারণ ঠিকানাটি না থাকলে sshd চালু হতে অস্বীকার করে।

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

LAN রুট টানেলের বাইরে রাখুন

192.168.10.0/24-এ ঠিকানা থাকা হোস্টের ওই প্রিফিক্সের জন্য সংযুক্ত রুট থাকে, আর একই টেবিলে আরও নির্দিষ্ট রুট VPN-এর ডিফল্টকে হারিয়ে দেয়। সেজন্যই টানেল ওঠার সময় লোকাল SSH প্রায়ই নিজে থেকেই কাজ করতে থাকে। ধরে নেওয়ার বদলে যাচাই করুন:ip route get 192.168.10.50 কার্নেল যে ইন্টারফেস ও সোর্স ঠিকানা ব্যবহার করবে তা বলে, আর উত্তরটি টানেল নয়, LAN ডিভাইস হওয়া উচিত। প্রশাসকের মেশিন থেকেও পরীক্ষাটি পুনরাবৃত্তি করুন, কারণ প্যাকেট আদৌ পৌঁছাবে কি না তা তার নিজের টেবিলই ঠিক করে। একই তারে থাকা দুই হোস্ট কোন দিকটি পৌঁছানো যায় তা নিয়ে দ্বিমত পোষণ করতে পারে।

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

রাউটেড ম্যানেজমেন্ট VLAN হলো অন্য কেস। প্রশাসক যদি লোকাল রাউটারের পিছনে 192.168.50.0/24-এ বসেন, তবে সার্ভারের ওই প্রিফিক্সের জন্য 192.168.10.1 হয়ে স্পষ্ট রুট দরকার, এবং সেই রুটকে পুনঃসংযোগে টিকে থাকতে হবে। ব্যতিক্রমটি ম্যানেজমেন্ট প্রিফিক্সেই সীমিত রাখুন; প্রাইভেট রেঞ্জের প্রশস্ত ব্যতিক্রম টানেলের উদ্দেশ্য ব্যর্থ করে।

ফায়ারওয়াল ব্যতিক্রমকে নিয়মের মতোই সংকীর্ণ করুন

হোস্টে ফায়ারওয়াল চললে SSH কেবল ম্যানেজমেন্ট সোর্স থেকে, কেবল LAN ইন্টারফেসে অনুমোদন করুন। যে নিয়ম সব জায়গা থেকে 22 পোর্ট খোলে তা চাহিদার চেয়ে প্রশস্ত এবং পর্যালোচনায় ন্যায্যতা দেওয়া কঠিন। nftables হোস্টে নিয়মটি ইনপুট চেইনে ইন্টারফেস ও সোর্স মিলিয়ে রাখতে হয়; iptables হোস্টে সমতুল্য হলো-i এবং-s। নিয়মটিতে যে প্রশাসক গোষ্ঠীর জন্য এটি, তা মন্তব্য হিসেবে লিখুন, যাতে পরের অডিটকে 22 পোর্ট কেন খোলা তা অনুমান করতে না হয়।

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

দুই অবস্থাই পরীক্ষা করুন

পরীক্ষাটি দুবার চালান: একবার টানেল সংযুক্ত অবস্থায়, একবার বিচ্ছিন্ন অবস্থায়। প্রতিটি অবস্থায় লিসেনার, রুট এবং প্রশাসকের মেশিন থেকে প্রকৃত SSH লগইন নিশ্চিত করুন। যে পথ কেবল টানেল ওঠা অবস্থায় কাজ করে তা লোকাল ব্যবস্থাপনা পথ নয়; তা কাকতালীয়।

তারপর SSH সেশন খোলা রেখেই টানেল পুনরায় চালু করুন। যে সেশন টিকে থাকে তা প্রমাণ করে রাউটিং স্থিতিশীল; যে সেশন ভেঙে যায় তা বলে ক্লায়েন্ট পুনঃসংযোগে রুট বা ফিল্টার আবার লিখছে, যা ঘটনার আগে জানা ভালো, ঘটনার সময় নয়।

আপনি যে সোর্স ঠিকানা থেকে পরীক্ষা করেছেন তা লিখে রাখুন, কারণ 192.168.10.50-এর জন্য লেখা নিয়ম প্রশাসকের ল্যাপটপ অন্য সাবনেটে গেলে নীরবে ব্যর্থ হয়।

রানবুকে পুনরুদ্ধারের পথ লিখুন

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

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