عام لوپ تحفظ ایک ہوسٹ راستہ ہے: VPN سرور کے عوامی پتے کی ٹریفک اپ لنک سے باہر بھیجیں تاکہ خفیہ کردہ سیشن کبھی اپنی ہی سرنگ میں داخل نہ ہو۔ یہ ٹھیک اس لمحے تک کام کرتا ہے جب آپ اسی سرور پر سرنگ کے ذریعے ویب سروس تک بھی پہنچنا چاہیں، کیونکہ استثنا منزل سے جڑا ہے اور منزل ایک ہی ہے۔ نکلنے کا راستہ یہ ہے کہ منزل کے لحاظ سے درجہ بندی کرنا چھوڑ دیں اور یہ درجہ بندی شروع کریں کہ کس ساکٹ نے پیکٹ بھیجا۔

جن دو بہاؤ کو الگ کرنا چاہتے ہیں ان سے شروع کریں

ایک بہاؤ خفیہ کردہ OpenVPN منتقلی خود ہے، جسے اپ لنک سے باہر جانا ہوتا ہے، ورنہ سرنگ اپنا ہی بیرونی کنکشن اٹھائے گی۔ دوسرا اسی عوامی پتے پر ایک عام HTTPS درخواست ہے، جسے آپ سرنگ کے اندر رکھنا چاہتے ہیں تاکہ وہ سرنگ کے ماخذ سے سروس تک پہنچے۔ وہی منزل، اکثر وہی پورٹ نمبر، مختلف مطلوبہ راستہ۔

اس وضاحت میں فرض کریں کہ 10.90.0.10 پر ایک کلائنٹ tun1 کے ذریعے ہے، سرور کا عوامی پتہ 198.51.100.25 ہے، اور مرکزی جدول اچھوتا ہے جس کا طے شدہ راستہ عام اپ لنک کی طرف ہے۔ سرور کی طرف بھی اندرونی راستے پر ویب سروس قبول کرنی ہوتی ہے اور ٹریفک کو سرنگ کے ماخذ تک واپس بھیجنا ہوتا ہے؛ عوامی پتے پر پیکٹ بھیجنا سرور کے لسنر یا فائر وال پالیسی کو منسوخ نہیں کرتا۔

کچھ بھی بدلنے سے پہلے ہوسٹ کے موجودہ قواعد درج کریں اور ایسی قدریں چنیں جو کوئی اور استعمال نہیں کرتا: ایک نشان، ایک جدول نمبر اور تین قاعدہ ترجیحات۔ اس کنکشن سے نہ جانے والا واپسی کا راستہ رکھیں، کیونکہ یہاں کی غلطی براؤزر ٹیب توڑنے کے بجائے آپ کی اپنی دور دراز رسائی چھین لیتی ہے۔

لفافہ اٹھانے والے ساکٹ کو نشان زد کریں

کلائنٹ ترتیب کو اپنے خفیہ کردہ باہر جانے والے پیکٹوں کے لیے ایک نشان ملتا ہے اور وہ خود راستے نصب کرنا چھوڑ دیتی ہے، تاکہ متبادل پالیسی ہی راستے طے کرنے والی واحد چیز ہو:

mark 42
route-noexec
disable-dco

اعشاریہ 42 ہیکساڈیسیمل 0x2a ہے، اور ہیکس شکل وہی ہے جس سے روٹنگ قواعد مماثل ہوں گے۔ link-options کا حوالہ mark کو Linux پر خفیہ کردہ باہر جانے والے پیکٹوں پر لاگو ہونے والی چیز بتاتا ہے، یعنی بالکل وہی ساکٹ جس کا راستہ آپ کو کنٹرول کرنا ہے۔ ڈیٹا چینل کا آف لوڈ بند کرنے سے یہ مثال صارف کی جگہ کے راستے پر رہتی ہے، جہاں نشان کا رویہ بیان کردہ ہی ہے۔

route-noexec اوپن وی پی این کی خودکار راستہ شمولیت اور اخراج کو دبا دیتا ہے۔ یہ ان کی جگہ کچھ نصب نہیں کرتا، اس لیے اس لمحے سے راستوں کے مالک کو سرنگ کے لیے درکار ہر راستہ برقرار رکھنا ہوتا ہے۔ اگر تبدیلی کے بعد کوئی نجی منزل غائب ہو جائے تو وہ غائب متبادل پالیسی ہے، نشان کا نقص نہیں۔

یہ کرتے وقت 198.51.100.25 کے لیے مرکزی جدول میں ہوسٹ راستہ نہ رکھیں۔ ایسا راستہ وہی استثنا واپس لاتا ہے جسے ڈیزائن محدود کرنا چاہتا ہے، اور نیچے کی کسی بھی پالیسی سے پوچھے جانے سے پہلے یہ HTTPS بہاؤ کے لیے جیت جائے گا۔

باقی سب سرنگ کے جدول میں بھیجیں

