VPN-এ Dante SOCKS: সম্পূর্ণ টানেল বনাম সোর্স রাউটিং

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

দুটি নকশা, দুটি আলাদা ক্ষতির পরিধি

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

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

এই সংকীর্ণতাই আবার সীমাবদ্ধতাও: নকশাটি তখনই কাজ করে যদি প্রক্সির বহির্গামী প্যাকেট সত্যিই সেই ঠিকানা বহন করে।

Dante-র external সেটিং কী করে

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

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

নিশ্চিত করুন যে কনফিগার করা ঠিকানাটি প্রক্সির নেটওয়ার্ক নেমস্পেসের ভিতরে সত্যিই টানেলের অন্তর্গত।

সোর্স-নির্বাচিত টেবিল তৈরি করা

10.90.0.2/24 TUN ঠিকানা, 10.90.0.1-এ পৌঁছানো যায় এমন পিয়ার, এবং এমন একটি টেবিল নম্বর যা আর কিছু ব্যবহার করে না—এমন পরিস্থিতিতে বিন্যাসটি এরকম:

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

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

এই মানগুলি একটিমাত্র টপোলজি বর্ণনা করে। পয়েন্ট-টু-পয়েন্ট পিয়ার, net30 অ্যাড্রেসিং এবং ভিন্ন প্রিফিক্স দেওয়া ক্লায়েন্ট—সবাই নিজেদের রুট চায়, তাই ঠিকানা নয়, কাঠামো কপি করুন।

সোর্স নিয়ম কোথায় ফাঁস হয়

সোর্স ঠিকানার সঙ্গে মেলা নিয়ম সেই ঠিকানা ব্যবহার করা প্রতিটি প্রসেসকে প্রভাবিত করে, কেবল প্রক্সিকে নয়। যদি অন্য কোনো ডেমন একই ঠিকানা বাইন্ড করে, তার ট্র্যাফিকও টানেল নেয়, আর ব্যর্থতা অসম্পর্কিত কোনো সার্ভিস সমস্যার মতো দেখাবে। প্রক্সিকে এমন ঠিকানা দিন যা আর কেউ ব্যবহার করে না, অথবা মেনে নিন যে পরিধি প্রসেস নয়, ঠিকানা।

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

IPv6-এর নিজস্ব নিয়ম ও রুট দরকার, কারণ IPv4-এর বিন্যাস তার সম্পর্কে কিছুই প্রমাণ করে না।

যে ব্যর্থতা আপনি সহ্য করতে পারেন তা দিয়ে বেছে নিন

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

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

টানেল পড়ে গেলে আগেই ঠিক করুন প্রক্সির ব্যর্থ হওয়া উচিত নাকি সাধারণ পথে ফেরা, আর রাউটিং টেবিলকে সেই সিদ্ধান্ত প্রকাশ করতে দিন।