LAN میزبان OpenVPN کلائنٹ کے پتے کے لیے ARP کیوں بھیجتا ہے

LAN میزبان اور VPN کلائنٹ کے درمیان رسائی کے مسائل اکثر خود پتہ منصوبے کی طرف لوٹتے ہیں۔ اس میزبان کو 10.0.100.0/22 پر ایک انٹرفیس دیں اور یہ 10.0.100.0 سے 10.0.103.255 تک ہر پتے کو براہِ راست منسلک سمجھے گا، بشمول کلائنٹس کا وہ پول جو خاموشی سے 10.0.101.0/24 پر رکھا گیا ہے۔ جواب کبھی روٹر کی طرف نہیں جاتا، کیونکہ میزبان کے نقطہ نظر سے کوئی روٹر شامل نہیں ہوتا۔ پیکٹ کسی ہمسایہ کو مخاطب ہوتا ہے اور تار پر طلب کیا جاتا ہے۔

یہی طریقہ کار رپورٹس کے ایک پورے خاندان کے پیچھے ہے: ٹنل قائم ہے، سرور کے پاس روٹ ہے اور LAN میزبان پھر بھی کلائنٹ تک نہیں پہنچ سکتا۔

وہ /22 جو /24 کو نگل جاتا ہے

پریفکس کو رینج کے طور پر پڑھیں، سٹرنگ کے طور پر نہیں۔ ایک /22 میں 1024 پتے ہوتے ہیں اور 10.0.100.0/22 10.0.100.0 سے 10.0.103.255 تک پھیلا ہے، اس لیے 10.0.101.0/24 کا پول مکمل طور پر اس کے اندر ہے۔ یہ غلطی جائزے سے بچ جاتی ہے کیونکہ پول کے پہلے آکٹیٹ LAN کے پہلے آکٹیٹس سے مختلف دکھتے ہیں اور صرف تیسرا آکٹیٹ اس احاطے کو ظاہر کرتا ہے۔ دونوں رینجز کو ہندسوں میں لکھیں اس سے پہلے کہ انہیں الگ قرار دیں۔

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

براہِ راست رابطہ کا مطلب ARP ہے، روٹنگ نہیں

جب /22 انٹرفیس والا میزبان 10.0.101.25 پر بھیجتا ہے تو کرنل منزل کا انٹرفیس کے پریفکس سے موازنہ کرتا ہے اور مماثلت پاتا ہے۔ پیکٹ روٹ شدہ پیکٹ کی بجائے ہمسایہ کی تلاش بن جاتا ہے، اور ایتھرنیٹ پر ہمسایہ کی تلاش اسی پتے کے لیے ARP درخواست ہے۔ اگر پتہ روٹ شدہ گیٹ وے کے پیچھے کسی VPN کلائنٹ کا ہو تو LAN کا کوئی میزبان اس کا مالک نہیں ہوتا، لہٰذا درخواست بے جواب رہتی ہے اور پیکٹ ضائع ہو جاتے ہیں۔ ٹنل قصوروار نہیں اور کلائنٹ ٹریفک کبھی نہیں دیکھتا۔

اسی لیے ناکامی غیر متوازن اور کبھی کبھار وقفے وقفے سے دکھتی ہے۔ VPN میزبان اکثر LAN تک پہنچ جاتا ہے کیونکہ اس کے اپنے روٹ درست سمت میں اشارہ کرتے ہیں، جبکہ LAN میزبان جواب نہیں دے سکتا، اور پرانے ARP اندراج کو کیش کرنے والی ہر چیز علامت کو جھلملاتی رکھتی ہے۔

TUN، TAP اور ہر ایک کیا لے جاتا ہے

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

نتائج اخذ کرنے سے پہلے نوٹ کریں کہ ARP درخواست کہاں نمودار ہوئی اور کس نظام نے بھیجی۔ بھیجنے والا آپ کو بتاتا ہے کہ وہ منزل کے بارے میں کیا سمجھتا ہے، نہ کہ ٹنل کیا کرتا ہے۔

ایسا پول ڈیزائن کریں جو متداخل نہ ہو سکے

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

سرور پر Source NAT پول کو LAN سے قابلِ روٹ پتے کے پیچھے چھپا سکتا ہے، اور یہ نقل مکانی کا جائز اوزار ہے۔ یہ ماخذ کو بھی دوبارہ لکھتا ہے، اس لیے LAN کنکشنز کو انفرادی کلائنٹس سے منسوب کرنے اور فی کلائنٹ قواعد لاگو کرنے کی صلاحیت کھو دیتا ہے۔

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