sshuttle বনাম পূর্ণ VPN: এর পদ্ধতি আসলে কী কভার করে
sshuttle কেবল তার ফরওয়ার্ডিং পদ্ধতি যা সমর্থন করে তা বহন করে: প্রথমে TCP, DNS ও UDP কভারেজ, প্রয়োজনীয় স্থানীয় বিশেষাধিকার এবং দূরবর্তী হেল্পার যাচাই করুন।
sshuttle বেছে নেওয়া হয় কারণ SSH আগে থেকেই কাজ করে আর ক্রিপ্টোগ্রাফি পরিচিত মনে হয়, আর এই যুক্তি উপযুক্ততা নির্ধারণকারী একমাত্র প্রশ্নটি এড়িয়ে যায়। কোন প্যাকেট মেশিন ছাড়ে, বিপরীত প্রান্তে কোন অ্যাকাউন্ট সেগুলো বহন করে, এবং টুলটি কতটা স্থানীয় বিশেষাধিকার দাবি করে। এই তিন উত্তরই ফরওয়ার্ডিং পদ্ধতি অনুসারে ভিন্ন হয়, তাই একটি অ্যাপ্লিকেশনের জন্য কাজ করা ব্যবস্থা পরেরটির জন্য চুপচাপ ব্যর্থ হতে পারে। নিচের আলোচনা অ্যাপ্লিকেশনটির সত্যিই যে প্রোটোকল দরকার তা থেকেই শুরু হয়।
অ্যাপ্লিকেশনটির যে প্রোটোকল দরকার তা দিয়ে শুরু করুন
sshuttle 2.0-এ প্রোটোকল সমর্থন নির্ভর করে আপনি কোন পদ্ধতি বেছে নেন তার ওপর। Linux-এর NAT ও nft পদ্ধতি TCP এবং DNS সামলায়, আর TPROXY সাধারণ UDP যোগ করে। প্রতিটি প্ল্যাটফর্ম ও পদ্ধতির নিজস্ব সীমা আছে, আর macOS সম্পূর্ণ ভিন্ন একটি ব্যবস্থার মাধ্যমে হস্তক্ষেপ করে। কিছু বেছে নেওয়ার আগে ইনস্টল করা সংস্করণ, নির্বাচিত পদ্ধতি এবং অ্যাপ্লিকেশনটির প্রয়োজনীয় প্রোটোকল লিখে রাখুন।
তাই একটি সফল TCP অনুরোধ UDP অ্যাপ্লিকেশন বা প্রতিটি DNS লুকআপ সম্পর্কে খুব কম প্রমাণ করে। sshuttle TCP-কে সম্পূর্ণ IP প্যাকেট টানেল করার বদলে স্ট্রিম হিসেবে দেখে, তাই প্রচলিত VPN থেকে ধার করা থ্রুপুট উপসংহার এখানে খাটে না। আপনি সত্যিই যে ব্যবস্থা চালান তার সঙ্গে সত্যিই যে ওয়ার্কলোড আছে তার তুলনা করুন।
| Approach | What it carries | What it needs locally |
|---|---|---|
| SSH local forward | One explicitly named TCP destination | Nothing beyond the SSH client |
| sshuttle, nft or nat method | TCP and DNS to the routed prefixes | Root or sudo for firewall rules |
| sshuttle, tproxy method | TCP, DNS and general UDP | Root or sudo, and kernel support |
| IP VPN | Routed IP traffic in a tunnel | A client with the required privileges |
ক্লায়েন্টের স্থানীয়ভাবে যা দরকার
নথিভুক্ত ক্লায়েন্ট ব্যবস্থায় root বা sudo দরকার, কারণ এটি টানেল ইন্টারফেস তৈরি না করে স্থানীয় ইন্টারসেপশন নিয়ম ইনস্টল করে। এই একটি তথ্যই নিরাপত্তার গল্প বদলে দেয়: সেই বিশেষাধিকারসম্পন্ন প্রক্রিয়া কেবল একটি অ্যাপ্লিকেশনের নয়, পুরো মেশিনের ট্রাফিক ঘুরিয়ে দিতে পারে। বিশেষাধিকারকে ইনস্টলেশনের খুঁটিনাটি নয়, নকশার অংশ হিসেবে দেখুন।
টুলটি কোন নিয়ম ইনস্টল করেছে এবং প্রস্থানের সময় সেগুলো চলে যায় কি না তা নিশ্চিত করুন। ক্র্যাশ করা একটি সেশন ইন্টারসেপশন নিয়ম রেখে গেলে অপারেটর সংযোগটি শেষ হয়েছে ভাবার অনেক পরেও ট্রাফিক ব্ল্যাকহোলে যেতে পারে, আর লক্ষণটি পড়ে থাকা নিয়মের মতো নয়, নেটওয়ার্ক বিকলের মতো দেখায়।
sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip routeপ্রথম কমান্ডটি সাধারণ একটি আহ্বানের রূপ, আপনার সত্যিই প্রয়োজনীয় প্রিফিক্সসহ। দ্বিতীয়টি দেখায় টুলটি কী ইনস্টল করেছে, আর তৃতীয়টি নিশ্চিত করে কোনো টানেল ইন্টারফেস তৈরি হয়নি, যা এই নকশার প্রত্যাশিত ফলাফল।
দূরবর্তী প্রান্ত কী চালায়
দূরবর্তী প্রান্ত হলো একটি অনুমোদিত SSH অ্যাকাউন্ট এবং একটি সামঞ্জস্যপূর্ণ Python হেল্পার পরিবেশ। সীমিত শেলের অধীনে সফল লগইন স্বয়ংক্রিয়ভাবে সেই হেল্পার চালানোর অনুমতি দেয় না, আর হেল্পার চালাতে সক্ষম অ্যাকাউন্ট স্বয়ংক্রিয়ভাবে প্রতিটি লক্ষ্য সেবায় পৌঁছায় না। দুটি তথ্যই সমস্যা সমাধানের নোটে নয়, অ্যাক্সেস অনুরোধে থাকা উচিত।
হোস্ট পরিচয় যাচাই এবং অ্যাকাউন্টের প্রমাণীকরণ রক্ষা করুন। প্রথম সংযোগ কাজ করাতে অজানা হোস্ট কী গ্রহণ করলে দূরবর্তী প্রান্তটি আপনার অভীষ্ট মেশিন কি না সেই যাচাইটি সরে যায়, আর এখানে তা একক উদ্দেশ্যের ফরওয়ার্ডের চেয়ে বেশি গুরুত্বপূর্ণ।
দূরবর্তী অ্যাকাউন্টকে কর্মপ্রবাহের প্রয়োজনীয় সেবাগুলোতে সীমাবদ্ধ করুন এবং সেই পরিধি হোস্ট পরিচালনাকারীদের সঙ্গে আলোচনা করুন। তারা বিশ্বাস সম্পর্কের অংশ, আর ক্লায়েন্ট পক্ষের কোনো সেটিং তা বদলায় না।
বিশ্বাসের সীমানা কোথায়
SSH-এর মাধ্যমে একটি ব্যক্তিগত API সংযোগ ফরওয়ার্ড করা প্রতিটি API অপারেশনকে অনুমোদন করে না। অ্যাপ্লিকেশন TLS এবং অ্যাপ্লিকেশন লগইন এখনও প্রযোজ্য, আর টুলটি একটি অননুমোদিত সেবাকে নিরাপদ করতে পারে না। দূরবর্তী হোস্ট থেকে পরবর্তী লাফও স্বয়ংক্রিয়ভাবে SSH চ্যানেলের মতো একই সুরক্ষিত সেগমেন্ট নয়, কারণ সেই দ্বিতীয় সংযোগ দূরবর্তী হোস্টের যা নীতি আছে তা-ই অনুসরণ করে।
সীমানাটি এক বাক্যে লিখুন: এই প্রিফিক্সগুলোর ট্রাফিক ওই হোস্টে এই অ্যাকাউন্ট দিয়ে বের হয়। বাক্যটির জন্য যদি ব্যতিক্রমের একটি প্যারা দরকার হয়, তবে নকশাটি তার নথির দাবির চেয়ে বেশি কাজ করছে এবং উৎপাদনে যাওয়ার আগে দ্বিতীয়বার দেখা দরকার।
প্রতিটি প্রোটোকলে প্রমাণ করুন, তারপর টুল বাছুন
প্রতিটি প্রয়োজনীয় প্রোটোকল নিরীহ অনুরোধ দিয়ে পরীক্ষা করুন, রিজলভার পথ এবং অ্যাপ্লিকেশন যে অ্যাড্রেস পরিবার ব্যবহার করে তা সহ। পরীক্ষায় একটি সংযোগ বিচ্ছিন্নও রাখুন, যাতে অ্যাপ্লিকেশনের অনুমোদিত ব্যর্থতার আচরণ ঘটনার সময় অপ্রত্যাশিত না হয়ে জানা ফল হয়। চালু থাকার সময় সঠিকভাবে ফরওয়ার্ড করা সেশনটি পড়ে যাওয়ার পর কী হয় সে সম্পর্কে কিছুই বলে না।
স্পষ্টভাবে নাম দেওয়া অল্প কয়েকটি সেবার জন্য সাধারণ স্থানীয় ফরওয়ার্ড মালিকানা ও নিরীক্ষা করা সহজ। যে অ্যাপ্লিকেশন ট্রাফিক তার পদ্ধতির সঙ্গে মেলে, তার জন্য sshuttle বৈধ একটি মধ্যবর্তী পথ দেয়। যখন প্রয়োজনটি বিস্তৃত IP সংযোগ, তখন VPN নকশাই সৎ উত্তর, আর পছন্দটি এনক্রিপশন অ্যালগরিদমের ক্রম নয়, কভারেজ ও পরিচালন দায়িত্ব অনুসরণ করে।