با حوصله بخوان، مثال‌ها را تحلیل کن و تمرین‌ها را انجام بده؛ هدف حفظ کردن تعریف‌ها نیست
محدوده را یک Client یا VLAN یا همه مشخص کن
محدوده مشکل مشخص می‌کند چند کاربر، دستگاه، شبکه یا سرویس تحت تأثیر هستند؛ مقایسه یک نمونه سالم و خراب سریع‌ترین راه کوچک کردن محدوده است قبل از دانستن محدوده سراغ تغییر سراسری نرو VLAN یک Broadcast Domain منطقی جدا روی زیرساخت Switch می‌سازد؛ کاربران دو VLAN برای ارتباط به Routing نیاز دارند VLAN امنیت کامل نیست؛ Policy بین VLANها هم مهم است VLAN یک Broadcast Domain منطقی ایجاد می‌کند و به سازمان اجازه می‌دهد جداسازی شبکه را مستقل از محل فیزیکی کاربران انجام دهد؛ Access Port معمولاً ترافیک یک VLAN را برای End Device حمل می‌کند و Trunk چند VLAN را با Tag ۸۰۲.۱Q بین تجهیزات منتقل می‌کند؛ برای عیب‌یابی باید VLAN ID در دو سر لینک، وضعیت Tag و Untag، Native VLAN در صورت استفاده و عضویت پورت‌ها با طراحی شبکه مقایسه شوند روش عیب‌یابی قابل اتکا از تعیین دامنه مشکل شروع می‌شود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویس‌ها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیه‌ها از کم‌ریسک‌ترین تست‌ها بررسی شوند؛ تغییر چند عامل هم‌زمان تشخیص علت را دشوار می‌کند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود
Gateway داخلی را اول تست کن
Default Gateway معمولاً روتر یا فایروال محلی است که Client ترافیک مقصدهای خارج از Subnet را به آن می‌فرستد؛ ابتدا خود Gateway را Ping کن تا ارتباط داخل شبکه محلی را از مشکل اینترنت جدا کنی Gateway معمولاً باید در همان Subnet Client باشد Router زمانی وارد مسیر می‌شود که مقصد خارج از شبکه محلی باشد و جدول Routing تعیین می‌کند Packet از کدام Next Hop یا Interface عبور کند؛ Default Route فقط مسیر پیش‌فرض برای مقصدهایی است که Route مشخص‌تری ندارند؛ در بررسی مشکل باید Routeهای موجود، Prefix هر Route، Gateway یا Next Hop، وضعیت Interface و مسیر برگشت را هم دید، چون رسیدن Packet به مقصد بدون مسیر برگشت معتبر ارتباط پایدار ایجاد نمی‌کند روش عیب‌یابی قابل اتکا از تعیین دامنه مشکل شروع می‌شود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویس‌ها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیه‌ها از کم‌ریسک‌ترین تست‌ها بررسی شوند؛ تغییر چند عامل هم‌زمان تشخیص علت را دشوار می‌کند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود
IP اینترنت و DNS را جدا تست کن
DNS نام را به اطلاعاتی مانند IP تبدیل می‌کند تا کاربر مجبور نباشد نشانی عددی سرویس‌ها را حفظ کند؛ اگر IP مقصد کار می‌کند ولی نام نه، Query DNS را جداگانه آزمایش کن پاک کردن Cache ممکن است کمک کند اما جای بررسی Record، Resolver و مسیر DNS را نمی‌گیرد نشانی IP هویت منطقی Interface در لایه شبکه است و باید همراه Prefix یا Subnet Mask تفسیر شود؛ Prefix مشخص می‌کند کدام بخش نشانی برای شبکه و کدام بخش برای Host استفاده می‌شود و همین موضوع تعیین می‌کند مقصد محلی است یا باید به Router فرستاده شود؛ در عیب‌یابی، فقط دیدن یک IP کافی نیست و باید Prefix، Gateway، DNS، روش دریافت تنظیمات، Route Table و احتمال وجود نشانی تکراری نیز بررسی شوند DNS سامانه نام‌گذاری توزیع‌شده‌ای است که نام را به داده‌هایی مانند IP مرتبط می‌کند و بسیاری از سرویس‌های سازمانی به Name Resolution درست وابسته‌اند؛ خطای DNS ممکن است در ظاهر شبیه قطعی شبکه یا خرابی برنامه دیده شود، بنابراین باید جداگانه بررسی شود که Client به DNS Server درست اشاره می‌کند، Query پاسخ می‌گیرد، Zone و Record مورد نیاز وجود دارند و زمان و دامنه جست‌وجو با طراحی شبکه سازگارند؛ در همین درس، موضوع «IP اینترنت و DNS را جدا تست کن» را باید در ارتباط با «عیب‌یابی قطعی و کندی اینترنت» بررسی کنی و نتیجه را با شواهد همان سیستم توضیح بدهی
Latency و Loss را مقایسه کن
Latency زمان پاسخ یک عملیات است و در Storage یا شبکه مستقیماً روی حس کندی اثر می‌گذارد؛ میانگین، اوج و زمان رخداد را مقایسه کن Bandwidth بالا مشکل Latency را لزوماً حل نمی‌کند روش عیب‌یابی قابل اتکا از تعیین دامنه مشکل شروع می‌شود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویس‌ها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیه‌ها از کم‌ریسک‌ترین تست‌ها بررسی شوند؛ تغییر چند عامل هم‌زمان تشخیص علت را دشوار می‌کند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن می‌شود که برای تحلیل مسیر از مبدأ تا مقصد، ابتدا Default Gateway Client، سپس Routeهای Router و در صورت وجود چند Router مسیرهای بین آن‌ها را بررسی کن؛ بعد مسیر برگشت را نیز دنبال کن؛ Traceroute می‌تواند سرنخ بدهد اما نبود پاسخ در یک Hop لزوماً به معنی قطع همان نقطه نیست چون بعضی تجهیزات پیام‌های تشخیصی را محدود می‌کنند
قبل از تماس ISP شواهد آماده کن
شواهد داده قابل مشاهده مانند پیام خطا، Log، نتیجه تست، وضعیت Port یا تنظیمات فعلی هستند؛ هر فرضیه باید با شواهد تأیید یا رد شود حدس و تجربه شخصی مفیدند اما جای شواهد را نمی‌گیرند روش عیب‌یابی قابل اتکا از تعیین دامنه مشکل شروع می‌شود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویس‌ها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیه‌ها از کم‌ریسک‌ترین تست‌ها بررسی شوند؛ تغییر چند عامل هم‌زمان تشخیص علت را دشوار می‌کند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، Routing تصمیم می‌گیرد Packet برای شبکه‌های غیرمحلی از کدام مسیر خارج شود؛ Routeهای مشخص‌تر بر Routeهای عمومی‌تر ترجیح دارند و Default Route فقط آخرین انتخاب برای مقصدهای ناشناخته است؛ در اینترنت سازمانی علاوه بر Route، NAT، Firewall و DNS نیز دخیل‌اند و باید نقش هر کدام جداگانه بررسی شود در کار روزمره بهتر است این موضوع را این‌طور بررسی کنی: برای تحلیل مسیر از مبدأ تا مقصد، ابتدا Default Gateway Client، سپس Routeهای Router و در صورت وجود چند Router مسیرهای بین آن‌ها را بررسی کن؛ بعد مسیر برگشت را نیز دنبال کن؛ Traceroute می‌تواند سرنخ بدهد اما نبود پاسخ در یک Hop لزوماً به معنی قطع همان نقطه نیست چون بعضی تجهیزات پیام‌های تشخیصی را محدود می‌کنند
فرض کن در مرز اینترنت و Routing شبکه مشکلی گزارش شده و احتمال می‌دهی به عیب‌یابی قطعی و کندی اینترنت مربوط باشد. قبل از تغییر، وضعیت فعلی را با Route Table، ping، tracert، NAT و Firewall بررسی می‌کنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه می‌کنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر می‌دهی و بعد همان تست را دوباره اجرا می‌کنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباه‌ها را تکرار نکن
- پاک کردن Cache ممکن است کمک کند اما جای بررسی Record، Resolver و مسیر DNS را نمی‌گیرد
- حدس و تجربه شخصی مفیدند اما جای شواهد را نمی‌گیرند
- تغییر دادن تنظیمات مرتبط با عیب‌یابی قطعی و کندی اینترنت قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با عیب‌یابی قطعی و کندی اینترنت، فقط وضعیت فعلی را مشاهده کن و سه نکته‌ای را که برای تشخیص حالت سالم مهم‌اند یادداشت کن
- با Route Table، ping، tracert، NAT و Firewall وضعیت مرتبط با عیب‌یابی قطعی و کندی اینترنت را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو می‌گویند
- یک خطای فرضی مرتبط با عیب‌یابی قطعی و کندی اینترنت بنویس و مشخص کن اولین تست کم‌خطر تو چیست و چه نتیجه‌ای فرضیه‌ات را رد می‌کند
نکته‌هایی که باید با خودت ببری
- محدوده را یک Client یا VLAN یا همه مشخص کن
- Gateway داخلی را اول تست کن
- IP اینترنت و DNS را جدا تست کن
- Latency و Loss را مقایسه کن
- قبل از تماس ISP شواهد آماده کن
- قبل از تغییر Default Route، NAT یا WAN دسترسی جایگزین و Rollback را مشخص کن
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
چرا باید محدوده را یک Client یا VLAN یا همه مشخص کنی و از کجا می‌فهمی نتیجه درست است؟
محدوده مشکل مشخص می‌کند چند کاربر، دستگاه، شبکه یا سرویس تحت تأثیر هستند؛ مقایسه یک نمونه سالم و خراب سریع‌ترین راه کوچک کردن محدوده است
چرا باید Gateway داخلی را اول تست کنی و از کجا می‌فهمی نتیجه درست است؟
Default Gateway معمولاً روتر یا فایروال محلی است که Client ترافیک مقصدهای خارج از Subnet را به آن می‌فرستد. ابتدا خود Gateway را Ping کن تا ارتباط داخل شبکه محلی را از مشکل اینترنت جدا کنی
چرا باید IP اینترنت و DNS را جدا تست کنی و از کجا می‌فهمی نتیجه درست است؟
DNS نام را به اطلاعاتی مانند IP تبدیل می‌کند تا کاربر مجبور نباشد نشانی عددی سرویس‌ها را حفظ کند؛ اگر IP مقصد کار می‌کند ولی نام نه، Query DNS را جداگانه آزمایش کن
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبت‌نام، تکمیل درس‌ها و نمره آزمون روی حساب ذخیره می‌شود
