SSH-এর মাধ্যমে VPN ক্লায়েন্ট চালাচ্ছেন? আগে নিজের রুট পিন করুন

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

শুরু করার আগে পথটি লিখে রাখুন

ip route show default বর্তমান গেটওয়ে ও ইন্টারফেস জানায়, আর ip route get 203.0.113.9 দেখায় আপনার সেশনের জন্য কার্নেল কোন ইন্টারফেস ও সোর্স ঠিকানা ব্যবহার করবে। দুটি আউটপুটই রেখে দিন। টানেল ওঠার পরে ওই দুটি কমান্ডের এখনও ভৌত পথ বর্ণনা করা উচিত, আর যদি তারা এর বদলে টানেল বর্ণনা করে, তবে সেশনটি ইতিমধ্যেই ধার করা সময়ে বেঁচে আছে।

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

ক্লায়েন্টের নিজের কনফিগারেশনে ঠিকানাটি পিন করুন

হাতে যোগ করা রুট রিবুটে হারিয়ে যায় এবং ক্লায়েন্টের নিজের টেবিল হালনাগাদের সঙ্গে প্রতিযোগিতা করে, তাই ব্যতিক্রমটি সেখানে রাখুন যেখানে টেবিলটি পরিচালিত হয়। OpenVPN-এ net_gateway কীওয়ার্ডটি টানেলের আগে যে গেটওয়ে ছিল সেটিতে রিজলভ হয়, তাই route 203.0.113.9 255.255.255.255 net_gateway ঠিক একটি ঠিকানা তার বাইরে রাখে। WireGuard-এর ভিন্ন পদ্ধতি দরকার, কারণ wg-quick নিজেই রুট পরিচালনা করে: Table = off সেট করুন এবং PostUp-এ ব্যতিক্রমটি যোগ করুন, সঙ্গে মিলে যাওয়া PostDown যা সেটি সরায়। উভয় রূপই একই অভিপ্রায় প্রকাশ করে, এবং উভয়ই ব্যতিক্রমটিকে সবকিছুর জন্য টানেল দুর্বল করার বদলে একটি ঠিকানায় সীমাবদ্ধ রাখে।

IPv6-এর ক্ষেত্রে একই ধারণা একক-হোস্ট প্রিফিক্স নেয়, আর মোড়ানো-ট্রান্সপোর্টের ঘটনাটি মনে রাখা দরকার: যদি টানেলের নিজের বাইরের সংযোগ একটি নির্দিষ্ট ঠিকানায় থাকে, তবে সেই ঠিকানাটিকে তার বহন করা টানেলের বাইরে থাকতেই হবে, নইলে ক্লায়েন্ট নিজের ট্রান্সপোর্টকে নিজের ভেতরে রুট করে।

অথবা মূল টেবিলটিকে বিতর্কের বাইরে রাখুন

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

উভয়ই একটি একক হোস্ট রুটের চেয়ে বেশি যন্ত্রকৌশল, এবং বাক্সে একাধিক জিনিসকে টানেল টিকে থাকতে হলে উভয়ই তার যোগ্য।

ধরে নিন পিনটি ব্যর্থ হতে পারে

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

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

যে ক্রমটি গুরুত্বপূর্ণ সেই ক্রমে যাচাই করুন

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

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