ایک OpenVPN کلائنٹ پر دو سروس پتے: iroute اور lo

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

عرفی نام مقامی ہے، ملکیت دور ہے

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

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

اپنے نوٹس میں بھی دونوں حدود کو الگ رکھیں۔ مثال کے پتے دستاویزی قدریں ہیں، اور انہیں حقیقی LAN کے ساتھ اوورلیپ کرنا کام کرنے والی ترتیب کو ٹوٹا ہوا دکھانے کا تیز ترین طریقہ ہے۔

کلائنٹ پر پتہ مستقل طور پر شامل کریں

سروس پتے کو میزبان سابقے کے ساتھ loopback پر رکھیں، تاکہ میزبان اسے پہنچنے والے ذیلی نیٹ کے بجائے مقامی ان پٹ سمجھے۔ ip address add 10.66.0.10/32 dev lo یہ ایک پتے کے لیے کرتا ہے، اور دوسرے پتے کے لیے کمانڈ دہرانا دو سروسوں کی ماڈلنگ کرتا ہے۔

اسے ایک بار کی جانچ کے طور پر چلائیں، پھر اسے اس چیز میں منتقل کریں جو میزبان کی نیٹ ورک ترتیب کی مالک ہے، کیونکہ رن ٹائم اضافہ دوبارہ آغاز پر غائب ہو جاتا ہے اور دوبارہ جڑنے کے درمیان نقول جمع ہوتی ہیں۔ نیٹ ورک کے بعد ترتیب دی گئی systemd یونٹ ایک آپشن ہے، اور ڈسٹری بیوشن کا نیٹ ورک مینیجر دوسرا۔ آپ جو بھی چنیں، ایپلیکیشن کے جڑنے سے پہلے پتہ موجود ہونا چاہیے، ورنہ سروس غلط ساکٹ پر اٹھتی ہے۔ دستی کمانڈ کے بعد نہیں، دوبارہ آغاز کے بعد ip address show dev lo سے تصدیق کریں۔

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

اس کا دعویٰ اس CCD فائل میں کریں جسے حب واقعی پڑھتا ہے

سرور پر ملکیت کا اعلان تصدیق شدہ مشترکہ نام سے منتخب کردہ فی کلائنٹ فائل میں جاتا ہے، client-config-dir کے نام کردہ ڈائریکٹری کے اندر۔ لائن iroute 10.66.0.10 255.255.255.255 ہے، ہر پتے کے لیے ایک، اور یہ سرور کو بتاتی ہے کہ اس منزل کے لیے کون سا ساتھی ٹریفک لے۔

دو تفصیلیں اسے خاموشی سے توڑتی ہیں۔ فائل کا نام اس نام سے میل کھانا چاہیے جو سرور واقعی استعمال کرتا ہے، جو username-as-common-name کے کھیل میں ہونے پر مختلف ہوتا ہے۔ اور iroute صرف TUN موڈ میں کلائنٹ کنفیگریشن ڈائریکٹری ترتیب دیے جانے پر لاگو ہوتا ہے، اس لیے برجڈ تعیناتی میں وہی لائن کچھ نہیں کرتی۔ موجودہ فائل میں لکیریں شامل کریں، اسے تبدیل نہ کریں، کیونکہ اس میں پہلے سے مقررہ پتہ یا push اختیارات ہو سکتے ہیں۔ OpenVPN 2.6 حوالہ ڈائریکٹری اور ملکیت کی ہدایت دونوں کی دستاویز کرتا ہے۔

حب کے اپنے کرنل کو بھی ان منزلوں تک راستہ درکار ہے، تاکہ مقامی طور پر پیدا شدہ ٹریفک ٹنل کے عمل میں داخل ہو۔ سرور کنفیگریشن میں route 10.66.0.10 255.255.255.255 اس ٹریفک کو ڈھکتا ہے جو سرور خود پیدا کرتا ہے، جبکہ دوسرے کلائنٹس کو منزل خود سیکھنے کے لیے push "route 10.66.0.10 255.255.255.255" درکار ہے۔

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

ان پٹ پالیسی اور جواب کا راستہ جانچیں

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

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

اسی پورٹ پر دوسرے پتے سے بندھے دوسرے سننے والے پر دھیان دیں، کیونکہ کرنل اسی ساکٹ کو دیتا ہے جو میل کھائے اور نتائج بے ترتیب لگتے ہیں۔ ss -lntp سے جانچیں اور تصدیق کریں کہ بندھا ہوا پتہ سروس کا عرفی نام ہے۔ یہاں ماخذ NAT درکار نہیں، اور اسے شامل کرنا اس طلب کرنے والے کی شناخت چھپا دیتا ہے جس پر آپ کے لاگ منحصر ہیں۔

پتے اور ملکیت الگ الگ جانچیں

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

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