ایک VLAN کے لیے TAP برج: ذیلی انٹرفیس منسلک کریں

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

ایک VLAN کی توسیع کا مطلب ایک 2 سطحی ڈومین ہے، اور برج کو ان سب کو اٹھانے والے ٹرنک میں نہیں، اسی ڈومین میں شامل ہونا چاہیے۔

ٹیگ نظر نہیں آتا کیونکہ آپ نے ٹرنک کو برج کیا

VLAN 120 اٹھانے والا Linux اپ لنک eno1 کسی منظم سوئچ تک لے جائیں۔ ایک VLAN کے لیے کام کرنے والا ڈیزائن یہ ہے کہ tap_vpn کو br_vpn سے برج کیا جائے، جہاں br_vpn میں eno1 کے بجائے eno1.120 ہو۔ VLAN ذیلی انٹرفیس باہر جاتے وقت ٹیگ لگاتا ہے اور اندر آتے وقت اسے ہٹا دیتا ہے، اس لیے برج صرف اسی ایک VLAN کے بغیر ٹیگ فریمز دیکھتا ہے۔ اس کے بجائے فزیکل انٹرفیس برج میں رکھیں، وہی فریمز ٹرنک پورٹ پر بغیر ٹیگ نکلتے ہیں، جو آپ نے منصوبہ بند نہیں کیا تھا۔

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

دو جائز ڈیزائن، ایک ٹیگ کا مالک

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

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

پتہ رکنیت کے ساتھ منتقل کریں

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

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

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

راستوں کو قصوروار ٹھہرانے سے پہلے رکنیت جانچیں

مطلوبہ حالت نہیں، موجودہ حالت پڑھیں: ip -d link show dev eno1.120 VLAN id اور اس کے والد کو چھاپتا ہے، ip link show master br_vpn برج کے ارکان کی فہرست دیتا ہے، اور bridge vlan show فی پورٹ رکنیت اور اخراج کی کارروائی بتاتا ہے۔ ذیلی انٹرفیس ڈیزائن میں، یقینی بنائیں کہ TAP ڈیوائس اور VLAN ڈیوائس ارکان ہیں۔ VLAN سے واقف برج میں، خود پورٹ پالیسی جانچیں، کیونکہ برج کا موجود ہونا ثابت نہیں کرتا کہ وہ کس چیز کی اجازت دیتا ہے۔

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