OpenVPN کا UDP جواب غلط پتے سے کیوں آتا ہے

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

ماخذ بدلنے پر کلائنٹ کیا دیکھتا ہے

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

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

multihome اختیار دراصل کیا کرتا ہے

یہ ہدایت ترتیبات کی فائل میں multihome اور کمانڈ لائن پر --multihome کے طور پر لکھی جاتی ہے، اور UDP سرور کو مجبور کرتی ہے کہ اُس پتے سے جواب دے جہاں کلائنٹ کا پیکٹ پہنچا۔ کرنل وصولی کے وقت اصل منزل کا پتہ بطور اضافی ڈیٹا دیتا ہے، اور OpenVPN اُس قدر کو جواب کے ماخذ کے طور پر استعمال کرتا ہے۔ اس طرح عمومی پتے پر سننے والا سرور، IPv4 کے لیے local 0.0.0.0 یا اس کا IPv6 مساوی، ایسے برتاؤ کرتا ہے جیسے ہر کلائنٹ کسی مخصوص سننے والے تک پہنچا ہو۔ عوامی پتے سے آنے والے کلائنٹ عوامی پتے سے جواب پاتے ہیں، اور اندرونی پتے والے کلائنٹ اسی پتے سے پاتے ہیں۔ پیکٹ کے راستے میں اور کچھ نہیں ہلتا: راستہ، فلٹر کے قواعد اور ٹنل کی ترتیب ویسے ہی رہتے ہیں جیسے تھے۔

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

کب مستقل مقامی پتہ غلط ڈیفالٹ ہے

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

OpenVPN حوالہ اس اختیار کو UDP سرورز تک محدود رکھتا ہے، پیکٹ کے راستے میں اضافی پروسیسنگ کا ذکر کرتا ہے، اور درج کرتا ہے کہ کون سے پلیٹ فارم اس کی حمایت کرتے ہیں۔ اس کی بنیاد پر منصوبہ بندی سے پہلے نصب شدہ ورژن پر اس کی تصدیق کریں۔ جہاں حمایت نہیں ہے وہاں مخصوص پتہ باندھنا یا واپسی راستہ درست کرنا متبادل ہے، اور دونوں پہلی نظر میں نظر آنے سے زیادہ تنگ تبدیلیاں ہیں۔ عمومی پتے پر سننا جوابات سے آگے بھی نتائج رکھتا ہے: تمام پتوں پر سرور اُس ہر نیٹ ورک سے قابل رسائی ہے جس سے میزبان جڑا ہے، اور یہ شاید وہ نمائش نہ ہو جو کسی کا ارادہ تھا۔

جواب کے ماخذ کو باہر سے ثابت کریں

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

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

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

روٹنگ، دریافت اور فلٹرنگ الگ رہتے ہیں

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

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