OpenVPN: local اور ٹنل کا پتہ، دو مختلف ساکٹ

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

bind خرابی ایک مقامی پتہ بتاتی ہے

جب OpenVPN بتاتا ہے کہ وہ مقامی پتہ bind نہیں کر سکتا، تو یہ ٹرانسپورٹ ساکٹ کی بات کر رہا ہے: وہ UDP یا TCP اختتامی نقطہ جو پیئر تک خفیہ کردہ کنکشن لے کر جاتا ہے۔

ایک واضح local ہدایت ڈیمون سے کہتی ہے کہ وہ اس ساکٹ کو ایک مخصوص مقامی پتے سے bind کرے۔ یہ پتہ اسی نیٹ ورک نیم اسپیس میں موجود ہونا چاہیے جہاں عمل چل رہا ہے، اور کلائنٹ کے شروع ہونے کے وقت اسے تفویض کیا جا سکنا چاہیے۔

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

local اور remote اصل میں کیا منتخب کرتے ہیں

remote اس پیئر کا نام بتاتا ہے جس سے رابطہ کرنا ہے۔ local اسی ساکٹ کے قریبی سرے کو bind کرتا ہے۔ nobind آپریٹنگ سسٹم کو مقامی پتہ اور پورٹ دونوں منتخب کرنے دیتا ہے، اسی لیے گھریلو روٹروں کے پیچھے کلائنٹ عام طور پر ان دونوں ہدایات کے بغیر کام کرتے ہیں۔

ان میں سے کوئی ہدایت ٹنل کے اندر کے پتے سے کوئی تعلق نہیں رکھتی۔

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

ip -brief address show
ip route get 203.0.113.10

اندر کا پتہ سرور سے آتا ہے

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

اندر کے پتے کے ساتھ local لکھنا سرور سے یہ نہیں کہتا کہ وہ یہ پتہ تفویض کرے۔ بہترین صورت میں bind ناکام ہوتا ہے؛ بدترین صورت میں کلائنٹ اسی قدر والا کوئی غیر متعلق میزبان پتہ ڈھونڈ کر اسے ٹرانسپورٹ کے لیے استعمال کرنے لگتا ہے۔

پڑھنے کے لیے انٹرفیس بھی مختلف ہیں۔ ifconfig پیرامیٹر اور پول کنفیگریشن اندرونی حصہ بیان کرتے ہیں، جبکہ remote، local، proto اور nobind بیرونی حصہ بیان کرتے ہیں۔ ان دو فہرستوں کو الگ رکھنا فورم پر ملنے والی تقریباً ہر الجھن والی مثال کی وضاحت کرتا ہے۔ اسی لیے OpenVPN 2.6 دستی انہیں الگ حصوں میں درج کرتا ہے۔

پھندا: مکمل ٹنل جو اپنی ٹرانسپورٹ کو پکڑ لیتی ہے

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

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

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

الجھن روکنے کی عادت

پروفائل میں ہر پتہ پڑھیں اور اس میں ترمیم سے پہلے طے کریں کہ یہ کس پرت سے تعلق رکھتا ہے۔

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

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