جب سرنگ انٹرفیس موجود ہو اور اپنا پتہ رکھتا ہو، پالیسی ایسی دکھتی ہے:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

پہلا قاعدہ ہوسٹ کے مخصوص راستوں کو نظر آتا رکھتا ہے، جس میں کوئی بھی منظور شدہ مقامی نیٹ ورک شامل ہے، جبکہ اس تلاش کے لیے مرکزی جدول کے طے شدہ راستے کو پوشیدہ کر دیتا ہے۔ یہ فرق اہم ہے: طے شدہ کو دبانا جدول کو نظر انداز کرنے کے برابر نہیں، اور آپ کو اب بھی درکار مقامی استثنائیں اسی وجہ سے بچی رہتی ہیں۔ ان استثناؤں کو ایک ایک کرکے پڑھیں، بجائے یہ مان لینے کے کہ نتیجہ کوئی عالمگیر ہنگامی سوئچ ہے۔

بغیر نشان والی ٹریفک پھر سرنگ کے جدول میں گرتی ہے، سرنگ کا ماخذ لیتی ہے اور VPN سے باہر نکلتی ہے۔ نشان زدہ ٹریفک اگلے دو قواعد کے fwmark امتحان میں ناکام ہو کر فہرست میں نیچے والی عام مرکزی تلاش کی طرف بڑھتی ہے، جہاں اپ لنک کا طے شدہ راستہ اب بھی ہے۔ آخری unreachable قاعدہ وہی ہے جو سرنگ کا راستہ نہ ہونے پر بغیر نشان والے بہاؤ کو خاموشی سے اپ لنک پر واپس گرنے سے روکتا ہے۔ منتخب کنندہ شروع سے آخر تک نشان ہے، اور منزل کا پتہ کبھی فیصلے میں نہیں آتا۔

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

واپسی کے راستے کو بھی وہی نشان نظر آئے

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

اصلاح فائر وال کے مالک کی ہے: باہر جانے والے کنکشن پر نشان محفوظ کریں، اسے مماثل اندر آنے والے پیکٹوں پر بحال کریں، اور متعلقہ راستے کے لیے ماخذ سے تصدیق شدہ نشان کی تدبیر فعال کریں۔ OpenVPN کا ساکٹ نشان مقرر کرنا ان تینوں میں سے کچھ نہیں کرتا، اور صرف کلائنٹ اختیارات گنوانے والی ترکیب نامکمل ہے۔ اس انضمام کی تحریری طور پر درخواست کریں، کیونکہ یہ ڈیزائن کا سب سے کم نظر آنے والا حصہ ہے اور دوبارہ تعمیر میں سب سے آسانی سے گم ہونے والا۔

ڈھیلی واپسی راستے کی جانچ بھی متبادل نہیں۔ ڈھیلے موڈ میں بھی ماخذ کے لیے کوئی راستہ موجود ہونا ضروری ہے، اور آپ کا شامل کردہ unreachable محافظ بغیر نشان والی تلاشوں کے لیے جان بوجھ کر ایک ہٹا دیتا ہے۔ اس ڈیزائن پر بھروسہ کرنے سے پہلے کنکشن نشان کے انضمام کو مکمل اور جائزہ شدہ کرائیں، اور ہوسٹ فلٹروں کو الگ سوال مانیں: نشان روٹنگ کا اشارہ ہے، اجازت نہیں۔ اگر انضمام موجود نہ ہو تو علامت وہ سیشن ہے جو قائم ہوتا ہے اور پھر جواب آنے لگتے ہی خاموش ہو جاتا ہے۔

اسے دو راستہ تلاشوں سے ثابت کریں

موازنہ کریں کہ کرنل دونوں سیاق و سباق کے لیے کیا فیصلہ کرتا ہے، اور اخراج کی حالت کے بجائے dev اور src فیلڈز پڑھیں:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

پہلی تلاش سرنگ کے ماخذ کے ساتھ tun1 پر حل ہونی چاہیے، اور دوسری اپ لنک پر۔ یہ مصنوعی تلاشیں ہیں، اس لیے یہ پالیسی ثابت کرتی ہیں، چلتی ہوئی عمل نہیں: چلتے ہوئے کلائنٹ کا اصل منتقلی راستہ الگ سے تصدیق کریں، پھر سرٹیفکیٹ کی توثیق آن رکھتے ہوئے حقیقی HTTPS درخواست کریں۔

مکمل قرار دینے سے پہلے لکھیں کہ ڈیزائن کیا نہیں ڈھکتا۔ DNS، IPv6 اور قواعد کا زندگی نامہ ہر ایک کو اپنا فیصلہ درکار ہے، اور یہ IPv4 روٹنگ کی مثال ہے، مکمل رازداری کی ترتیب نہیں۔ اس کی قدر منتخب کنندہ ہے: لفافے کو اپ لنک کی استثنا ملتی ہے، اور اسی پتے پر عام سروس کو اسے ورثے میں لینے کی ضرورت نہیں۔

متعلقہ مضامین