وینو سرور

عیب‌یابی مشکل ارتباط بین VLANها: از Trunk تا Routing

اگر ارتباط بین VLANها برقرار نیست، باید مسیر عیب‌یابی را از بررسی Trunk و Allowed VLAN شروع کنید، سپس وضعیت SVI یا Router-on-a-Stick را چک کنید و در نهایت ACL و Routing Table را بررسی نمایید؛ ۸۰٪ مشکلات Inter-VLAN Routing در همین سه لایه ریشه دارند. این راهنما دقیقاً همین مسیر عملی را بر اساس تجربه پروژه‌های واقعی توضیح می‌دهد.

در بیش از صد پروژه طراحی و بازطراحی شبکه‌های سازمانی، اختلال ارتباط بین VLANها یکی از پرتکرارترین Ticketها بوده است. اما نکته مهم این است که در اغلب موارد، مشکل پیچیده نیست؛ بلکه ترتیب بررسی اشتباه است. این مقاله با نگاه معماری زیرساخت نوشته شده، نه صرفاً اجرای چند دستور CLI.

گام اول: بررسی Trunk و Allowed VLAN

در عیب‌یابی ارتباط بین VLANها، اولین نقطه بررسی، صحت تنظیم Trunk و لیست VLANهای مجاز است.

در شبکه‌های چندسوییچه، اگر VLAN موردنظر روی لینک Trunk Allow نشده باشد، ترافیک هرگز به لایه Routing نمی‌رسد. یکی از رایج‌ترین خطاها، اضافه‌کردن VLAN در Access Switch و فراموش‌کردن اضافه‌کردن آن به Allowed VLAN در Trunk بین Access و Distribution است.

در پروژه‌ای که روی بستر سوئیچ سیسکو WS-C2960-24TC-L  اجرا شد، کاربران VLAN جدید تعریف‌شده قادر به دسترسی به سرور نبودند. بررسی نشان داد VLAN در Access ایجاد شده اما در Trunk بین Access و Distribution Allow نشده است. اصلاح یک خط تنظیم، مشکل را برطرف کرد. این تجربه نشان می‌دهد که قبل از رفتن سراغ Routing، باید لایه 2 را کامل بررسی کرد.

قاعده قطعی: اگر VLAN در هر دو سمت Trunk تعریف و Allow نشده باشد، Routing هرگز کار نخواهد کرد.

گام دوم: بررسی وضعیت SVI یا Router-on-a-Stick

پس از تأیید Trunk، باید بررسی شود که Interface مجازی VLAN (SVI) یا Subinterface روتر فعال و Up باشد.

در معماری Inter-VLAN Routing، یا از SVI در سوئیچ لایه 3 استفاده می‌شود یا از Router-on-a-Stick. در هر دو حالت، اگر Interface مربوطه Shutdown باشد یا IP اشتباه داشته باشد، ارتباط قطع می‌شود. در برخی موارد، VLAN تعریف شده اما SVI آن ایجاد نشده است.

در شبکه‌ای مبتنی بر سوئیچ سیسکو WS-C2960C-8PC-L  که به روتر مرکزی متصل بود، VLAN جدید به‌درستی روی سوئیچ تعریف شد اما Subinterface مربوطه روی روتر ایجاد نشده بود. کاربران تصور می‌کردند مشکل از ACL است، در حالی‌که Gateway آن VLAN عملاً وجود نداشت. این اشتباه در شبکه‌هایی که چند تیم روی تجهیزات کار می‌کنند بسیار رایج است.

نکته معماری: Gateway هر VLAN باید دقیقاً یک نقطه مشخص و مستند داشته باشد.

گام سوم: بررسی IP Addressing و Default Gateway

بخش قابل‌توجهی از مشکلات ارتباط بین VLANها به اشتباه در IP Plan یا Default Gateway مربوط است.

در تجربه عملی، دیده‌ام که کاربران VLAN 20 به‌اشتباه Gateway VLAN 10 را تنظیم کرده‌اند یا Subnet Mask اشتباه وارد شده است. این خطاها معمولاً در زمان تغییر ساختار شبکه یا افزودن VLAN جدید رخ می‌دهد.

در یکی از پروژه‌هایی که مدیریت آن را برعهده داشتم، پس از Migration شبکه، بخشی از کاربران به VLAN جدید منتقل شدند اما DHCP Scope به‌روزرسانی نشده بود. در نتیجه، IP از Subnet قدیمی دریافت می‌کردند و ارتباط بین VLANها دچار اختلال شد. بررسی DHCP و ARP Table مشکل را آشکار کرد.

قاعده روشن: پیش از ورود به بحث ACL یا Routing Protocol، IP Plan را با دقت بررسی کنید.

سوئیچ سیسکو WS-C2960-24TC-L

گام چهارم: بررسی ACL و سیاست‌های امنیتی

اگر Trunk و Routing صحیح است اما ارتباط برقرار نیست، احتمالاً ACL یا فایروال داخلی ترافیک را مسدود کرده است.

