آشنایی با مفهوم VLAN بندی و پیکربندی آن در دنیای مجازی سازی

در این قسمت قصد داریم به بحث VLAN بندی بپردازیم، VLAN بندی در سطح سوئیچ های ESXI یا در دنیای VMware و هم چنین بررسی نماییم چند متد وجود دارد تا بر روی بسته ها VLAN Tag زده شود. در ابتدا در محیط فیزیکی و سپس در دنیای Virtualization به بررسی این موضوع که به چند روش قادر خواهیم بود بر روی بسته ها به هنگام خارج شدن یا وارد شدن به سرور بحث VLAN Tag را انجام دهیم، می‌پردازیم. (یعنی به چه صورت مشخص می‌کنیم که بسته از چه VM ای در کدام VLAN قرار می‌گیرد.)

بررسی VLAN بندی در محیط فیزیکی:

به شکل زیر توجه کنید.

در این شکل یک شبکه با دپارتمان های مختلف اعم از Management، Helpdesk، Finance، Security و ... را داریم که برای هر دپارتمان یک سوئیچ جدا در نظر گرفته شده است، اما این یک design استاندارد نیست؛ مثلا اگر سوئیچ Management از بین برود، Engineering نیز از بین خواهد رفت یا اگر Helpdesk خراب شود، دیگر سوئیچ Human Resource را نخواهیم داشت چون کاملا به هم وابسته هستند. مثلا اگر Engineering یک بسته را Broadcast کند، Flow ترافیکی آن به Management، Helpdesk، Finance، Security و سپس Human Resource، Sales و Research ارسال خواهد شد. البته ما با سوئیچ Engineering این مثال را در نظر گرفتیم اما اگر هر کدام از سوئیچ های دیگر بسته Broadcast ارسال کند، این اتفاق تکرار خواهد شد.

شما فرض کنید اگر در یک شبکه خیلی بزرگ چنین design ای داشته باشیم، چقدر از Capacity و پهنای باند شبکه بخاطر Broadcast ها بیهوده مصرف می‌شود. از طرفی دیگر ما نمی‌توانیم Broadcast را بخاطر بحث ARP و Unknown Unicast کنار بگذاریم، چون مثلا سوئیچ Engineering، بار اول از MAC address ها و اینکه بسته ها را به چه صورت باید انتقال داد، اطلاعی ندارد؛ مجبور است از Broadcast استفاده کند یا مثلا سوئیچ Managemnet می‌خواهد به PC ای که تا به حال به آن متصل نشده، متصل شود؛ بایستی از Unknown Unicast کمک بگیرد تا MAC address مربوط به PC مورد نظر سوئیچ Management را پیدا کند. پس عملا ما نمی‌توانیم جلوی Broadcast و ARP را بگیریم چون PC ها از این طریق با یکدیگر ارتباط برقرار می‌کنند. حال این در مورد بحث Broadcast بود. در بحث Security چطور؟ اگر ما چنین شبکه ای داشته باشیم که مثلا دپارتمان Engineering از لحاظ Layer 2 بتواند بقیه دپارتمان ها را ببیند، می‌تواند مشکلات امنیتی در دپارتمان های دیگر به وجود آورد؛ مثلا برای پروتکل های مدیریتی که برای سوئیچ ها استفاده می‌کنید، یا هنگامی که برای متصل شدن به سرور remote می‌زنید و یا به صفحه وب آن متصل می‌شوید و حتی زمانی که ترافیک های user name/password دار در داخل شبکه عبور می‌کنند، ممکن است با مشکلات امنیتی روبرو شوند و این اصلا خوب نیست. فرض کنید در قسمت حراست، مدام دوربین ها مانیتور می‌شوند و درست نیست که دپارتمان Sales بتواند با نرم افزاری آن ها را capture کرده و ببیند. پس ما باید کاری کنیم که دپارتمان ها از لحاظ Layer 2 جدا از هم باشند، اما در کنار آن کاری انجام می‌دهیم که بتوانیم Broadcast ها را مدیریت کنیم.

