VPN کے ذریعے DHCP: براڈکاسٹ کو پل بنائیں یا ریلے کریں؟

سرنگ کے دوسری طرف نیا لیپ ٹاپ پتہ نہیں پاتا، جبکہ وہی لیپ ٹاپ مرکزی دفتر میں کام کرتا ہے۔ عام پہلا گمان یہ ہوتا ہے کہ سرنگ DHCP کو روک رہی ہے۔ اکثر براڈکاسٹ کا کبھی راستہ ہی نہیں تھا: غیر ترتیب شدہ کلائنٹ 255.255.255.255 پر بھیجتا ہے، اور عام IP راؤٹر وہ پیکٹ آگے نہیں بھیجتا۔ سرنگ وہی کر رہی ہے جو روٹ شدہ سرنگ کرتی ہے۔

دو ڈیزائن اسے بدل سکتے ہیں، اور وہ برابر نہیں ہیں۔ ایک براڈکاسٹ لے جاتا ہے؛ دوسرا درخواست ریلے کرتا ہے۔

براڈکاسٹ کبھی راؤٹر سے نہیں گزرتا

بغیر پتے کا DHCPv4 کلائنٹ 0.0.0.0 سے محدود براڈکاسٹ پتے پر UDP پورٹ 67 اور 68 پر بھیجتا ہے۔ وہ پیکٹ ڈیزائن کے مطابق اپنی لنک پر ہی رہتا ہے۔ جو راؤٹر اسے آگے بھیجے گا وہ اپنی خدمت کے ہر حصے کو سیلاب سے بھر دے گا۔

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

پل بنائی گئی سرنگ دراصل کیا بڑھاتی ہے

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

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

یہ پتہ دینے سے بڑا فیصلہ ہے، اور اسے دانستہ لیا جانا چاہیے۔

اس کے بجائے درخواست ریلے کریں

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

مثال کے طور پر دور دفتر کے لیے، ریلے دفتر کے LAN پر بیٹھتا ہے اور سرور تک سائٹ VPN کے ذریعے پہنچا جاتا ہے۔ اس دفتر کے لیے اسکوپ، ریلے اور سرور کی شناخت، اور مکمل واپسی راستہ ترتیب دیں۔ سرنگ کے ذریعے UDP 67 کی اجازت دینا سرور کو یہ نہیں بتاتا کہ کون سا پول استعمال کرنا ہے۔

آگے بھیجنے والا مگر کبھی جواب نہ پانے والا ریلے عام طور پر واپسی راستے کا مسئلہ ہے۔ اسکوپ بدلنے سے پہلے ریلے پتے تک واپسی راستہ جانچیں۔

DHCP کو ARP سے اور سرنگ کے پتوں سے الگ رکھیں

DHCP UDP/IP پر چلتا ہے۔ Ethernet میں، ہوسٹ ARP بھی استعمال کر سکتا ہے تاکہ دیکھے کہ امیدوار پتہ پہلے سے زیر استعمال ہے یا نہیں۔ وہ تصادم جانچ ایک الگ لنک مقامی کارروائی ہے، DHCP پیغامات کی ترسیل نہیں۔ یہ کہنا کہ DHCP بنیادی طور پر ARP ہے غلط ہے؛ یہ کہنا کہ دونوں کا کبھی تعلق نہیں بہت وسیع ہے۔

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

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