دو درخواست با تقریباً همان عبارت می‌رسند: هر کارخواه VPN را در یک VLAN انتخابی قرار بده، یا یک trunk VLAN موجود را از طریق VPN عبور بده. این‌ها دو محصول متفاوت‌اند. حالت درون‌ساخت OpenVPN که از VLAN آگاه است، برای درخواست اول یک مدل سوئیچ است و مترادف انتقال شفاف برچسب نیست. انتخاب گزینه نادرست طرحی می‌سازد که پیکربندی‌شده به نظر می‌رسد و قاب‌هایی را که برایتان مهم بود بی‌صدا کنار می‌گذارد.

حالت آگاه از VLAN در واقع چه می‌سازد

وقتی vlan-tagging در یک استقرار TAP فقط-سرور فعال باشد، دیمن دستگاه TAP خود و هر کارخواه متصل را به‌عنوان پورت‌های یک سوئیچ داخلی مدل می‌کند. پورت‌های کارخواه بدون برچسب‌اند و وابستگی VLAN آن‌ها روی سرور از طریق بافت vlan-pvid هر کارخواه تنظیم می‌شود، نه با چیزی که کارخواه می‌فرستد. این تمام نکته مدل است: عضویت تصمیمی در سمت سرور درباره یک همتای احراز هویت‌شده است. هیچ چیز در پروفایل کارخواه لازم نیست بداند به کدام VLAN تعلق دارد.

سمت TAP سرور سیاست پذیرش برچسب‌خورده یا بدون برچسب خود را از طریق vlan-accept می‌گیرد. ارسال درون آن سوئیچ فقط میان VIDهای یکسان رخ می‌دهد، از جمله وقتی client-to-client تنظیم شده باشد، بنابراین دو کارخواه در VLANهای مختلف نمی‌توانند از طریق سرور به هم برسند، هرچند هر دو به آن متصل‌اند.

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

تخصیص‌ها باید از هویت احراز هویت‌شده کارخواه پیروی کنند، نه از مقداری که کارخواه درباره خودش ارائه می‌دهد. تخصیص حذف‌شده هم وضعیت قرنطینه نیست: کارخواه روی PVID پیش‌فرض می‌افتد، پس نبود یک ورودی ccd تصمیمی سیاستی و بی‌صدا است، نه خنثی.

trunk شفاف در عوض چه می‌خواهد

حمل قاب‌هایی که از قبل برچسب دارند از سرتاسر با خاموش‌کردن پردازش آگاه از VLAN آغاز می‌شود. مدل سوئیچ و حفظ برچسب جایگزین یکدیگرند و فعال‌کردن هر دو یعنی خواستن از یک ویژگی که کار دیگری را انجام دهد.

خاموش‌کردن تنها آغاز است. پل در هر انتها و پورت‌های فیزیکی سوئیچ باید بر سر این توافق کنند که کدام VLANها مجازند، کدام برچسب بومی است و قاب‌های بدون برچسب چگونه رفتار می‌شوند. گسترش یک trunk نامحدود دامنه‌های پخش بسیار بیشتری را در معرض می‌گذارد از آن دو که می‌خواستید وصل کنید.

اندازه قاب بودجه خودش را می‌خواهد. یک قاب اترنت برچسب‌خورده به‌همراه کپسوله‌سازی از عدد بار مفیدی که مردم از یک راهنما کپی می‌کنند بزرگ‌تر است و MTUیی که برای یک تونل مسیریابی‌شده خوب بود، دلیل بر کارکردن مسیر trunk نیست.

سه شرطی که پاسخ را تعیین می‌کند

اول، آیا سکوی کارخواه اصلاً از TAP پشتیبانی می‌کند؟ اندروید و iOS پشتیبانی نمی‌کنند و پشتیبانی macOS محدود است، پس ناوگانی از کاربران همراه هر دو طرح TAP را کنار می‌گذارد، بی‌آنکه ترتیب VLANها اهمیتی داشته باشد. یک نشست TUN مسیریابی‌شده بسته‌های IP را حمل می‌کند نه قاب‌های اترنت، و هیچ مقدار پیکربندی VLAN در سمت سرور آن را تغییر نمی‌دهد. پیش از طراحی توپولوژی ناوگان را بررسی کنید، چون این شرط همان است که نمی‌توان دورش زد. این هم شرطی است که بیشتر از همه پس از پایان کار سوئیچ کشف می‌شود.

دوم، چه کسی VLAN را تخصیص می‌دهد؟ اگر پاسخ «سرور، بر پایه اینکه چه کسی احراز هویت کرد» است، مدل سوئیچ مناسب است. اگر پاسخ «زیرساخت سوئیچ موجود، با برچسب‌هایی که از قبل وجود دارند» است، به طرح trunk نیاز دارید.

سوم، چه بخشی از شبکه باید قابل دسترس باشد؟ مدل سوئیچ هر کارخواه را به‌حکم ساختار در یک VLAN نگه می‌دارد. طرح trunk یک پل است و پلی که بد پیکربندی شده باشد دامنه‌های پخشی را که باید جدا می‌ماندند به هم می‌پیوندد.

آزمودن انتخابی که کرده‌اید

یک کارخواه که باید در VLAN مجاز باشد و یکی که نباید، وصل کنید و سپس از انتهای واقعی آزمایش کنید نه از خود سرور. دسترسی‌پذیری از سمت سرور ثابت می‌کند پل یا سوئیچ وجود دارد؛ ثابت نمی‌کند کارخواه در کدام VLAN فرود آمده است.

ip -d link show tap0
bridge vlan show

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

ثبت کنید که استقرار کدام یک از دو طرح را به کار می‌برد. یادداشتی که بگوید «آگاه از VLAN» مبهم است و مهندس بعدی همانی را فرض می‌کند که اول آموخته است. مرجع VLAN در OpenVPNرفتار سوئیچ و بافت هر کارخواه را تعریف می‌کند و کوتاه‌ترین راه برای تأیید این است که کدام مدل را اجرا می‌کنید.

مقالات مرتبط