کلائنٹ VLANs یا ٹیگ شدہ ٹرنک: درست OpenVPN موڈ منتخب کریں

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

VLAN سے واقف موڈ اصل میں کیا بناتا ہے

جب صرف سرور کے لیے TAP تعیناتی میں vlan-tagging فعال ہو، ڈیمون اپنے TAP آلے اور ہر منسلک کلائنٹ کو اندرونی سوئچ کی پورٹس کے طور پر ماڈل کرتا ہے۔ کلائنٹ پورٹس بغیر ٹیگ کے ہوتی ہیں، اور ان کا VLAN تعلق سرور پر ہر کلائنٹ کے vlan-pvid سیاق کے ذریعے طے ہوتا ہے، کلائنٹ کی بھیجی ہوئی کسی چیز سے نہیں۔ ماڈل کا پورا مقصد یہی ہے: رکنیت تصدیق شدہ ساتھی کے بارے میں سرور کی طرف کا فیصلہ ہے۔ کلائنٹ پروفائل میں کسی چیز کو یہ جاننے کی ضرورت نہیں کہ وہ کس VLAN میں ہے۔

سرور کی TAP طرف vlan-accept کے ذریعے اپنی ٹیگ شدہ یا بغیر ٹیگ قبولیت کی پالیسی پاتی ہے۔ اس سوئچ کے اندر آگے بھیجنا صرف مماثل VID کے درمیان ہوتا ہے، client-to-client مقرر ہونے پر بھی، اس لیے مختلف VLAN کے دو کلائنٹ دونوں اس سے منسلک ہونے کے باوجود سرور کے ذریعے ایک دوسرے تک نہیں پہنچ سکتے۔

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

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

شفاف ٹرنک اس کے بجائے کیا مانگتا ہے

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

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

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

جواب کا تعین کرنے والی تین شرطیں

پہلی، کیا کلائنٹ پلیٹ فارم TAP کی حمایت کرتا ہے؟ Android اور iOS نہیں کرتے، اور macOS کی حمایت محدود ہے، اس لیے موبائل صارفین کا بیڑا VLAN کیسے بھی ترتیب دیے جائیں دونوں TAP ڈیزائن مسترد کر دیتا ہے۔ روٹ شدہ TUN سیشن ایتھرنیٹ فریم نہیں بلکہ IP پیکٹ لے کر چلتا ہے، اور سرور کی طرف کی کوئی VLAN ترتیب اسے نہیں بدلتی۔ ٹوپولوجی ڈیزائن کرنے سے پہلے بیڑے کی جانچ کریں، کیونکہ یہی وہ شرط ہے جس سے بچا نہیں جا سکتا۔ یہ بھی وہی شرط ہے جو سوئچ کا کام مکمل ہونے کے بعد سب سے زیادہ دریافت ہوتی ہے۔

دوسری، VLAN کون تخصیص کرتا ہے؟ اگر جواب «سرور، اس بنیاد پر کہ کس نے تصدیق کی» ہو تو سوئچ ماڈل موزوں ہے۔ اگر جواب «موجودہ سوئچ ڈھانچہ، پہلے سے موجود ٹیگ کے ساتھ» ہو تو آپ کو ٹرنک ڈیزائن درکار ہے۔

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

اپنے انتخاب کی جانچ

ایک کلائنٹ جواز شدہ VLAN میں ہونا چاہیے اور ایک جو نہیں ہونا چاہیے، دونوں منسلک کریں، پھر سرور سے نہیں بلکہ اصل سرے سے جانچیں۔ سرور کی طرف سے رسائی ثابت کرتی ہے کہ برج یا سوئچ موجود ہے؛ یہ ثابت نہیں کرتی کہ کلائنٹ کس VLAN میں پہنچا۔

ip -d link show tap0
bridge vlan show

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

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