آپ کا VPN پول LAN کا DHCP رینج نہیں ہے: یہ کیوں ٹوٹتا ہے

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

دو تقسیم کار، ایک پتے کی جگہ

LAN کا DHCP سرور جانتا ہے کہ اس نے کون سے پتے کس MAC پتے کو لیز پر دیے ہیں، اور ARP سے ان کی حفاظت کرتا ہے۔ VPN سرور کا اپنا پول ہے اور ان لیزوں کے بارے میں کچھ نہیں جانتا۔ دونوں غلط نہیں ہیں؛ انہیں کبھی ایک دوسرے سے متعارف نہیں کرایا گیا۔

VPN سرور LAN پول سے جو پتہ دیتا ہے وہ پہلے سے کسی پرنٹر کا ہو سکتا ہے۔ اب دو آلات ایک ہی پریفکس پر ایک پتے کا دعویٰ کرتے ہیں، اور سوئچ کی فارورڈنگ ٹیبل طے کرتی ہے کہ کون جواب دے گا۔

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

روٹر VPN پتے کیوں تقسیم نہیں کرتا

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

اسی لیے VPN سرور خود پتہ مقرر کرتا ہے: سرور کنفیگریشن میں ایک پول, WireGuard سیٹ اپ میں ہر ساتھی کے لیے ایک پتہ، یا IKEv2 تعیناتی میں توثیق کی تہہ جو پتہ دھکیلتی ہے۔ یہ طریقے LAN کے لیز ڈیٹا بیس سے آزاد ہیں، اور اسی لیے انہیں اپنی رینج درکار ہے۔

یہی دلیل بتاتی ہے کہ DHCP اسکوپ بدلنے سے وہ VPN کلائنٹ کیوں درست نہیں ہوتا جو کبھی پتہ نہیں پاتا۔ کلائنٹ LAN سرور سے نہیں پوچھ رہا، اور اسکوپ میں کوئی بھی ترمیم اسے پوچھنے پر مجبور نہیں کرتی۔

اوورلیپ سست نیٹ ورک کے طور پر نہیں، تصادم کے طور پر ظاہر ہوتا ہے

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

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

واپسی کا راستہ الگ مسئلہ ہے

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

کچھ بھی بدلنے سے پہلے راستہ دونوں سمتوں میں پڑھیں۔ گیٹ وے پر پوچھیں کہ کرنل کلائنٹ پتے کے لیے کون سا انٹرفیس استعمال کرے گا؛ کلائنٹ پر پوچھیں کہ وہ LAN پتے کے لیے کون سا راستہ استعمال کرتا ہے۔

یہ کمانڈز گیٹ وے پر فارورڈنگ کا فیصلہ اور ڈپلیکیٹ آشکار کرنے والے ہمسایہ اندراجات دکھاتی ہیں:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

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

پل شدہ ڈیزائن موجود ہیں، مگر انہیں منتخب کرنا پڑتا ہے

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

جو کام نہیں کرتا وہ نمبر کاپی کرکے نتیجے کی نقل کرنا ہے۔ پل کے بغیر مشترکہ پول آپ کو دریافت کے بغیر تصادم دیتا ہے، جو دونوں ترتیبوں میں بدترین ہے۔

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