کیا دو سائٹوں کو سائٹ VPN کے لیے ایک ہی VLAN ID درکار ہیں؟

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

افسانہ: دونوں سروں پر ایک ہی VLAN ID

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

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

الٹی آزمائش بھی اتنی ہی معلوماتی ہے۔ دونوں دفاتر کو ایک ہی سب نیٹ دیں اور ایک جیسے VLAN نمبر کتنے ہی ہوں، وہ کسی ایڈریس کو غیر مبہم نہیں کریں گے۔

ٹنل واقعی کیا منتقل کرتا ہے

IPsec ایڈریس، پروٹوکول اور پورٹ میں بیان کردہ پالیسی کے مطابق IP پیکٹوں کی حفاظت کرتا ہے۔ IPsec آرکیٹیکچر IP سطح پر ان سلیکٹروں کی وضاحت کرتا ہے، جو سوئچ ٹیگ کی بیان کردہ کسی بھی چیز سے کئی سطح اوپر ہے۔ جب پیکٹ ٹنل میں داخل ہوتا ہے تو وہ پہلے ہی VLAN چھوڑ چکا ہوتا ہے؛ ٹیگ مقامی سوئچ استعمال کر چکا ہوتا ہے۔

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

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

ip xfrm policy
ip route show
swanctl --list-sas

وہ اوورلیپ جو واقعی توڑتا ہے

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

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

دونوں سروں پر ایک ہی VLAN نمبر کبھی کبھی مشترکہ ٹیمپلیٹ کا اتفاق ہوتے ہیں، اور اس اتفاق کو کام کرنے والی ٹنل کی وجہ سمجھنا بعد میں کچھ بگڑنے پر غلط تبدیلی کی طرف لے جاتا ہے۔

ہر سطح کے لیے ایک کام، تحریری طور پر

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

ان کاموں کو الگ رکھنا ہی تبدیلیوں کو محفوظ بناتا ہے۔ ایک دفتر میں VLAN دوبارہ نمبر کرنا مقامی سوئچ، DHCP دائرے اور ممکنہ طور پر فائر وال زون کو چھوتا ہے، اور ٹنل کو نہیں چھوتا۔ پریفکس تبدیلی ٹنل سلیکٹر، دونوں طرف کے روٹ اور رسائی پالیسی کو چھوتی ہے، اور سوئچ ٹیگ کو نہیں چھوتی۔

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

یہ فرض کرنے سے پہلے کہ ٹیگ ٹنل تک پہنچتا ہے، پل کے اوزار سے مقامی تصویر کی تصدیق کریں۔

bridge vlan show
ip -br addr
ip route get 10.62.0.20

جب layer-2 کی توسیع ہی اصل ضرورت ہو

کچھ ڈیزائنوں کو سائٹوں کے درمیان واقعی Ethernet رویے کی ضرورت ہوتی ہے: براڈکاسٹ دریافت پر منحصر پرانی ایپلیکیشن، ایسی منتقلی جس میں مشین کے ہلنے کے دوران ایڈریس برقرار رکھنا ہو، یا ایسا پروٹوکول جو layer-2 مفروضے سمیٹے ہو۔ ایسے معاملات میں فریم منتقل کرنے والا اوورلے یا پل شدہ سروس درکار ہوتی ہے، اور پھر VLAN رکنیت، لوپ کی روک تھام اور ناکامیوں کی دیکھ بھال سرے سے سرے تک کے معاملات بن جاتے ہیں۔

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

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