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 کی ترتیب اس کے بارے میں کچھ ثابت نہیں کرتی۔

جس ناکامی کو آپ برداشت کر سکیں اس کے مطابق چنیں

جب ہوسٹ کو مجموعی طور پر محفوظ رکھنا ہو اور آپ اخراج کی فہرست برقرار رکھ سکیں تو مکمل ٹنل چنیں۔ جب ہوسٹ کو اپنا راستہ رکھنا ہو اور صرف ایک سروس موڑنی ہو تو ماخذ کی بنیاد پر روٹنگ چنیں۔ دونوں جائز ہیں؛ غلطی یہ ہے کہ ایک چن کر پھر اسے دوسرے کی طرح جانچا جائے۔

جو بھی چنیں، دونوں طرف سے تصدیق کریں: پراکسی کے ذریعے ایک درخواست اور ہوسٹ سے براہ راست درخواست، ہر ایک کے لیے دیکھا گیا اخراجی پتہ درج کرتے ہوئے۔

اگر ٹنل گر جائے تو پہلے سے طے کریں کہ پراکسی کو ناکام ہونا چاہیے یا پیچھے ہٹنا، اور روٹنگ جدول کو وہ فیصلہ ظاہر کرنے دیں۔