پل TAP برای یک VLAN: زیررابط را متصل کنید

کلاینت TAP که پیش از VLANها به LAN می‌رسید و بعد از آن متوقف شد، معمولاً پلی دارد که هنوز رابط اشتباه را در خود نگه می‌دارد. ارسال فریم برچسب VLAN اضافه نمی‌کند، پس فریم کلاینت بدون برچسب که به uplink فیزیکی فرستاده می‌شود، بدون برچسب روی پورت ترنک می‌رسد و یا دور انداخته می‌شود یا در VLAN بومی می‌افتد. اینکه زیررابط جایی روی هاست وجود دارد، هیچ چیزی را در فهرست اعضای پل تغییر نمی‌دهد. این همان افسانه‌ای است که باید اول کشته شود: برچسب را رابطی اعمال می‌کند که مالک آن است، نه هاست فقط به این دلیل که یکی دارد.

یک گسترش VLAN یعنی یک دامنه layer-2، و پل باید به همان دامنه بپیوندد نه به ترنکی که همه را حمل می‌کند.

برچسب ظاهر نمی‌شود چون ترنک را پل کرده‌اید

یک uplink لینوکسی eno1 را در نظر بگیرید که VLAN 120 را به یک سوئیچ مدیریت‌شده می‌برد. طرحی که برای یک VLAN کار می‌کند، پل کردن tap_vpn به br_vpn است، با br_vpn که eno1.120 را به‌جای eno1 در خود دارد. زیررابط VLAN برچسب را در خروجی اعمال و در ورودی حذف می‌کند، پس پل فقط فریم‌های بدون برچسب برای همان یک VLAN می‌بیند. در عوض رابط فیزیکی را در پل بگذارید تا همان فریم‌ها بدون برچسب از پورت ترنک خارج شوند، که این همان چیزی نیست که برنامه‌ریزی کرده‌اید.

پل کردن ترنک با فیلتر VLAN خاموش هیچ میان‌بری به همان نتیجه نیست. همه VLANهای آن کابل را به پل می‌دهد، از جمله آن‌هایی که کلاینت‌ها نباید ببینند.

دو طرح مشروع، یک مالک برچسب

پل آگاه به VLAN چیدمان معتبر دیگر است: ترنک به پورت پل وارد می‌شود و عضویت هر پورت، PVID و تنظیمات خروجی برچسب‌دار تعیین می‌کند کدام VLANها عبور کنند. آنجا پل مالک برچسب‌گذاری است و افزودن زیررابط VLAN در زیر آن، برای یک کار مالک دومی نصب می‌کند. هر دو طرح کار می‌کنند؛ تکه‌هایی از هر دو نه. پیش از ویرایش هر فهرست عضویت تصمیم بگیرید کدام شیء برچسب را اعمال می‌کند.

پورت سوئیچ باید با طرحی که انتخاب می‌کنید همخوان باشد. پورت access که VLAN را بدون برچسب حمل می‌کند با رابط فیزیکی به‌عنوان اتصال جفت می‌شود، در حالی که پورت ترنک با زیررابط برچسب‌دار جفت می‌شود. افزودن زیررابط به پورت access ناسازگار چیزی را درست نمی‌کند.

آدرس را همراه با عضویت جابه‌جا کنید

در طرح زیررابط، آدرس هاست برای زیرشبکه پل‌شده به br_vpn تعلق دارد، نه به پورت VLAN بنده‌شده که شاید پیش‌تر آنجا بوده است. نگه داشتن آن روی پورت می‌تواند کارکردن را نشان دهد و بعد عجیب رفتار کند، چون پل در layer 2 ارسال می‌کند در حالی که آدرس روی یک عضو نشسته است. آن را به‌عنوان بخشی از تغییر عضویت جابه‌جا کنید و نه به‌عنوان آزمایشی جداگانه.

جابه‌جایی آدرس می‌تواند مسیر مدیریت را قطع کند. یک مسیر بازیابی مستقل برپا کنید، پیکربندی موجود را از طریق مدیر شبکه خود توزیع ذخیره کنید و از اسکریپت راه‌اندازی رقیبی که پس از ارتقای بعدی با آن کشمکش می‌کند پرهیز کنید.

آدرس‌دهی کلاینت‌ها همین دقت را می‌طلبد. VPN پل‌شده کلاینت‌ها را در زیرشبکه گسترده قرار می‌دهد، پس یک استخر نباید با اجاره‌ها یا تخصیص‌های ثابت دیگر هم‌پوشانی داشته باشد و چیدمانی که DHCP سرو می‌کند باید همانی باشد که LAN واقعاً انتظار دارد. مسیر layer-2 کارآمد هیچ چیزی درباره آدرس‌های تکراری نمی‌گوید.

پیش از مقصر دانستن مسیرها، عضویت را بررسی کنید

وضعیت فعلی را بخوانید نه وضعیت موردنظر: ip -d link show dev eno1.120 شناسه VLAN و والد آن را چاپ می‌کند، ip link show master br_vpn اعضای پل را فهرست می‌کند و bridge vlan show عضویت هر پورت و نحوه برخورد با خروجی را گزارش می‌دهد. در طرح زیررابط تأیید کنید که دستگاه TAP و دستگاه VLAN اعضا هستند. در پل آگاه به VLAN، خود سیاست پورت را بررسی کنید، چون وجود پل چیزی را درباره آنچه مجاز می‌داند ثابت نمی‌کند.

سپس یک کلاینت مجاز را در برابر سرویسی در همان VLAN آزمایش کنید و به یاد داشته باشید که ARP، سیاست فایروال و مسیر پاسخ موضوعاتی جدا از عضویت‌اند. اگر بسته ضبط می‌کنید، توجه داشته باشید که offload سخت‌افزاری می‌تواند جای ظاهر شدن برچسب‌های VLAN در یک رد را تغییر دهد. دامنه را هم صادق نگه دارید: کلاینت TUN مسیریابی‌شده با هیچ تغییر پلی عضو VLAN نمی‌شود و ترافیک کلاینت-به-کلاینت جایگزین اتصال هاست به VLAN نیست.