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

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

دوسری ٹنل کس لیے ہے یہ پوچھ کر شروع کریں

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

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

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

راستوں سے پہلے پول دیکھیں

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

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

دو پتہ خاندان یعنی اس جانچ کے دو دور۔ IPv6 پول IPv4 کی طرح خاموشی سے ٹکراتے ہیں۔

ہر پروفائل کو مالک دیں

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

systemctl cat [email protected]
ip -4 addr show

پھر طے کریں کہ راستے کون نصب کرتا ہے، یہ پالیسی کا سوال ہے، نحو کا نہیں۔

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

ہر ٹنل کے مطابق تصدیق کریں، پھر ایک روکیں

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

ip rule show
ip route get 203.0.113.9

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

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