শুধু IPv6 সংযোগ, IPv4 সেবা: SOCKS প্রক্সি সেতু করে দিক

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

দুটি সকেট, দুটি ঠিকানা-পরিবার

একটি SOCKS5 অনুরোধ গন্তব্যের নাম দেয় তিনটি রূপের একটিতে: আক্ষরিক v4 ঠিকানা, আক্ষরিক v6 ঠিকানা, বা প্রক্সির সমাধান করার জন্য একটি নাম। অনুরোধটি বলে প্রক্সি কোথায় সংযোগ করবে, ক্লায়েন্ট-থেকে-প্রক্সি সংযোগ কেমন দেখায় তা নয়।

এই ঠিকানা-প্রকারগুলোকে একটি বার্তার ভেতরে তিনটি স্বাধীন পছন্দ হিসেবে পড়ুন। IPv6 দিয়ে পৌঁছানো যায় এমন প্রক্সি IPv4 গন্তব্যের সকেট খুলতে পারে, যখন তার কাজ করা IPv4 নির্গমন থাকে এবং তার নীতি অনুরোধটি অনুমোদন করে। SOCKS5 স্পেসিফিকেশন ক্লায়েন্টের পরিবহনের কোনো উল্লেখ ছাড়াই এগুলো সংজ্ঞায়িত করে।

নিয়ন্ত্রিত SSH উদাহরণ

এমন একটি SSH হোস্ট নিন যা ব্যবহারের অনুমতি আপনার আছে, IPv6-তে উত্তর দেয় এবং নিজেই কেবল v4-তে বিদ্যমান HTTPS সেবায় পৌঁছাতে পারে। OpenSSH-এর গতিশীল ফরওয়ার্ডিং আপনার মেশিনে স্থানীয় SOCKS শ্রোতা বসায়, আর লগইন সেশন v6 দিয়ে চলে।

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

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

সেশন চলাকালীন অনুরোধটি এমন দেখায়:

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

লুপব্যাক সংযোগ কোনো IPv4 ইন্টারনেট পথ নয়। আপনার মেশিন থেকে বেরিয়ে যায় v6-এর লগইন সেশন, আর দূরের পক্ষই গন্তব্যের সকেট খোলে। socks5h রূপটি নাম-সমাধানও ওই পক্ষের কাছে ছেড়ে দেয়, যা তখন গুরুত্বপূর্ণ যখন ক্লায়েন্টের নিজস্ব কোনো IPv4 রিজলভার পথ নেই।

গন্তব্য আসলে কী দেখে

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

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

এটি DNS64 বা NAT64 নয়

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

দুটি ব্যবস্থাই একই নেটওয়ার্কে থাকতে পারে, তাই যেটি কাছাকাছি শোনায় সেটি নয়, আপনি সত্যিই যাচাই করেছেন সেটি বর্ণনা করুন।

প্রতিশ্রুতি দেওয়ার আগে পরিধি জানুন

OpenSSH-এর গতিশীল ফরওয়ার্ডিং TCP সংযোগ বহন করে, ইচ্ছামতো IP ট্রাফিক নয়, তাই UDP, ICMP এবং প্রক্সিকে উপেক্ষা করা যেকোনো প্রোটোকলের জন্য ভিন্ন সমর্থিত নকশা দরকার। SSH হোস্ট-কী যাচাই, সার্ভারের ফরওয়ার্ডিং নিষেধাজ্ঞা এবং HTTPS সার্টিফিকেট যাচাই ধরে রাখুন, কারণ প্রক্সি একটি অতিরিক্ত বিশ্বস্ত অংশগ্রহণকারী, পরিচয় যাচাই দুর্বল করার কারণ নয়। লক্ষ্য যদি VPN-এর বাইরের পরিবহন প্রক্সির মধ্য দিয়ে নেওয়া হয়, তবে ধরে নেওয়ার বদলে যাচাই করুন যে দুই প্রান্তই ওই পরিবহন সমর্থন করে; যেকোনো SOCKS শ্রোতা তা রিলে করতে পারবে বলে ধরে নেবেন না।

এর কোনোটিই ক্লায়েন্টকে দ্বৈত-স্ট্যাক করে না, এবং দরকারও নেই। এটি একটি অ্যাপ্লিকেশনকে একটি রিলের মধ্য দিয়ে একটি সেবায় পৌঁছাতে দেয়, যা ছোট একটি দাবি এবং যাচাই করা অনেক সহজ।