ایک Linux گیٹ وے پر دو OpenVPN کلائنٹ: پالیسی تقسیم کریں

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

کرنل فیصلہ کرتا ہے، ڈیمان نہیں

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

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

ہر نقل کو اس کا اپنا وسیلہ مجموعہ دیں

ناموں سے شروع کریں، کیونکہ دوبارہ استعمال شدہ نام ہی وہ راستہ ہیں جس سے دونوں نقول اتفاقاً حالت بانٹنے لگتی ہیں۔ الگ سرنگ ڈیوائسز، الگ ترتیبی فائلیں، الگ اسناد اور الگ سروس اکائیاں مقرر کریں۔ ہر نقل کا بیرونی اختتامی نقطہ اور سرنگ کا پتہ پالیسی میٹرکس والے اسی جدول میں درج کریں، تاکہ بعد کی تبدیلی کے لیے دیکھنے کی ایک ہی جگہ ہو۔

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull سرور کے دھکیلے ہوئے راستوں کو مقامی جدول سے باہر رکھتا ہے، اور جب پالیسی کے جدول واضح ہونے چاہئیں تو آپ یہی چاہتے ہیں۔ کیا کوئی مخصوص سرور redirect-gateway کا اختیار بھی دھکیلتا ہے، اور کیا آپ کے کلائنٹ کا ورژن فلٹر کی شکل کو سہارا دیتا ہے، یہ فرض کرنے کی بجائے دستی کتاب میں دیکھنا بہتر ہے۔

میٹرکس لکھیں: ماخذ، جدول، ڈیوائس

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

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

جدول کو وہ منزل کے راستے چاہیے جو گروپ کے پاس ہونے چاہئیں، نیز کوئی بھی مقامی یا انتظامی استثنا جو گیٹ وے کو قابل استعمال رکھے۔ صرف ڈیفالٹ والا جدول اس گروپ کے لیے مکمل سرنگ کی پالیسی ہے، جو بالکل درست بھی ہو سکتی ہے، لیکن یہ رہ جانے کی چیز نہیں، فیصلہ ہونا چاہیے۔

سرنگ کی اپنی ترسیل کلائنٹ گروپ میں نہیں

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

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

راستہ چننا اس کی اجازت نہیں

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

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

ایک سرنگ گرنے پر کیا ہوتا ہے

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

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