در بسیاری از سازمان‌ها، برای جداسازی VLANها ACL تعریف می‌شود. اما گاهی یک Rule اشتباه باعث مسدودشدن کامل ارتباط می‌شود. در یک شبکه چندسایتی، دسترسی بین VLAN کاربران و سرور مالی قطع شده بود. بررسی نشان داد که یک ACL جدید برای محدودسازی دسترسی به اشتباه کل Subnet را Deny کرده است.

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

مرزبندی مهم: ACL باید مستند و مبتنی بر نیاز کسب‌وکار باشد، نه صرفاً برای سخت‌گیری بیشتر.

گام پنجم: بررسی Routing Table و Dynamic Protocolها

در شبکه‌های بزرگ‌تر، ممکن است مشکل در جدول مسیریابی یا Routing Protocol باشد.

اگر از OSPF یا EIGRP استفاده می‌کنید، باید مطمئن شوید که شبکه VLAN جدید Advertise شده است. در یکی از پروژه‌های ارتقاء شبکه، VLAN جدید روی Distribution ایجاد شد اما به دلیل عدم به‌روزرسانی Network Statement در OSPF، در Core دیده نمی‌شد. در نتیجه ارتباط بین سایت‌ها برقرار نبود.

در شبکه‌هایی که مبتنی بر مدل‌های Access مانند سوئیچ سیسکو WS-C2960-24TC-L هستند و Routing در روتر مرکزی انجام می‌شود، این خطا کمتر رخ می‌دهد. اما در معماری‌های لایه 3 توزیع‌شده، بررسی Routing Table الزامی است.

قاعده قطعی: اگر Packet به Gateway می‌رسد اما به مقصد نمی‌رسد، مشکل در Routing است نه VLAN.

کیس استادی اول: اختلال گسترده در سازمان چندساختمانی

در یک سازمان دولتی با سه ساختمان، ارتباط بین VLAN کاربران و سرور مرکزی قطع شد. تیم داخلی ابتدا تصور کرد مشکل از فایروال است. به‌عنوان مدیر پروژه بررسی، مسیر عیب‌یابی را از Trunk شروع کردیم. مشخص شد در زمان افزودن VLAN جدید، Allowed List در یکی از لینک‌های Distribution به‌روزرسانی نشده است.

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

سوئیچ سیسکو WS-C2960C-8PC-L

کیس استادی دوم: اشتباه در طراحی Router-on-a-Stick

در پروژه‌ای دیگر، سازمان تصمیم به استفاده از Router-on-a-Stick گرفت. VLANها تعریف شده بودند اما Native VLAN در Trunk بین سوئیچ و روتر اشتباه تنظیم شده بود. در نتیجه ترافیک Tagged به‌درستی پردازش نمی‌شد.

پس از اصلاح Native VLAN و تطبیق Subinterfaceها، مشکل رفع شد. این پروژه نشان داد که در طراحی‌های ساده نیز جزئیات Tagging اهمیت حیاتی دارد.

چه زمانی مشکل از تجهیزات نیست؟

گاهی مدیران تصور می‌کنند برای حل مشکل ارتباط VLANها باید سراغ ارتقاء تجهیزات یا حتی خرید سوئیچ سیسکو WS-C2960G-48TC-L  بروند. اما در بیش از ۷۰٪ مواردی که بررسی کرده‌ام، مشکل از تنظیمات بوده نه سخت‌افزار.

ارتقاء سوئیچ بدون اصلاح طراحی یا مستندسازی، فقط هزینه اضافی ایجاد می‌کند. ابتدا باید ساختار VLAN، Trunk و Routing بررسی و مستند شود.

جمع‌بندی اجرایی برای مدیران IT و خرید

اگر ارتباط بین VLANها برقرار نیست، مسیر عیب‌یابی را از لایه 2 (Trunk و VLAN) آغاز کنید، سپس Gateway و Routing را بررسی نمایید و در نهایت ACL و سیاست‌های امنیتی را تحلیل کنید. این ترتیب، سریع‌ترین و کم‌ریسک‌ترین روش است.

برای مدیر IT، توصیه روشن است: پیش از هر تصمیم برای تغییر تجهیزات یا توسعه شبکه، یک Audit ساختاری انجام دهید. در بسیاری از پروژه‌ها، اصلاح یک خط تنظیم، جایگزین خرید سخت‌افزار جدید شده است.

برای مدیر خرید نیز پیام واضح است: مشکلات Inter-VLAN اغلب ناشی از طراحی و تنظیمات است، نه کمبود تجهیزات. پیش از سرمایه‌گذاری، مطمئن شوید که معماری و مستندسازی شبکه شما استاندارد است.

در نهایت، عیب‌یابی ارتباط بین VLANها یک فرآیند منطقی و مرحله‌به‌مرحله است. اگر از Trunk شروع کنید و تا Routing پیش بروید، بدون حدس و گمان، به ریشه مشکل خواهید رسید. شبکه پایدار نتیجه طراحی منظم و بررسی سیستماتیک است، نه واکنش هیجانی به اختلال.

اشتراک گذاری

مطالب مرتبط

دیدگاهی بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *