برج کے ذریعے جڑے سائٹس کو اب بھی مقامی انٹرنیٹ اخراج کا فیصلہ درکار ہے

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

برج فریم ڈھوتا ہے، فیصلے نہیں

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

اس مشترکہ سب نیٹ پر دو راؤٹر رکھیں اور دونوں ممکنہ گیٹ وے بن جاتے ہیں، چاہے ان میں سے کوئی اس کلائنٹ کے قریب ہو جو اسے استعمال کرتا ہے یا نہ ہو۔

کلائنٹ اپنا گیٹ وے کیسے چنتا ہے

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

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

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

DHCP کو مطلوبہ اخراج کا اظہار کرنے دیں

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

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

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

چار چیزیں الگ الگ جانچیں

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

وہ چار نتائج بتاتے ہیں کہ آپ کے پاس سائٹس کے درمیان برج، مقامی اخراج یا حادثاتی بیک ہال ہے، اور انہیں جمع کرنے میں دس منٹ لگتے ہیں۔

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