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 پراکسی کی ترکیب تنگ کاموں کے لیے مفید رہتی ہے، بشرطیکہ باقی ٹریفک بھلا دیے جانے کے بجائے جان بوجھ کر سنبھالی جائے۔