برانچ اور لیب کے درمیان ربط کے لیے روٹ شدہ VPN یا برج شدہ LAN

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

جڑنے کے دو طریقے، ایک واضح سمجھوتہ

روٹ شدہ ربط گھریلو لیب کو اپنی ایڈریسنگ والا دور دراز نیٹ ورک سمجھتا ہے۔ برانچ لیب کا سابقہ مانگتی ہے، ٹنل وہ پیکٹ لے جاتا ہے، اور لیب کا گیٹ وے اپنے ذیلی نیٹ سے جواب دیتا ہے۔ برانچ کے ARP ٹیبل میں کچھ نہیں بدلتا، اور لیب کے DHCP دائرے سے کچھ برانچ تک نہیں پہنچتا۔

برج شدہ ربط ایک ہی لیئر 2 ڈومین کو دونوں سائٹوں پر پھیلا دیتا ہے۔ دریافت کے پروٹوکول کام کرتے ہیں، آلات خودبخود ظاہر ہوتے ہیں، اور ہر نشریات، ہر ARP درخواست اور ہر multicast پیکٹ اب ٹنل عبور کرنے کا امیدوار ہے، یعنی بڑی مقدار میں ٹریفک جو مقامی سیگمنٹ کے لیے بنائے گئے پروٹوکول اٹھاتے ہیں نہ کہ مختلف MTU اور بدلتے ہوئے راؤنڈ ٹرپ وقت والے WAN کے لیے۔

روٹنگ آپ کو کیا دیتی ہے

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

تیسرا یہ ہے کہ یہ اس سے میل کھاتا ہے جو ٹنل واقعی منتقل کرتا ہے۔ IPsec پالیسی سابقوں کا جوڑا ہے، اور ہر طرف ارسال کا راستہ گیٹ وے پر ارسال فعال کے ساتھ عام IP روٹنگ ہے:

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

آپ جس چیز سے دستبردار ہوتے ہیں وہ نشریات کے ذریعے دریافت ہے۔ یہ حقیقی نقصان ہے اور اسے سب کچھ برج کر کے بچنے کے بجائے دانستہ طور پر بدلنا چاہیے۔

برجنگ کی لاگت

برجنگ کو لیئر 2 کے فریم ٹنل سے گزارنے ہوں گے، جس کا مطلب سادہ پالیسی پر مبنی ٹنل کے بجائے IPsec کے اوپر GRE یا VXLAN جیسی encapsulation ہے۔ جب یہ موجود ہو تو دونوں سائٹیں ایک ناکامی کا ڈومین شیئر کرتی ہیں۔ Spanning tree ٹنل کو ربط سمجھتا ہے، نشریاتی ٹریفک ٹنل کی بینڈوڈتھ کھاتی ہے، اور ہر وہ آلہ جو کم تاخیر والا سیگمنٹ فرض کرتا ہے ایسے طریقوں سے غلط برتاؤ کرتا ہے جنہیں کسی بھی سرے سے منسوب کرنا مشکل ہے۔

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

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

نشریات کے بغیر نام

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

multicast دریافت زیادہ مشکل معاملہ ہے اور اسے درستگی کا حق ہے۔ mDNS جیسے پروٹوکول لنک لوکل multicast استعمال کرتے ہیں جو روٹر بطور طے شدہ آگے نہیں بھیجتے، اس لیے دریافت کی فہرست سے غائب لیب کا میزبان اپنے دستاویزی ایڈریس پر اب بھی قابلِ رسائی ہو سکتا ہے۔ اگر کوئی مخصوص سروس واقعی multicast مانگتی ہے تو اسی ایک پروٹوکول کی منصوبہ بندی کریں، کسی reflector یا ہدف شدہ ارسال کے قاعدے کے ساتھ، بجائے پورے LAN کو عام مرمت کے طور پر برج کرنے کے۔

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

روٹ شدہ ڈیزائن کو قابلِ جانچ بنائیں

ایک ہدف چنیں، مثلاً لیب کا ویب انٹرفیس اس کے اپنے سرور ذیلی نیٹ پر، اور اسے دونوں سمتوں میں ثابت کریں۔ برانچ کے میزبان سے مقامی طور پر ایڈریس اور سننے والی سروس کی تصدیق کریں، پھر ٹنل سے جڑیں اور دہرائیں۔ کھڑی ٹنل ثابت کرتی ہے کہ گیٹ ویز متفق ہیں؛ میزبان کے فائر وال یا واپسی کے راستے کے بارے میں یہ کچھ ثابت نہیں کرتی۔

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

پھر مسترد شدہ منزل بھی جانچیں۔ برانچ کا صارف جسے ایک ایپلیکیشن چاہیے اسے hypervisor کنسول کی ضرورت نہیں، اور یہ جاننے کا واحد طریقہ کہ پالیسی حقیقی ہے، ٹھیک وہی آزمائش ہے جسے اسے مسترد کرنا چاہیے۔ سابقے، resolver پر انحصار اور جانچ کے نتائج درج کریں، اور کسی بھی سائٹ میں آئندہ تبدیلی یادداشت سے دوبارہ بنانے کے بجائے منٹوں میں جائزہ لی جا سکتی ہے۔