NetGuard-এর SOCKS মোড TCP কভার করে, সব প্রোটোকল নয়

NetGuard ট্রাফিক ফিল্টার করার জন্য অ্যান্ড্রয়েডের VPN ইন্টারফেস দখল করে এবং সমর্থিত সংযোগ SOCKS এন্ডপয়েন্টে হস্তান্তর করতে পারে। এই দুটি তথ্যকে প্রায়ই “ফোনটি একটি VPN-এ আছে” হিসেবে পড়া হয়, যা একটি সিদ্ধান্ত এবং প্রক্রিয়াটি তা সমর্থন করে না। ফিল্টার প্যাকেট দেখে; প্রক্সি শুধু সেই সংযোগগুলো দেখে যেগুলো সত্যিই তার কাছে হস্তান্তর করা হয়েছে। এই দুই বিবৃতির মাঝখানে কভারেজের পুরো প্রশ্নটি অবস্থিত।

উৎসের FAQ একইসঙ্গে একক-সেবা সীমাবদ্ধতা ও SOCKS বিকল্পের কথা নথিভুক্ত করে। বিকল্পটির অস্তিত্ব এই প্রমাণ নয় যে প্রতিটি অনুমোদিত প্যাকেট এটি ব্যবহার করে, আর ঠিক এই ব্যবধান থেকেই কভারেজের প্রশ্ন ওঠে।

একটি অ্যাপের ভেতরে দুটি ফরওয়ার্ডিং পথ

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

এই পার্থক্যের একটি পরিণতি আছে যা মানুষ দুই দিকেই ভুলভাবে বলে। প্রতিটি UDP প্যাকেটকে লিক বলা ব্লকিং নিয়ম উপেক্ষা করে, কারণ প্রত্যাখ্যাত ডেটাগ্রাম কখনো বেরোয় না। পুরো ব্যবস্থাটিকে VPN বলা অনুমোদিত সরাসরি পথ উপেক্ষা করে, কারণ কিছু ট্রাফিক প্রক্সি ছাড়াই বেরোয়। আপনার কাছে যা আছে তা আংশিক প্রক্সিসহ একটি ফিল্টার করা ডিভাইস, আর সৎ বর্ণনা লেবেল নয়, একটি ম্যাট্রিক্স।

UDP ঘোষণা করা মানে তা বাস্তবায়ন করা নয়

UDP সমর্থনের দাবি করা একটি SOCKS সার্ভার আপনার ফোনের অ্যাপে সংশ্লিষ্ট ক্লায়েন্ট-পার্শ্ব পরিচালনা যোগ করে না। প্রোটোকলের তাত্ত্বিক বৈশিষ্ট্য আর ইনস্টল করা বিল্ডের আচরণ আলাদা বিষয়, এবং আপনার ট্রাফিক বর্ণনা করে শুধু দ্বিতীয়টি।

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

DNS তৃতীয় পথ, খুঁটিনাটি নয়

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

আপনি কোনটি চান তা সচেতনভাবে ঠিক করুন। যদি প্রয়োজন হয় নামগুলি টানেলের মধ্য দিয়ে সমাধান হবে, তবে শুধু ব্রাউজার সেটিং তা দেবে না, আর যে প্রক্সি নিজেই হোস্টনেম সমাধান করে সে উত্তর বদলায় শুধু সেই সংযোগগুলির জন্য যা সে সত্যিই পরিচালনা করে।

প্রক্সি পরিবহন স্বয়ংক্রিয়ভাবে ব্যক্তিগত নয়

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

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

পৃষ্ঠা লোড নয়, ম্যাট্রিক্স দিয়ে কভারেজ অডিট করুন

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

যদি প্রয়োজন হয় নির্বাচিত সব অ্যাপ্লিকেশন ট্রাফিক দূরবর্তী টানেল দিয়ে যাবে, তবে স্পষ্টভাবে সমর্থিত সম্মিলিত ফিল্টারিং ও টানেলিংযুক্ত বাস্তবায়ন বেছে নিন। কেবল TCP-প্রক্সি সমবায় সংকীর্ণ কাজের জন্য উপযোগী থাকে, যদি অন্য ট্রাফিক ভুলে না গিয়ে সচেতনভাবে পরিচালিত হয়।