ایک ہی Linux ہوسٹ پر دو OpenVPN سرنگیں: راستہ کس کا ہے؟

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

دوسرے لنک کو جو کام کرنا ہے اسی سے شروع کریں

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

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

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

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

اوور لیپ ہوتے پول روٹنگ سے پہلے ٹوٹتے ہیں

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

مقامی LAN بھی دیکھیں۔ 192.168.1.0/24 نمبر والا گھریلو LAN، جسے ایک سرنگ بھی ظاہر کرتی ہے، وہی ابہام پیدا کرتا ہے، اور علامت یہ ہے کہ ہوسٹ نام حل ہو جاتا ہے جبکہ رابطہ کبھی مکمل نہیں ہوتا۔ راستے چھاپنے تک یہ نام حل کرنے کی خرابی جیسا لگتا ہے۔

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

کلائنٹ کو چھونے سے پہلے دونوں نتائج کا موازنہ دونوں سرور ترتیبوں سے کریں۔ اگر سابقے ایک دوسرے پر چڑھ جائیں تو رکیں اور دوبارہ نمبر دیں، کیونکہ کتنی بھی بار ری اسٹارٹ کریں وہ الگ نہیں ہوں گے۔

ہر پروفائل کو اس کا یونٹ اور ہر سابقے کو مالک دیں

ہر پروفائل کو اپنا واقعہ نام اور اپنی ترتیب فائل ملتی ہے، اس لیے office نامی واقعہ office.conf لوڈ کرتا ہے جبکہ lab نامی lab.conf لوڈ کرتا ہے۔ ڈائریکٹری فہرست پر بھروسا کرنے کے بجائے سروس مینیجر کے ذریعے اس نقشے کی تصدیق کریں، کیونکہ drop-in بدل سکتا ہے کہ کون سی فائل لوڈ ہوتی ہے۔ نقشہ غلط ہونے کا مطلب ہے کہ آپ اس پروفائل کو ٹیون کر رہے ہیں جو چل نہیں رہا۔

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

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

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

مارک جوابات کو اسی انٹرفیس پر رکھتے ہیں جہاں سے وہ آئے

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

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

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

دوسرا شامل کرنے سے پہلے موجودہ قواعد پڑھیں۔ دہری ترجیحات اور بھولی ہوئی جدولیں ہی عام وجہ ہیں کہ مارک پالیسی کا کوئی اثر نہیں دکھتا۔

ایک لنک روک کر علیحدگی ثابت کریں

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

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

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