SSH ফরওয়ার্ড আসলে কোন অ্যাপের ট্র্যাফিক বহন করে?

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

কিছু তুলনা করার আগে ইন্টারফেসের নাম দিন

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

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

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

স্থানীয়, দূরবর্তী ও ডাইনামিক ফরওয়ার্ড কে শোনে সে বিষয়ে ভিন্ন

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

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

প্রথম কমান্ডটি ল্যাপটপে পোর্ট 5432 বাঁধে এবং বাস্টিয়ন থেকে যেভাবে দেখা যায় সেইভাবে ডেটাবেসে ফরওয়ার্ড করে। দ্বিতীয়টি পোর্ট 1080-এ একটি SOCKS প্রক্সি তৈরি করে। তৃতীয় কমান্ডটি নিশ্চিত করে কোন প্রক্রিয়াগুলো সত্যিই শোনছে, এবং এটাই একমাত্র প্রমাণ যে ফরওয়ার্ডটি বিদ্যমান, পোর্ট দ্বন্দ্বে নীরবে ব্যর্থ হয়নি।

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

টানেল-ডিভাইস মোডই একমাত্র প্রকৃত নেটওয়ার্ক ব্যতিক্রম

OpenSSH -w টানেল-ডিভাইস ফরওয়ার্ডিংও সমর্থন করে, যা TCP লিসেনারের বদলে একটি পয়েন্ট-টু-পয়েন্ট ইন্টারফেস পার করে। এটি সত্যিকারের নেটওয়ার্ক টানেল, এবং এটি সচেতনভাবেই কনফিগার করা হয়, শেল খোলার পার্শ্বপ্রতিক্রিয়া নয়।

sudo ssh -w 0:0 [email protected]
ip addr show tun0

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

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

আপনার অ্যাপটি আপনার তৈরি করা ইন্টারফেস ব্যবহার করে কিনা পরীক্ষা করুন

যাচাইকরণ প্রতিটি অ্যাপের জন্য, সেশনের জন্য নয়। কাজ করা ফরওয়ার্ড প্রমাণ করে পোর্টটি বাঁধা আছে এবং দূর প্রান্ত ডায়াল করতে পারে; এটি প্রমাণ করে না যে আপনার গুরুত্বপূর্ণ প্রোগ্রামটি এর মধ্য দিয়ে সংযোগ করেছিল।

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

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

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