OpenVPN کلائنٹ اس وقت رک جاتا ہے جب اس کا سرور اسی ہوسٹ پر چلتا ہے

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

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

علامت کو الٹا پڑھیں

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

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

ہر مثال کے لیے ایک ساکٹ اور ایک آلہ

سننے والا سرور اپنا پورٹ باندھتا ہے؛ آؤٹ باؤنڈ کلائنٹ کو بھی اپنے encapsulated ٹریفک کے لیے مقامی پورٹ درکار ہوتا ہے۔ جب دونوں ایک ہی ہوسٹ پر رہتے ہیں، تو کلائنٹ کا ڈیفالٹ رویہ سرور کے پورٹ سے ٹکرا سکتا ہے۔ کلائنٹ کا مقامی پورٹ پن کیا جا سکتا ہے، اور جہاں ساتھی کو مقررہ ماخذ پورٹ کی ضرورت نہ ہو وہاں باندھنا چھوڑا جا سکتا ہے:

lport 1195
nobind
dev tun1

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

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

ڈیفالٹ راستے کے لیے ایک مالک منتخب کریں

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

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

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

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

اسٹیٹس لائن سے نہیں، ٹیبل سے تصدیق کریں

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

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

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

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