شاید به این فکر کرده باشید که مثلا اگر دپارتمان Engineering بخواهد بسته ای را به دپارتمان Research ارسال کند، آیا این بسته به دپارتمان Sales ارسال می‌شود؟! اینجا باید بگم بله قشنگ ارسال می‌شه!! می‌دونین چرا؟ قطعا می‌دونین! فارغ از اینکه VLAN بندی کرده باشیم، زمانی که بسته ای Broadcast یا Unknown Unicast می‌شود، flow ترافیکی شروع به سرک کشیدن در کل شبکه می‌کند، البته همانطور که گفته شد بار اول ولی در مرحله دوم، چون بسته به صورت Unicast ارسال می‌شود این اتفاق تکرار نخواهد شد.

در شبکه های بزرگ، ممکن است این «بار اول» بسیار اتفاق بیفتد؛ چون امکان دارد MAC table های سوئیچ ها flush شوند یا برق قطع شود و سوئیچ خاموش و روشن شود یا حتی جابجایی انجام دهیم که در تمامی این موارد بار اول اتفاق می‌افتد با اینکه اصلا سوئیچ Sales با سوئیچ های دیگر ارتباطی ندارد و کارت شبکه های آن ها را نمی‌بیند، پس ما نمی‌توانیم جلوی Broadcasting را بگیریم.

VLAN بندی

خب VLAN بندی به چه صورت می‌باشد؟ زمانی که VLAN بندی می‌کنیم در واقع می‌گوییم هر VLAN، Broadcast domain مخصوص به خود را دارد؛ یعنی اگر Engineering پیامی را Broadcast کند، فقط Engineering های دیگر می‌توانند آن پیام را بشنوند یا اگر Human Resource بسته ای را ارسال می‌کند، فقط Human Resource ها می‌توانند آن بسته را دریافت کنند. خب این چطور امکان پذیره؟؟ فرض کنید برای هر کدام از دپارتمان ها رنگی را در نظر بگیریم؛ مثلا فرض می‌کنیم رنگ مربوط به دپارتمان Engineering آبی و رنگ مربوط به دپارتمان Human Resource سبز می‌باشد که هر کدام از این ها فقط می‌توانند با دپارتمان های هم رنگ خود تبادل اطلاعات کنند یا عمل Broadcasting را انجام دهند. ولی از آنجایی که سوئیچ ها رنگ را متوجه نمی‌شوند، از طریق بحث VLAN-ID ها به سوئیچ ها می‌فهمانیم که مثلا Engineering ها در VLAN 10 قرار دارند و فقط می‌توانند با سوئیچ هایی که دارای VLAN 10 هستند، ارتباط داشته باشند و Broadcasting را انجام دهند، مثلا اگر در سوئیچ Research، VLAN 10 ای داشته باشیم، flow ترافیکی اگر Broadcast کند به صورت تصویر زیر خواهد بود:

الان شاید بگین که نه اینجوری نیست، Broadcast بازم به بقیه دپارتمان ها میره!! به صورت پیش فرض بله این اتفاق می‌افتد و Broadcast به دپارتمان های دیگر ارسال می‌شود ولی زمانی که شما بر روی سوئیچ ها عملیات VLAN بندی را انجام می‌دهید و با انجام یک سری config  بر روی سوئیچ های Helpdesk و Finance، در واقع به آن ها می‌فهمانیم که در قسمت پایین آن سوئیچ ها هیچ VLAN 10 ای وجود ندارد بنابراین هیچ بسته یا Broadcast را به این سوئیچ ها ارسال نکند. البته ممکن است مقصدی که Engineering در نظر گرفته اصلا وجود نداشته باشد یا خاموش باشد ولی flow ترافیکی دقیقا به همان سوئیچی می‌رود که VLAN 10 در آن وجود دارد. برای بحث tuning خود vlan بندی میتوانیم از بحث VTP puring و Allowed vlan استفاده کرده که به سوییج های بالا دستی اطلاع رسانی کنیم که در سوییچ های پایین دست آیا vlan 10 وجود دارد یا نه ؟ مثلا در شکل بالا در داخل سوییچ Helpdesk در آن interface ای که به سمت سوییچ Human Resource می رود اعلام میکنیم که فقط vlan مربوط به Human Resource قرار دارد در این صورت سوییچ Helpdesk هیچ وقت بسته های Broadcast دیگر VLAN هارا به سمت سوییچ Human Resource نمی فرستد

حال اگر Human Resource در VLAN 20 و Engineering در VLAN 10 باشد، در این صورت این دو از لحاظ Layer 2 نمی‌توانند باهم ارتباط برقرار کنند، پس از لحاظ امنیت این را نیز در نظر داشته باشید. اگر زمانی بخواهید که این دو VLAN متفاوت باهم ارتباط داشته باشند، بایستی یک Routing ای انجام دهید تا از طریق Layer 3 باهم ارتباط بگیرند (چه Core switch چه Router). و زمانی که VLAN بندی را انجام دهید، عملا سوئیچ هایی که در قسمت بالا قرار دارند را حذف کرده و در سوئیچ های پایینی VLAN بندی را انجام می‌دهید.

نکته:

سعی کنید شبکه را طوری design کنید که از VLAN کمتری استفاده شود و هم چنین اگر VLAN بندی می‌کنید، سعی کنید VLAN ها پراکنده نباشند؛ مثلا زمانی که برای دپارتمان Engineering، VLAN 10 را در نظر می‌گیرید، نباید در دپارتمان Research که در طبقه 1 است از VLAN 10 مربوط به Engineering که در طبقه 2 است، چیزی باشد، چون بی دلیل باعث می‌شود ترافیک Layer 2 افزایش یابد که این نیز بستگی به شرایط شبکه شما دارد.

خب ما دلیل وجودیت VLAN را متوجه شدیم:

1. برای کنترل کردن Broadcast ها
2. برای Security؛ که مثلا Human Resource نتواند ترافیک Layer 2 مربوط به Engineering را ببیند.

بررسی مفهوم ACCESS و TRUNK به همراه پیکربندی آن ها در دنیای فیزیکی :

در ادامه قصد داریم با configuration مربوط به VLAN و هم چنین مفهوم Access و Trunk آشنا شویم.

با توجه به شکل زیر، اگر بخواهیم در سوئیچ مورد نظر تعریف کنیم که هر کدام از PC ها داخل چه VLAN ای قرار بگیرند، در ابتدا وارد interface مورد نظر شده و پورت آن را در حالت access قرار می‌دهیم که حالت Cisco ای آن به صورت زیر است:

1- switchport mode access

2- switchport access vlan 10

پس از انجام این config، سوئیچ در table خود port 10 را برای VLAN 10 ثبت می‌کند و دقیقا همین کار را برای پورت بعدی نیز انجام می‌دهیم؛ یعنی port 11 برای VLAN 11. زمانی که PC ای که در VLAN 10 قرار دارد، بخواهد ترافیکی را ارسال کند، به هیچ عنوان سوئیچ ترافیک را به آن هایی که در VLAN 11 قرار دارند ارسال نمی‌کند؛ چرا؟! چون سوئیچ می‌داند که ترافیک این PC از interface ای است که در VLAN 10 قرار دارد، در واقع طبق table ای که دارد و config ای که admin انجام داده است، پس پورت های 10 و 11 نباید با هم ارتباط داشته باشند و در شرایطی که PC ها در یک سوئیچ local قرار دارند و از یک VLAN هستند، هیچ نوع tag ای بر روی بسته های ارسالی PC ها زده نمی‌شود؛ زیرا سوئیچ وظیفه دارد بسته ها را فقط به آن هایی ارسال کند که VLAN یکسانی دارند، یعنی در واقع ترافیک PC1 را فقط به PC2 ارسال می‌کند و دیگر به PC3 ارسال نمی‌کند حتی در شرایط Broadcast.

اما زمانی که مقصد بسته خارج از سوئیچ local باشد؛ یعنی مبدا بسته Switch1 و مقصد Server1 باشد (که هر دو در VLAN 10 قرار دارند)، در این شرایط بایستی به سوئیچ های بین راهی اعلام کنیم که مبدا و مقصد این بسته چیست، VLAN ID آن را مشخص کنیم تا سوئیچ ها بتوانند با این اطلاعات بسته را به مقصد درستی ارسال کنند، مثلا اگر PC1 که در VLAN 10 است بخواهد ترافیکی را به Server1 در VLAN 10 ارسال کند باید سوئیچ های 2 و 3 بدانند که ترافیک ارسالی مربوط به VLAN 10 می‌باشد تا فقط به مقصدهایی که در VLAN 10 قرار دارند ارسال کند نه به همه VLAN ها. پس در خصوص این قضیه بایستی مکانیزمی انجام شود چون سوئیچ ها از local table یکدیگر اطلاعی ندارند، پس باید بر روی بسته ارسالی یک علامتی زده شود تا سوئیچ های بعدی متوجه شوند که این بسته برای کدام VLAN ID است. اینجاست که ما به Trunk نیاز داریم. مثلا هنگام config کردن Switch1، به سوئیچ می‌فهمانیم که اگر نیاز بود بسته ای از این interface خارج شود، بخاطر داشته باش!! که این interface از نوع Trunk است یعنی به یک سوئیچ دیگر متصل شده و لازم است حتما بر روی آن VLAN ID tag زده شود تا سوئیچ های 2 و 3 از اینکه Source بسته کدام VLAN است اطلاع یابند تا آن را به Server یا PC هایی که دقیقا در این VLAN هستند، هدایت کند. هم چنین قابل ذکر است پروتکلی که به ما کمک می‌کند تا بتوانیم بر روی بسته ها VLAN tag بزنیم، پروتکل 802.1Q می‌باشد.

سوال:

چرا interface به سمت Router نیز در حالت Trunk قرار دارد؟ زیرا Gateway کاربران در این قسمت ساخته شده است، مثلا گفته شده interface vlan 10 با این IP و interface vlan 11 با فلان IP می‌باشد که PC ها و Server ها این IP ها را در تنظیمات IP خودشان به عنوان Gateway قرار داده‌اند.

جمع بندی کلی:
• Access port:

پورتی است که بسته ها را تنها روی یک VLAN ارسال می کند و ترافیک در این پورت برچسب گذاری (tag) نمی‌شود؛ که سوئیچ در table خود مشخص می‌کند که مثلا port-10 در VLAN 10 و port-11 در VLAN 11 قرار دارند و هیچ علامتی بر روی بسته ها زده نمی‌شود چون local هستند و هیچ وقت از port-10 به port-11 ارتباطی صورت نمی‌گیرد چون در VLAN های متفاوتی هستند. البته به صورت لایه ۲ هیچ ارتباطی نخواهند داشت.

• Trunk port:

پورت Trunk نوعی اتصال روی سوئیچ است که هنگام ارسال بسته از این پورت دارای برچسب VLAN می‌باشد؛ اگر مقصد ما خارج از Switch1 باشد، باید بر روی بسته ها علامتی (VLAN tag) زده شود تا سوئیچ های 2 و 3 متوجه شوند این بسته ها از کدام VLAN هستند تا آن ها را به مقصد درستی هدایت کنند.

آشنایی با انواع Tagging در دنیای VLANING:

همانطور که در شکل بالا مشاهده می‌کنید، ما دارای 3 نوع Tagging هستیم:

1- نوع اول Virtual Switch Tagging (VST) می‌باشد. در این نوع، عملیات Tagging در VSS یا سوئیچ مجازی انجام می‌گیرد، البته این Port group ها هستند که آن را انجام می‌دهند.

2- نوع دوم External Switch Tagging (EST) می‌باشد. در این نوع انجام عملیات Tagging برعهده سوئیچ فیزیکی خارج از محیط مجازی می‌باشد.

3- نوع سوم Virtual Guest Tagging (VGT) می‌باشد. در این نوع عملیات Tag زنی بر روی Operating System (OS) های VM ها انجام می‌گیرد.

حال به بررسی با جزئیات بیشتر درباره این موارد می‌پردازیم.

Virtual Switch Tagging (VST):

همانطور که در تصویر زیر می‌بینید، VM ها را عضو یک PG کرده و PG را در VLAN مورد نظر قرار می‌دهیم؛ به این صورت که مثلا VM-1 که عضو PG-1 است، در VLAN 10 قرار بگیرد و تمام Port ID هایی که در داخل این PG وجود دارند نیز در VLAN 10 قرار می‌گیرند. فرق قرار دادن یک interface با یک PG در VLAN چیست؟ زمانی که یک interface را در VLAN قرار می‌دهیم، فقط همان interface در VLAN مورد نظر قرار دارد، اما زمانی که یک PG را در یک VLAN قرار می‌دهیم این PG شامل range ای از interface ها می‌باشد که در VLAN مورد نظر قرار می‌گیرند. پس با این تفاسیر، اتصال بین pSwitch و کارت شبکه سرور باید از نوع Trunk باشد؛ چرا؟ تا سوئیچ بسته های Tag خورده را دریافت کند و براساس آن تصمیم بگیرد که آیا بسته مورد نظر می‌تواند به VLAN 10 برود یا نه! این بود از VST که عملیات Tagging آن در سطح PG انجام می‌شود. 

ما نوع دیگری از Tagging را داریم که در سطح VDS قابل انجام است و زمانی اتفاق می‌افتد که بخواهید Port ID ها را در VLAN های مختلفی قرار دهید. دلیل این که در VSS قابل انجام نیست این است که VSS فقط به PG دسترسی دارد نه به Port ID.

External Switch Tagging (EST):

در این نوع شما هیچ تنظیماتی را بر روی سوئیچ مجازی انجام نمی‌دهید، بلکه فقط در سوئیچ فیزیکی (pSwitch) انجام می‌گیرد؛ مثلا به این صورت که مشخص می‌کنید پورت های 1، 2، 3 و 4 سرور در VLAN 10 قرار گیرند. البته قابل ذکر است اگر شما چندین کارت شبکه فیزیکی داشته باشید، می‌توانید تنظیمات مختلفی را بر روی آن ها انجام دهید؛ مثلا مشخص کنید که PG-1 فقط به vmnic1 متصل باشد و از طرفی در سوئیچ فیزیکی پورت آن را بر روی Access تنظیم کرده باشید و تعیین کرده‌اید هر ترافیکی که از interface مربوط به سروری که به پورت 1 متصل است، ارسال شد و هم چنین هر VM ای که به آن PG متصل باشد در VLAN 10 قرار گیرد.

از معایب این نوع می‌توان به این مورد اشاره کرد که شما محدود به یک سری VLAN خاص هستید، به طور مثال می‌توانید 4 پورت در VLAN های مختلف داشته باشید و از طرفی در سوئیچ مجازی تعریف کرده‌اید که PG-1 به vmnic1 متصل شود و vmnic1 ای که به port 1 سوئیچ فیزیکی متصل است در VLAN 10 قرار گیرد. البته در ابتدا ما به این مورد اشاره کردیم که نیاز نیست هیچ تنظیماتی در vSwitch انجام دهید اما اگر در شرایطی باشید یا بخواهید با روش EST هر کدام از vmnic ها را به پورت های مشخصی از pSwitch متصل کنید و آن پورت مشخص را در VLAN های مختلف قرار دهید، قطعا بحث Teaming را از دست خواهید داد. Teaming زمانی برای شما کاربرد دارد که یا در حالت VST باشید یا حالت VGT، در حالت EST شما قادر نخواهید بود چندین VLAN مختلف برای چندین interface فیزیکی سرور در نظر بگیرید و بر روی آنها Teaming انجام دهید، مثلا نمی‌شود port1 سرور در VLAN 10، port2 در VLAN 11 و port3 در VLAN 12 قرار گیرد؛ چون امکان دارد VM ای که در VLAN 10 قرار دارد، به طور اتفاقی بر روی کارت شبکه فیزیکی VLAN 11، assign شود. پس هیچ کنترلی در این مورد نخواهید داشت، یک روز VM ها در VLAN 10 و روز دیگر در VLAN 11 قرار می‌گیرند. در حالت EST، اگر همه آن ها را در یک VLAN قرار دهید و اتصالات سمت سوئیچ در حالت Access باشند هیچ مشکلی به وجود نمی‌آید. (یعنی تمام ارتباطات بین سوئیچ فیزیکی و ESXI به صورت Access باشد و Tagging در سطح سوئیچ فیزیکی انجام شود.)