কীভাবে একটি SSH লোকাল ফরোয়ার্ড TCP OpenVPN সেশন বহন করে

এখানে তিনটি ট্রান্সপোর্ট স্তর স্তূপ হয়ে আছে, এবং প্রতিটির নিজস্ব ফ্রেমিং রয়েছে। VPN পেলোড একটি TLS সেশনের ভিতরে যায়, সেই TLS সেশন একটি লুপব্যাক পোর্টে TCP সংযোগের ভিতরে যায়, আর সেই সংযোগের বাইটগুলি SSH-এর ভিতরে একটি রিলে হোস্টে যায়, যা VPN শ্রোতার সাথে প্রকৃত TCP সংযোগ খোলে। এই বিন্যাসের কিছুই বদলায় না যা OpenVPN প্রমাণ করে, এবং এর কিছুই UDP শ্রোতাকে TCP দিয়ে পৌঁছানোযোগ্য করে না। বাকিটা বাইট পথের বর্ণনা হিসেবে পড়ুন, নেটওয়ার্ক নিয়ন্ত্রণ এড়ানোর রেসিপি হিসেবে নয়।

লোকাল ফরোয়ার্ড আসলে কী সরায়

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

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

SSH সেশন শুরু করা কেবল প্রমাণ করে যে রিলে পৌঁছানোযোগ্য ও প্রমাণিত। এটি বলে না পরবর্তী শ্রোতা চালু আছে কি না, রিলে ও শ্রোতার মাঝের ফায়ারওয়াল সংযোগ গ্রহণ করে কি না, বা VPN আপনার প্রোফাইল গ্রহণ করবে কি না।

ক্লায়েন্টকে লোকাল শ্রোতার দিকে ঘোরান

ঘোষিত উদাহরণ: রিলে gw.internal.example:443-এ একটি TCP শ্রোতায় পৌঁছাতে পারে, আর একটি উঁচু লোকাল পোর্ট সেই পথ কেবল এই মেশিনের জন্য খোলে।

ssh -N -L 127.0.0.1:24011:gw.internal.example:443 [email protected]

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

তারপর VPN ক্লায়েন্টকে TCP মোডে সেট করুন এবং 127.0.0.1:24011-এ নির্দেশ করুন। প্রোফাইল UDP ব্যবহার করলে এই নকশা সাহায্য করতে পারে না: ফরোয়ার্ড বাইট স্ট্রিম বহন করে, আর এর ভিতর দিয়ে ডেটাগ্রামের পথ নেই।

দুটি প্রমাণীকরণ আলাদা রাখুন

SSH রিলে হোস্টকে প্রমাণ করে। OpenVPN এখনও VPN পিয়ারকে প্রমাণ করে, এবং লুপব্যাক গন্তব্য সেই শর্ত বদলায় না। সকেট এখন localhost-এ নির্দেশ করে বলে সার্টিফিকেট যাচাই বন্ধ করা এই নকশার সবচেয়ে খারাপ শর্টকাট। এটি ট্রান্সপোর্ট বিন্যাসকে বিশ্বাসের বিন্যাসে বদলে দেয়, আর দ্বিতীয়টিতে কেউ সম্মতি দেয়নি।

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

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

টানেলের নিচে লুপ বানাবেন না

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

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

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

কাজ শেষ হলে শ্রোতা বন্ধ করুন

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

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