Troubleshooting حرفه‌ای شبکه و سیستم

وقتی کاربر می‌گوید «شبکه خراب است»، هنوز مسئله فنی مشخصی نداری؛ فقط یک گزارش کلی از تجربه ناموفق او داری. کار حرفه‌ای از جایی شروع می‌شود که این جمله مبهم را به نشانه‌های قابل اندازه‌گیری تبدیل کنی: دقیقاً چه چیزی کار نمی‌کند، از چه زمانی، برای چه کسانی، روی کدام دستگاه‌ها و آیا سرویس‌های دیگر همان مسیر سالم‌اند یا نه. در عیب‌یابی درست، قبل از هر تغییر وضعیت موجود ثبت می‌شود، بعد یک فرضیه محدود ساخته می‌شود و یک آزمایش مشخص برای رد یا تأیید آن انجام می‌گیرد. اگر آزمایش فرضیه را رد کرد، شاخه دیگری را بررسی می‌کنی؛ اگر تأیید کرد، هنوز باید علت عمیق‌تر و اثر اصلاح را بسنجی. خاموش و روشن‌کردن Router، عوض‌کردن DNS یا Disable کردن Firewall بدون فرضیه شاید موقتاً علامت را پنهان کند، اما دانشی درباره علت ایجاد نمی‌کند و حتی ممکن است خرابی تازه بسازد. هدف نهایی فقط بالا آمدن سرویس نیست؛ باید بتوانی توضیح بدهی چه چیزی خراب بود، چرا آن را علت می‌دانی، چه تغییری انجام شد و چه تستی نشان داد سرویس واقعاً به وضعیت سالم برگشته است. همین روش در Windows، MikroTik، VMware، Active Directory و Backup قابل استفاده است.

در بسیاری از Incidentها چیزی که کاربر گزارش می‌کند Symptom یا نشانه است، نه Fault و نه Root Cause. «فایل‌سرور باز نمی‌شود» یک نشانه است؛ Fault می‌تواند شکست DNS Resolution، قطع Route، بسته‌شدن پورت SMB، Stop شدن سرویس، Permission نادرست یا Down بودن VM باشد. Root Cause یک لایه عمیق‌تر است: چه چیزی آن Fault را ایجاد کرده است؟ مثلاً Scope جدید DHCP ممکن است DNS اشتباه توزیع کرده باشد، Rule تازه Firewall ممکن است ترافیک لازم را Drop کند یا Datastore پر شده باشد و VM از دسترس خارج شود. اگر فقط Symptom را درمان کنی، ممکن است سرویس موقتاً برگردد ولی خرابی دوباره ظاهر شود. در گزارش نهایی نیز این تفکیک مهم است؛ «مشکل شبکه رفع شد» تقریباً هیچ دانش قابل استفاده‌ای ایجاد نمی‌کند، اما «Clientهای VLAN 20 به دلیل Option نادرست DNS در Scope جدید، نام FILE01 را Resolve نمی‌کردند» مسیر علت را روشن می‌کند. گاهی Root Cause فوری قابل اثبات نیست. در چنین حالتی نباید حدس را به‌عنوان علت قطعی ثبت کنی. چیزی را Root Cause بنویس که با Timeline، Log، رفتار سیستم و تست بعد از اصلاح قابل دفاع باشد.

یکی از سریع‌ترین روش‌ها برای کوچک‌کردن فضای جست‌وجو تعیین Scope است. اگر فقط یک کاربر نمی‌تواند به CRM وصل شود ولی پنج کاربر کناری بدون مشکل کار می‌کنند، احتمال خرابی سراسری Server یا Internet کمتر می‌شود و باید روی Client، Credential، DNS Cache، Firewall محلی یا Profile همان کاربر تمرکز بیشتری داشته باشی. برعکس، اگر همه کاربران یک VLAN هم‌زمان اینترنت ندارند اما VLAN دیگر سالم است، بررسی Gateway، VLAN، DHCP، ACL و مسیر همان Segment منطقی‌تر است. سؤال‌های ساده‌ای مثل «برای چه کسانی؟»، «با کابل و Wi‑Fi هر دو؟»، «با IP باز می‌شود ولی با Name نه؟»، «از داخل شرکت خراب است یا از VPN هم؟» می‌توانند چندین شاخه را حذف کنند. Scope باید با تست تأیید شود، نه فقط گفته کاربر؛ ممکن است او بگوید «برای همه خراب است» چون دو همکار نزدیکش هم مشکل دارند. از یک سیستم سالم در همان محل، یک سیستم در Segment دیگر و در صورت امکان خود سرویس تست بگیر. همچنین زمان شروع و الگوی تکرار را مشخص کن. تعیین Scope خوب باعث می‌شود از جایی شروع کنی که بیشترین ارزش تشخیصی را دارد.

زمان‌بندی اتفاق‌ها یکی از قوی‌ترین ابزارهای عیب‌یابی است. اگر مشکل دقیقاً بعد از تغییر Rule روی Firewall، جابه‌جایی Uplink، Update یک Server، تغییر Scope DHCP یا Restore یک VM شروع شده باشد، آن Change ارزش بررسی زیادی دارد. با این حال نزدیک‌بودن دو اتفاق به هم ثابت نمی‌کند یکی علت دیگری است. Timeline باید با Event Log، Configuration History، Ticket تغییرات، زمان Reboot، Backup Job History و گفته افراد درگیر تطبیق داده شود. ابتدا آخرین زمانی را که سرویس سالم بوده مشخص کن و بعد اولین زمانی را که خرابی قطعی مشاهده شده پیدا کن. هر تغییری که در این بازه انجام شده فهرست کن. اگر ابزار Audit داری به حافظه افراد تکیه نکن. در مسئله‌های دوره‌ای نیز Timeline بسیار مهم است؛ اگر Packet Loss هر روز ساعت ۱۳ رخ می‌دهد، ممکن است Backup، Sync، Scan یا مصرف پهنای باند زمان‌بندی‌شده در همان ساعت فعال شود. هنگام Rollback نیز فقط همان Change مرتبط را برگردان و قبل و بعد از آن تست یکسان انجام بده. هدف Timeline ساختن یک داستان قابل اثبات از «قبل از خرابی، شروع خرابی و رویدادهای هم‌زمان» است، نه پیدا کردن سریع یک مقصر.

یکی از اشتباه‌های رایج این است که به محض دیدن خطا شروع به Reset و Restart کنیم. Restart گاهی سرویس را برمی‌گرداند، اما وضعیت Sessionها، Queueها، Connectionها و بعضی خطاهای موقت را پاک می‌کند و علت اصلی را پنهان می‌سازد. قبل از تغییر، تا جایی که شدت Incident اجازه می‌دهد شواهد مرتبط جمع کن: Screenshot خطای کاربر، IP Configuration، DNS Query، Route Table، وضعیت Link، Eventهای هم‌زمان، وضعیت Service، مصرف CPU/RAM/Disk، Counterهای Interface، Logهای Firewall و Job History. تاریخ و ساعت Client، Server و تجهیزات شبکه را هم بررسی کن، چون اگر زمان‌ها هماهنگ نباشند تطبیق Logها دشوار می‌شود. Evidence باید هدفمند باشد؛ جمع‌آوری حجم زیادی Log بدون بازه زمانی و سؤال مشخص معمولاً تحلیل را سخت‌تر می‌کند. در Incident بحرانی ممکن است Restore Service اولویت داشته باشد، اما حتی در آن حالت ثبت چند نشانه کلیدی قبل از Restart ارزش زیادی دارد. اگر لازم شد موضوع را به Vendor یا تیم دیگر Escalate کنی، Error دقیق، Version/Build، زمان رخداد، مراحل بازتولید و Log مرتبط بسیار مفیدتر از جمله «کار نمی‌کند» است.

برای عیب‌یابی پیچیده بهتر است علاوه بر مدل لایه‌ای، مسیر واقعی سرویس را در ذهن یا روی کاغذ رسم کنی. فرض کن کاربر می‌خواهد Share با آدرس \FILE01\Data را باز کند. Client باید IP معتبر داشته باشد، نام FILE01 را Resolve کند، Route مناسب داشته باشد، VLAN و Firewall اجازه عبور بدهند، Server قابل دسترس باشد، سرویس SMB روی پورت لازم پاسخ دهد، احراز هویت Domain انجام شود و در پایان Share Permission و NTFS Permission اجازه دسترسی بدهند. Ping موفق فقط بخشی از مسیر IP را نشان می‌دهد و سلامت SMB، DNS، Authentication یا Permission را ثابت نمی‌کند. برای یک وب‌سایت هم مسیر شامل DNS، Route، TCP، TLS و خود Application است. با رسم این زنجیره می‌توانی برای هر حلقه یک تست مشخص تعریف کنی. وقتی یک تست Fail شد، می‌دانی کدام بخش‌های قبل احتمالاً سالم‌اند و کدام بخش‌های بعد هنوز بررسی نشده‌اند. این روش جلوی جمله‌های گمراه‌کننده‌ای مثل «اینترنت هست پس شبکه سالم است» یا «Ping دارم پس سرور سالم است» را می‌گیرد و کمک می‌کند یک Fault در DNS را با خرابی Application اشتباه نکنی.

وجود ابزارهای مدیریتی پیشرفته نباید باعث شود لایه فیزیکی فراموش شود. کابل معیوب، Patch Cord شل، پورت خاموش، SFP مشکل‌دار، PoE ناپایدار یا برق نامناسب می‌تواند تمام لایه‌های بالاتر را بی‌اثر کند. وقتی یک Endpoint هیچ ارتباطی ندارد، قبل از DNS و Firewall وضعیت Link را ببین. چراغ Link، وضعیت Interface در سیستم‌عامل و Switch، Speed Negotiation، CRC/FCS Error و تعداد Link Up/Down سرنخ‌های مهم‌اند. چراغ روشن سلامت کامل را ثابت نمی‌کند؛ ممکن است Link برقرار باشد ولی Error یا Packet Loss وجود داشته باشد. کابل را با نمونه سالم شناخته‌شده مقایسه کن و در صورت نیاز دستگاه را روی پورتی با Configuration مشابه تست کن. جابه‌جایی پورت بدون دانستن VLAN یا Port Security ممکن است نتیجه آزمایش را خراب کند. در PoE، روشن‌بودن دستگاه هم همیشه ثابت نمی‌کند توان کافی و پایدار دریافت می‌کند. در لینک فیبر یا رادیویی باید کیفیت سمت مقابل و Counterهای Interface را هم دید. بررسی لایه فیزیکی به این معنی نیست که هر خرابی را به کابل نسبت بدهی؛ قبل از رفتن سراغ لایه‌های پیچیده فقط باید با شواهد مطمئن شوی مسیر فیزیکی قابل اعتماد است.

وقتی Client به شبکه متصل است اما سرویس‌ها کار نمی‌کنند، IP Configuration اولین تصویر منطقی از وضعیت شبکه می‌دهد. فقط به وجود یک IPv4 Address نگاه نکن. Address باید در Subnet درست باشد، Prefix یا Subnet Mask باید با طراحی شبکه مطابقت داشته باشد، Default Gateway باید در مسیر منطقی قرار گیرد و DNS Serverها باید همان‌هایی باشند که محیط انتظار دارد. در Domain، استفاده مستقیم از Public DNS روی Client می‌تواند پیدا کردن Domain Controller و سرویس‌های AD را مختل کند، حتی وقتی وب‌گردی ظاهراً سالم است. اگر Client آدرس 169.254.x.x گرفته باشد، معمولاً DHCP معمولی کامل نشده و Windows از Link-local/APIPA استفاده کرده است؛ در این وضعیت قبل از اینترنت باید مسیر DHCP را بررسی کنی. IP دستی می‌تواند Duplicate IP یا Gateway اشتباه ایجاد کند. وجود چند Adapter مثل Ethernet، Wi‑Fi، VPN و Hyper-V نیز ممکن است Route و DNS متفاوت بسازد. یک Client سالم در همان VLAN بهترین مرجع مقایسه است. هدف حفظ‌کردن چند عدد نیست؛ باید بتوانی از روی IP، Prefix، Gateway و DNS بفهمی Client در کدام شبکه قرار دارد و برای رسیدن به مقصد چه وابستگی‌هایی دارد.

برای ارسال Packet IPv4 به مقصدی در همان Subnet، سیستم باید بداند آن IP با کدام MAC Address مرتبط است. ARP این نگاشت را فراهم می‌کند. اگر Client IP صحیح دارد ولی Gateway محلی را نمی‌بیند، ARP Table می‌تواند نشان دهد آیا درخواست برای MAC Gateway پاسخ گرفته یا نه. نبود Entry معتبر می‌تواند از VLAN اشتباه، Gateway Down، Link مشکل‌دار یا نرسیدن Broadcast ناشی شود. وجود Entry نیز سلامت کامل مسیر را ثابت نمی‌کند؛ فقط نشان می‌دهد نگاشت لایه ۲ در آن لحظه ایجاد شده است. Duplicate IP می‌تواند ARP Table را ناپایدار کند و باعث شود ترافیک گاهی به MAC اشتباه برود. در Switch مدیریتی، MAC Address Table نیز نشان می‌دهد MAC Client روی کدام Port و VLAN دیده می‌شود. اگر یک MAC مرتب بین دو Port جابه‌جا شود، Loop، جابه‌جایی واقعی دستگاه یا طراحی خاص شبکه باید بررسی شود. ARP را به‌عنوان پلی میان IP و Ethernet ببین. این ابزار زمانی ارزش زیادی دارد که Ping به Gateway Fail است اما Link Up و IP Configuration ظاهراً درست است.

Client برای مقصدهای خارج از Subnet محلی از Routing Table استفاده می‌کند. Default Gateway فقط یکی از Routeهاست و زمانی به‌کار می‌رود که Route اختصاصی‌تری وجود نداشته باشد. VPN، چند کارت شبکه، Hyper-V یا Route دستی می‌تواند باعث شود Packet از مسیری متفاوت با انتظار تو خارج شود. در عیب‌یابی باید بپرسی «برای این Destination دقیقاً کدام Route انتخاب می‌شود؟» Route با Prefix خاص‌تر معمولاً بر Route عمومی‌تر مقدم است و Metric بین Routeهای قابل مقایسه نقش دارد. به همین دلیل کارکرد اینترنت ثابت نمی‌کند Route به شبکه خصوصی شرکت سالم است. برعکس، ممکن است سرویس داخلی کار کند ولی Default Route اینترنت اشتباه باشد. چند Default Route روی Adapterهای متفاوت می‌تواند رفتار دوره‌ای و سخت‌تشخیص ایجاد کند. در VPN نیز Split Tunnel یا Full Tunnel مشخص می‌کند کدام Prefix از Tunnel عبور کند. افزودن Route دستی قبل از فهم علت نبود Route درست ممکن است فقط Symptom را پنهان کند. Route Table را همراه IP Configuration و Traceroute بخوان تا بفهمی سیستم واقعاً تصمیم گرفته Packet را به کجا تحویل دهد.

Ping و Traceroute ابزارهای پایه عیب‌یابی‌اند، اما باید دقیق بدانی چه چیزی را ثابت می‌کنند. Ping با ICMP Echo معمولاً بررسی می‌کند آیا مقصد پاسخ می‌دهد و زمان رفت‌وبرگشت تقریبی چقدر است. Ping موفق یعنی بخشی از مسیر IP در آن لحظه کار می‌کند؛ اما سرویس مقصد، پورت TCP، DNS، Authentication یا Application هنوز می‌توانند خراب باشند. Ping ناموفق نیز الزاماً به معنی Down بودن مقصد نیست، چون ICMP ممکن است در Firewall محدود شده باشد. Traceroute با TTL تلاش می‌کند Hopهای مسیر را نشان دهد و برای فهمیدن تغییر مسیر یا نقطه‌ای که پاسخ‌ها متوقف می‌شوند مفید است، اما بعضی Routerها به Probe پاسخ نمی‌دهند و ستاره در خروجی همیشه نشانه خرابی آن Hop نیست. روش خوب این است که از نزدیک‌ترین نقطه شروع کنی: Loopback، IP خود Client، Gateway، مقصد داخلی و سپس مقصد دورتر. یک مقصد را با Name و IP جدا تست کن تا DNS از Connectivity تفکیک شود. Cisco نیز Ping و Traceroute را ابزارهای رایج عیب‌یابی دسترسی می‌داند، اما تفسیر نتیجه همیشه به Topology و Policy شبکه وابسته است.

DNS یکی از وابستگی‌های اصلی Windows و Active Directory است. وقتی کاربر می‌گوید «سایت باز نمی‌شود» یا «سرور پیدا نمی‌شود»، ابتدا بررسی کن مشکل با Name است یا با IP. اگر اتصال به IP مقصد برقرار است اما Name Resolve نمی‌شود، مسیر بررسی به DNS نزدیک می‌شود. روی Client ببین کدام DNS Serverها تنظیم شده‌اند، Query به کدام Server می‌رود و چه نوع پاسخی برمی‌گردد. Cache محلی می‌تواند پاسخ قدیمی نگه دارد، اما پاک‌کردن Cache نباید اولین واکنش همیشگی باشد؛ اول وضعیت فعلی را ثبت کن تا سرنخ از بین نرود. در Domain، Clientها معمولاً باید DNS داخلی را استفاده کنند تا رکوردهای AD و سرویس‌های داخلی Resolve شوند. Public DNS ممکن است اینترنت را Resolve کند ولی Zone داخلی را نمی‌شناسد. اگر Query Timeout می‌شود، مسیر شبکه، Firewall یا DNS Server مطرح است؛ اگر پاسخ منفی مثل NXDOMAIN برمی‌گردد، Server پاسخ داده ولی رکورد را ندارد. این دو حالت کاملاً متفاوت‌اند. DNS Suffix و FQDN نیز روی Resolution نام‌های کوتاه اثر دارند. عیب‌یابی DNS وقتی دقیق می‌شود که جمله «DNS کار نمی‌کند» را به سؤال مشخص «Query کجا رفت و چه پاسخی گرفت؟» تبدیل کنی.

یک Server ممکن است Ping داشته باشد ولی سرویس مورد نظر کاملاً از دسترس خارج باشد. SMB، HTTPS، RDP، DNS، Kerberos و SQL هرکدام Protocol و Portهای مشخصی دارند و بعد از اثبات IP Connectivity باید همان سرویس را جدا بررسی کنی. شکست اتصال TCP می‌تواند از Firewall روی Client یا Server، ACL میانی، Service خاموش، Listen کردن روی Address اشتباه، Route برگشت یا NAT ناشی شود. Timeout و Connection Refused نیز یک معنی ندارند؛ Refused معمولاً نشان می‌دهد مقصد پاسخ داده اما روی آن Port سرویس پذیرفته نشده، در حالی که Timeout می‌تواند ناشی از Drop در مسیر یا نبود پاسخ باشد. در UDP به دلیل Connectionless بودن، تفسیر متفاوت است و ابزارهای TCP همیشه تصویر کامل نمی‌دهند. روی Server بررسی کن Process یا Service واقعاً Running است و روی Port مورد انتظار Listen می‌کند. هنگام عیب‌یابی، مسیر دوطرفه را فراموش نکن؛ Packet باید به Server برسد و پاسخ هم بتواند برگردد. سؤال درست از «آیا سرور زنده است؟» به «آیا این سرویس مشخص از این Client و این مسیر قابل استفاده است؟» تغییر می‌کند.

وقتی Client برای IPv4 به DHCP وابسته است، دریافت Address تنها یک بخش از فرایند است. درخواست باید روی Segment ارسال شود، DHCP Server یا Relay آن را دریافت کند، Scope مناسب Address آزاد داشته باشد و پاسخ همراه Optionهای لازم مثل Gateway و DNS به Client برگردد. اگر این مسیر کامل نشود، Windows ممکن است آدرس 169.254.x.x از محدوده Link-local/APIPA بگیرد. این نشانه می‌گوید قبل از بررسی اینترنت باید ارتباط Client با DHCP را تحلیل کنی. ابتدا مطمئن شو Adapter روی دریافت خودکار تنظیم است و VLAN درست دارد. بعد Scope، Lease، Reservation، Exclusion و ظرفیت Pool را بررسی کن. اگر Server در VLAN دیگری است، Relay/IP Helper باید Broadcast Client را به Server برساند و پاسخ نیز مسیر برگشت داشته باشد. Release/Renew تست مفیدی است، اما قبل از آن Lease فعلی و Optionها را ثبت کن. اگر Client IP می‌گیرد ولی DNS یا Gateway نادرست است، DHCP ظاهراً پاسخ داده ولی Configuration کامل سالم نیست؛ بنابراین جمله «DHCP کار می‌کند» کافی نیست. باید دقیق بگویی Address، Lease و Optionها کدام‌یک درست یا اشتباه‌اند.

ممکن است IP، DNS و Route روی Client کاملاً درست باشند اما Policy محلی یا امنیتی جلوی سرویس را بگیرد. Windows Firewall بر اساس Profile و Rule کار می‌کند و رفتار Domain، Private و Public Profile می‌تواند متفاوت باشد. اگر Network Profile اشتباه تشخیص داده شود یا Rule تازه‌ای اعمال شود، فقط یک سرویس خاص ممکن است Block شود. روش حرفه‌ای Disable کامل Firewall نیست؛ این کار هم امنیت را کاهش می‌دهد و هم نشان نمی‌دهد دقیقاً کدام Rule علت بوده است. Profile فعال، Direction، Protocol، Port، Scope و Source Policy را بررسی کن. Proxy نیز مخصوصاً برای وب باعث می‌شود Browser یا Application از مسیری متفاوت با Ping استفاده کند. Endpoint Security یا Web Filtering ممکن است تنها یک Domain، Certificate یا Protocol را محدود کند. اگر مشکل فقط یک Client است، این لایه‌ها ارزش بررسی بیشتری دارند. در Domain ممکن است Rule از GPO آمده باشد و تغییر محلی دوباره Override شود؛ بنابراین منبع تنظیم را هم پیدا کن. Logهای Block یا Eventهای مرتبط به‌جای حدس مشخص می‌کنند ترافیک کجا محدود شده است. Firewall، Proxy و Endpoint Security را باید مثل اجزای قابل مشاهده و قابل آزمایش مسیر بررسی کنی، نه چیزهایی که برای تست کورکورانه خاموش شوند.

وقتی Application یا Port کار نمی‌کند، باید وضعیت سرویس داخل سیستم‌عامل را مستقل از شبکه بررسی کنی. یک Server ممکن است Ping داشته باشد و چند سرویس دیگرش سالم باشند، اما Service مورد نظر Stop شده باشد، هنگام Start Fail شود یا بعد از Crash مرتب Restart شود. در Windows، Services Console و Event Viewer برای دیدن Startup Type، Service Account و خطای Start/Stop مفیدند. بعضی سرویس‌ها Dependency دارند؛ Application ممکن است به Database، DNS، Certificate، Storage یا Service دیگری نیاز داشته باشد. Restart کردن Service گاهی موقتاً مشکل را رفع می‌کند، اما قبل از آن Error و زمان رخداد را ثبت کن تا Evidence از دست نرود. وجود Process نیز همیشه به معنی Healthy بودن Application نیست؛ Process ممکن است Running باشد اما روی Port درست Listen نکند یا Threadهایش گیر کرده باشند. سه سؤال جدا بپرس: آیا Service فعال است؟ آیا Port درست را Listen می‌کند؟ آیا Dependencyهایش قابل دسترس‌اند؟ Expire شدن Password یک Service Account یا تغییر Permission روی Folder/Certificate نیز می‌تواند بعد از مدت مشخص باعث Failure شود. این منطق برای CRM، SQL، File Server، Veeam Agent و سرویس‌های مدیریتی کاربرد دارد.

Event Viewer اطلاعات زیادی تولید می‌کند و اگر بدون سؤال مشخص وارد آن شوی با Warning و Errorهای قدیمی زیادی روبه‌رو می‌شوی که شاید هیچ ارتباطی با Incident فعلی نداشته باشند. روش درست از Timeline شروع می‌شود. زمان دقیق خرابی را مشخص کن و بعد Log مرتبط با همان Component را باز کن: System برای Driver و سرویس‌های سیستمی، Application برای برنامه‌ها و Applications and Services Logs برای Componentهایی مثل DHCP یا Group Policy. Event ID به‌تنهایی کافی نیست؛ Source، Level، زمان، Computer و متن Details را کنار هم بخوان. یک Error ممکن است نتیجه خرابی دیگری باشد، نه علت اولیه. مثلاً Service به دلیل Storage یا DNS Fail شود و Event خودش فقط شکست Start را گزارش کند. Microsoft برای DHCP و Group Policy کانال‌های Operational جدا مستند کرده که در عیب‌یابی ارزش زیادی دارند. Filter کردن بازه زمانی و Source کمک می‌کند Noise کم شود. قبل از Clear Log یا Restart، Eventهای مهم را Export یا ثبت کن. اگر چند دستگاه درگیرند، ساعت صحیح روی همه سیستم‌ها اهمیت دارد تا بتوانی Log Client، Server و Network را روی یک Timeline قرار بدهی.

همه Incidentها Down نیستند. گاهی کاربر می‌گوید «شبکه قطع است» اما در واقع Response Time چند ثانیه یا چند ده ثانیه شده است. Ping ساده ممکن است کاملاً طبیعی باشد و مسئله در CPU، Memory Pressure، Disk Latency، Storage Queue، Database یا Application قرار داشته باشد. ابتدا تعریف کن کندی دقیقاً در کدام مرحله دیده می‌شود: Login، بازشدن Share، اجرای Query، کپی فایل یا نمایش صفحه وب. سپس Metric مرتبط را در همان بازه زمانی بررسی کن. Task Manager برای دید اولیه مناسب است، اما در Server یا VMware باید Historical Data و Counterها را هم ببینی. مصرف ۱۰۰٪ CPU فقط نشانه است؛ باید Process و مدت آن را پیدا کنی. Memory Free کم همیشه مشکل نیست چون سیستم‌عامل از Cache استفاده می‌کند؛ Paging و رفتار Workload مهم‌تر است. Disk Active Time بدون Latency و Queue تصویر کامل نمی‌دهد. برای Performance Troubleshooting داشتن Baseline سالم ارزش زیادی دارد؛ اگر نمی‌دانی سرویس در حالت عادی چه اعدادی دارد، تشخیص غیرعادی بودن دشوار می‌شود. عبارت مبهم «کند است» را به Metric، بازه زمانی و Component مشخص تبدیل کن تا بتوانی علت را اندازه‌گیری و مقایسه کنی.

در LAN، Port سوئیچ نقطه اتصال Endpoint به زیرساخت است و باید بیشتر از چراغ Link بررسی شود. ببین Port Up است یا نه، Speed و Duplex چیست، در کدام VLAN قرار دارد و آیا Port Security، Storm Control یا ACL روی آن فعال است. Counterهای Error و Drop را در دو زمان مقایسه کن تا مشخص شود در زمان Incident افزایش دارند یا فقط عددی قدیمی‌اند. اگر Access Port باید در VLAN 20 باشد ولی به VLAN 10 افتاده، Client ممکن است IP بگیرد اما از شبکه اشتباه. اگر Port Trunk است، Allowed VLAN و Native/Untagged دو سمت باید هماهنگ باشند. MAC Address Table کمک می‌کند بفهمی MAC Client روی همان Port و VLAN دیده می‌شود یا نه. جابه‌جایی Client به Port دیگر برای تست فقط وقتی معنی‌دار است که Configuration دو Port معادل باشد؛ در غیر این صورت خود Test یک متغیر جدید وارد می‌کند. در Uplink، Link Flap می‌تواند از کابل، SFP، Negotiation یا Loop ناشی شود. Port را به‌عنوان Interface دارای State، Configuration و Counter ببین، نه یک سوکت ساده.

VLAN مشکل‌هایی ایجاد می‌کند که شبیه خرابی DHCP، Gateway یا Server دیده می‌شوند. Client ممکن است Link داشته باشد اما در Broadcast Domain اشتباه باشد یا VLAN مورد نیاز در یکی از Trunkهای مسیر Allow نشده باشد. ابتدا VLAN مورد انتظار Client را مشخص کن و مسیر آن را از Access Port تا Gateway دنبال کن. هر Trunk باید VLAN را به شکل مورد انتظار حمل کند و Tagged/Untagged بودن دو سمت باید هماهنگ باشد. Native VLAN یا PVID اشتباه می‌تواند ترافیک بدون Tag را به شبکه دیگری ببرد. در RouterOS با Bridge VLAN Filtering باید Bridge Port، PVID و VLAN Table با هم دیده شوند. اگر فقط یک VLAN مشکل دارد اما Uplink Up و VLANهای دیگر سالم‌اند، احتمال Physical Failure کلی کمتر است و بررسی Allowed VLAN یا Gateway همان VLAN منطقی‌تر می‌شود. DHCP می‌تواند به دلیل VLAN اشتباه Lease از Scope دیگری بدهد و همین نشانه مهمی است. هنگام تغییر Production، چند Port را هم‌زمان تغییر نده؛ یک Change محدود انجام بده و نتیجه را در همان Segment تست کن تا معلوم باشد کدام تغییر اثر داشته است.

Ethernet لایه ۲ در برابر Loop حساس است. اگر دو مسیر فعال بدون کنترل مناسب میان سوئیچ‌ها ایجاد شود، Broadcast و بعضی Unknown Unicastها می‌توانند بارها در حلقه بچرخند و لینک و CPU تجهیزات را پر کنند. نشانه‌ها ممکن است کندی شدید، Packet Loss گسترده، MAC Flapping و ناپایداری هم‌زمان چند VLAN باشند. Spanning Tree برای ساخت Topology بدون Loop طراحی شده و بعضی Portها را غیر Forwarding می‌کند؛ بنابراین Blocked بودن یک Port همیشه خرابی نیست و ممکن است رفتار صحیح STP باشد. هنگام Incident، تصادفی Uplinkها را جدا نکن. ابتدا Topology، تغییر کابل‌کشی اخیر، MAC Flap و وضعیت STP را بررسی کن. اگر Loop بعد از اضافه‌شدن Switch unmanaged یا کابل جدید شروع شده، Timeline سرنخ مهمی می‌دهد. BPDU Guard و Loop Protection نیز باید مطابق Design استفاده شوند. حتی در شبکه کوچک، نقشه ساده لینک‌های بین سوئیچ‌ها ارزش زیادی دارد. لازم نیست تمام جزئیات STP را حفظ کنی؛ مهم این است که بفهمی چرا Redundancy بدون Control خطرناک است و چرا Incident گسترده لایه ۲ را با Topology، MAC Table و STP بررسی می‌کنند.

بعضی مشکلات به شکل قطع کامل ظاهر نمی‌شوند؛ کپی فایل کند است، RDP Freeze دارد یا تماس صوتی Drop می‌شود. در این شرایط Counterهای Interface مهم‌اند. CRC/FCS Error می‌تواند با مشکل فیزیکی، کابل یا Connector مرتبط باشد. Drop ممکن است از Congestion، Queue یا محدودیت منابع ناشی شود و باید Context آن را دید. Speed و Duplex در تجهیزات جدید معمولاً با Auto-Negotiation درست کار می‌کنند، اما اجبار ناهماهنگ در دو سمت می‌تواند Performance بد ایجاد کند. فقط دیدن عدد 1 Gbps کافی نیست؛ Rate خطا در طول زمان مهم‌تر است. اگر Counter از ماه‌ها قبل عدد دارد ولی در زمان Incident افزایش نمی‌یابد، ممکن است به مشکل فعلی ربطی نداشته باشد. دو سمت لینک را بررسی کن چون یک سمت ممکن است Error دریافت و سمت دیگر وضعیت متفاوت گزارش کند. در Uplink، Utilization بالا می‌تواند Packet Loss در زمان Peak ایجاد کند. Counter را قبل از ثبت مقدار قبلی Reset نکن تا Evidence از بین نرود. کیفیت لینک را با Trend، دو سمت و مقایسه زمان سالم و خراب بسنج.

در شبکه چند VLAN، DHCP Server اغلب در Broadcast Domain همه Clientها نیست. Router یا Layer 3 Switch باید درخواست DHCP را با Relay به Server منتقل کند. اگر Clientهای یک VLAN IP می‌گیرند و VLAN دیگر APIPA دارد، قبل از متهم‌کردن Server باید Relay، SVI/Gateway و مسیر همان VLAN را بررسی کنی. Scope مربوط به هر Subnet باید وجود داشته، Active باشد و Address آزاد داشته باشد. Relay باید Server درست را بشناسد و پاسخ Server هم مسیر برگشت داشته باشد. Firewall میان Relay و Server می‌تواند فرایند را قطع کند. اگر Pool پر باشد، درخواست به Server می‌رسد ولی Lease مناسب صادر نمی‌شود؛ این با خراب‌بودن Relay فرق دارد. Log DHCP و Packet Capture روی نقطه مناسب کمک می‌کنند ببینی Discover یا Request تا کجا می‌رسد. در Windows Server کانال‌های Event جدا برای DHCP وجود دارد و تغییر Scope، Authorization و خطاها را ثبت می‌کند. زنجیره را مرحله‌ای ببین: آیا Client درخواست می‌فرستد، Relay می‌گیرد، Server Scope را انتخاب می‌کند و پاسخ برمی‌گردد؟ این نگاه دقیق‌تر از Restart ساده DHCP است.

عیب‌یابی Wireless با LAN کابلی فرق دارد چون محیط رادیویی مشترک و متغیر است. کاربر ممکن است Signal ظاهراً خوب ببیند اما به دلیل Interference، Channel شلوغ، Retransmission، Roaming بد یا Authentication مشکل‌دار Performance ضعیف داشته باشد. ابتدا Scope را مشخص کن: یک دستگاه، یک Access Point، یک SSID یا همه کاربران؟ مقایسه همان Client با کابل بسیار مفید است؛ اگر با کابل پایدار است، بخش رادیویی یا Policy SSID اهمیت بیشتری پیدا می‌کند. Signal را همراه Noise و SNR ببین، نه به‌عنوان یک عدد جدا. اگر مشکل هنگام حرکت رخ می‌دهد، Roaming و پوشش بین APها را بررسی کن. اگر Client به SSID وصل می‌شود اما IP نمی‌گیرد، Wireless Association احتمالاً برقرار است ولی VLAN/DHCP بعد از آن مشکل دارد. در 2.4 GHz تداخل و محدودیت Channel بیشتر است و در 5/6 GHz قابلیت Client و طراحی پوشش اهمیت دارد. Cisco در راهنماهای Wireless نیز Configuration، Interference و مشکلات Connectivity را جدا بررسی می‌کند. عبارت «Wi‑Fi ضعیف است» را به یکی از بخش‌های رادیو، Association، VLAN/DHCP یا مسیر IP محدود کن تا محل خرابی قابل بررسی شود.

Latency مدت زمان رفت‌وبرگشت Packet است، Packet Loss نشان می‌دهد چه درصدی از Packetها یا پاسخ‌ها از دست می‌روند و Jitter تغییرپذیری زمان رسیدن آن‌هاست. برای Voice و Video، Jitter و Loss کم هم می‌تواند محسوس باشد، در حالی که Transfer بزرگ بیشتر به Throughput و Loss پایدار حساس است. وقتی کاربر می‌گوید «شبکه کند است»، باید این گزارش را به Metric قابل اندازه‌گیری تبدیل کنی. Ping متوالی دید ساده‌ای از Latency و Loss می‌دهد، اما مقصد، مدت و مسیر تست مهم‌اند. اگر Latency تا Gateway محلی بالا است، Client، Wi‑Fi، LAN یا Switch اولویت دارد؛ اگر Gateway سالم است ولی افزایش از Hopهای بعدی شروع می‌شود، مسیر دیگری مطرح است. Loss فقط در ساعت Peak می‌تواند با Congestion مرتبط باشد، اما Counterهای Interface و Utilization باید این فرضیه را پشتیبانی کنند. Jitter روی Wireless ممکن است با Interference و Retransmission همراه باشد. یک عدد به‌تنهایی بدون Baseline معنای محدودی دارد؛ 20 ms در یک شبکه ممکن است طبیعی و در شبکه دیگر غیرعادی باشد. مقایسه حالت سالم و خراب باید نشان دهد اولین تغییر Metric در کدام نقطه مسیر رخ می‌دهد؛ همان نقطه معمولاً سرنخ مهم‌تری برای ادامه بررسی است.

وقتی مشخص شد Client Query را به DNS Server درست می‌فرستد اما پاسخ مشکل دارد، بررسی از Client به Server منتقل می‌شود. ابتدا Zone مربوط به نام را پیدا کن و ببین Server برای آن Authoritative است یا باید Query را با Forwarder/Recursion ادامه دهد. رکوردهای A/AAAA، CNAME و SRV باید با طراحی سرویس مطابقت داشته باشند. در Active Directory Integrated Zone، داده DNS با Directory Replication ارتباط دارد و خرابی Replication می‌تواند باعث شود دو DNS Server پاسخ متفاوت بدهند. Dynamic Update نیز روی ثبت رکوردهای Client و Service اثر دارد. Microsoft در راهنمای Troubleshooting DNS بررسی IP Configuration، Server Problems، Authoritative Data و Recursion را مرحله‌ای پیشنهاد می‌کند. اگر یک DNS پاسخ درست و دیگری پاسخ قدیمی می‌دهد، Incident می‌تواند Intermittent شود چون Clientها به Serverهای متفاوت Query می‌زنند. TTL نیز تعیین می‌کند Cache چه مدت پاسخ را نگه دارد. حذف دستی رکورد اشتباه اگر DHCP یا Service دوباره همان داده غلط را Register کند فقط Workaround است. منبع ایجاد رکورد را پیدا کن. Resolution را از Client Query تا Zone Data، Forwarding و Replication دنبال کن تا دقیقاً مشخص شود پاسخ در کدام بخش تغییر یا متوقف می‌شود.

یک DHCP Server می‌تواند Service Running داشته باشد اما فقط یک Scope مشکل‌دار باشد، Scope Deactivate شده باشد، Pool پر شده باشد یا Option نادرست توزیع کند. بررسی Server باید از Scope مرتبط با Subnet مشکل‌دار شروع شود. وضعیت Active بودن، Range، Exclusion، Reservation، Leaseهای فعال و Addressهای آزاد را ببین. Optionهای Gateway و DNS اگر اشتباه باشند، Client IP می‌گیرد اما Network یا Domain درست کار نمی‌کند. در Windows Domain، Authorization DHCP نیز طبق طراحی اهمیت دارد. Microsoft برای DHCP Server کانال‌های Operational، Administrative، System و Audit را در Event Viewer مستند کرده و این Logها تغییر Scope، Lease و خطاهای سرویس را نشان می‌دهند. اگر فقط چند Client مشکل دارند، Lease/Reservation و MAC آن‌ها را با Client سالم مقایسه کن. اگر یک VLAN کامل مشکل دارد، Scope و Relay ارزش بیشتری دارند. اگر Failover استفاده می‌شود، State دو Server و Replication تنظیمات هم بررسی می‌شود. به‌جای جمله مبهم «DHCP بالا است»، Scope، Capacity، Option، Authorization و Log را جداگانه بسنج و سپس با گرفتن Lease جدید نتیجه را تأیید کن.

Active Directory Domain Services برای عملیات روزمره به DNS، ارتباط شبکه، زمان هماهنگ و سلامت Domain Controllerها وابسته است. وقتی کاربر Login نمی‌شود یا Group Policy اعمال نمی‌شود، حذف Account و ساخت دوباره آن نباید اولین اقدام باشد. ابتدا بررسی کن Client DNS داخلی درست دارد و می‌تواند Domain Controller مناسب را پیدا کند. سپس زمان Client، DC و منبع Time را ببین، چون Kerberos به اختلاف زمان حساس است. Portها و مسیرهای لازم میان Client و DC و میان DCها نیز باید سالم باشند. اگر چند Domain Controller وجود دارد، Replication ناسالم می‌تواند باعث شود Password، Group Membership یا DNS Record روی یک DC به‌روز باشد و روی دیگری نباشد. Microsoft در راهنماهای Domain Controller و Replication، DNS Resolution، Time، Network Connectivity و Authentication را از وابستگی‌های اصلی می‌داند. برای عیب‌یابی باید بدانی Client با کدام DC صحبت کرده و مشکل روی همه DCها دیده می‌شود یا فقط یکی. Event Viewer، Query رکوردهای SRV، Replication Health و Group Policy Result ابزارهای بعدی‌اند. پیش از دست‌کاری User یا GPO، ابتدا DNS، Time، DC Discovery و Replication را که Directory به آن‌ها وابسته است تأیید کن.

هنگام Join کردن یک Computer به Domain، چند Dependency باید درست باشند. Microsoft در راهنمای Domain Join توضیح می‌دهد که Network Connectivity، DNS Configuration، Security Restriction و Authentication همگی می‌توانند مانع Join شوند. Client باید نام Domain و رکوردهای Service را از DNS داخلی Resolve کند و Domain Controller قابل دسترس باشد. Time و Firewall نیز اهمیت دارند. Credential استفاده‌شده باید Permission لازم داشته باشد و Computer Account موجود یا Conflict احتمالی بررسی شود. متن Error ارزش زیادی دارد؛ پیدا نکردن Domain، Access Denied و Network Path یک مسیر عیب‌یابی ندارند. هنگام Login نیز Cached Logon را از Online Authentication جدا کن. ممکن است Laptop بدون دسترسی به DC با Credential Cache وارد شود، در حالی که تغییر Password جدید هنوز بررسی آنلاین می‌خواهد. پاک‌کردن Computer از Domain و Join دوباره باید بعد از تشخیص انجام شود، نه به‌عنوان اولین راه‌حل. اگر Secure Channel مشکل دارد، علت ایجاد آن را پیدا کن. زنجیره مناسب شامل DNS، DC Discovery، Network/Port، Time، Credential و Computer Account است. با تست هر حلقه می‌توانی محل Failure را دقیق‌تر تعیین کنی.

Kerberos پروتکل اصلی Authentication در بسیاری از سناریوهای Active Directory است و به نام سرویس، Domain Controller/KDC، Ticket و زمان صحیح وابسته است. اگر ساعت Client و DC اختلاف قابل توجه داشته باشد، Authentication می‌تواند Fail شود. Microsoft در Troubleshooting Kerberos بررسی Availability دامنه، Firewall/Portها، DNS و Time را از مراحل اصلی معرفی می‌کند. مشکل Kerberos همیشه Password اشتباه نیست. SPN تکراری یا نادرست، استفاده از Alias نامناسب، Ticket قدیمی یا مشکل ارتباط با KDC می‌تواند Prompt مکرر Credential یا Fallback به روش دیگر ایجاد کند. پشتیبان شبکه لازم نیست تمام جزئیات رمزنگاری را حفظ کند، اما باید مسیر منطقی را بفهمد: Client باید Domain و Service را با Name درست بشناسد، KDC قابل دسترس باشد، ساعت هماهنگ باشد و Ticket مناسب صادر شود. Eventهای Security/System و ابزارهای مشاهده Ticket کمک می‌کنند. تغییر Registry یا Encryption Policy بدون شواهد ریسک بالایی دارد. از عناصر پایه شروع کن و فقط وقتی Logها واقعاً به SPN یا Encryption اشاره دارند وارد تنظیمات پیشرفته شو.

در محیط چند Domain Controller، تغییرات Directory باید میان DCها Replicate شوند. اگر Replication Fail شود، ممکن است Password روی یک DC جدید باشد ولی روی دیگری قدیمی، GPO یا DNS Record یکسان نباشد یا Object تازه در Site دیگر ظاهر نشود. Microsoft در راهنمای Diagnose Replication Failures وابستگی‌هایی مثل Network Connectivity، DNS Resolution، Authentication، Time Accuracy و Replication Topology را فهرست می‌کند. بنابراین هنگام Error Replication فوراً Database یا Registry را دست‌کاری نکن. ابتدا مشخص کن Source DC و Destination DC کدام‌اند و Error دقیق چیست. DNS دوطرفه، FQDN، Time و Portهای لازم باید سالم باشند. Event Logهای Directory Service و DNS Timeline می‌دهند. اگر Failure فقط میان Siteهاست، WAN/VPN و Site Link نیز مطرح‌اند. بعد از اصلاح، فقط سبزشدن یک Status کافی نیست؛ Replication دوباره باید موفق شود و تغییر آزمایشی کم‌ریسک در مسیر مورد انتظار دیده شود. AD را یک سیستم توزیع‌شده ببین، نه چند Server مستقل. یک DC سالم در ظاهر می‌تواند در پشت صحنه از دیگر DCها جدا مانده باشد.

وقتی Policy مورد انتظار روی User یا Computer اعمال نمی‌شود، مسیر پردازش GPO را مرحله‌ای بررسی کن. ابتدا مشخص کن Setting در User Configuration است یا Computer Configuration و Object در کدام OU قرار دارد. Link، Enabled بودن GPO، Security Filtering، WMI Filter و Inheritance می‌توانند Scope را تغییر دهند. سپس Client باید Domain Controller و SYSVOL را از طریق DNS و Network دسترسی داشته باشد. Microsoft برای Group Policy کانال‌های Operational و Eventهای مرتبط با Processing را مستند کرده است. اجرای Update ممکن است Policy را دوباره پردازش کند، اما Scope اشتباه را اصلاح نمی‌کند. Resultant Set of Policy یا ابزار Result نشان می‌دهد کدام GPO واقعاً Apply یا Deny شده و چرا. Conflict چند GPO باید بر اساس Precedence تحلیل شود. اگر فقط یک User مشکل دارد، Group Membership و Scope او را با User سالم مقایسه کن؛ اگر کل OU مشکل دارد، Link و دسترسی به DC اهمیت بیشتری دارد. سؤال‌های اصلی این‌اند: آیا Object در Scope است؟ آیا GPO قابل دسترس است؟ Client هنگام Processing چه نتیجه‌ای ثبت کرده است؟

وقتی یک User مرتب Lock می‌شود، Unlock کردن Account فقط برای مدتی کوتاه سرویس را برمی‌گرداند. علت معمولاً تلاش‌های Authentication با Credential قدیمی از یک دستگاه یا Service است: موبایل، Outlook، RDP Session، Scheduled Task، Windows Service، Drive Mapping یا Credential Manager. زمان Lockout را ثبت کن و روی Domain Controller مرتبط Eventهای Authentication را بررسی کن تا Source احتمالی مشخص شود. در محیط چند DC باید بدانی کدام DC Lock را پردازش کرده است. تغییر Password دوباره بدون پیدا کردن Source می‌تواند تلاش‌های ناموفق را بیشتر کند. Service Account نیز باید با احتیاط بررسی شود؛ Password آن ممکن است در چند Service یا Job استفاده شود. VPN و دستگاه‌های خارج شرکت را فراموش نکن. Credential نادرست را در همان مبدأیی که Lockout را ایجاد می‌کند اصلاح کن؛ تغییر Lockout Threshold فقط نشانه مشکل را پنهان می‌کند. Policy Lockout بخشی از Security سازمان است و تغییرش باید بر اساس Design انجام شود. Timeline دقیق از لحظه Lock تا Sourceهای درگیر معمولاً سریع‌تر از حدس‌زدن نتیجه می‌دهد.

دسترسی به File Share چند مرحله دارد و هر Error باید در همان مرحله بررسی شود. Client ابتدا نام Server را Resolve می‌کند و به Service SMB می‌رسد، سپس Session با Credential معتبر تشکیل می‌شود و در پایان Share Permission و NTFS Permission تعیین می‌کنند User چه کاری انجام دهد. Microsoft در SMB Troubleshooting توصیه می‌کند Connectivity، Protocol و در موارد پیچیده Network Trace دو سمت بررسی شود. اگر Share با IP باز می‌شود ولی با Name نه، DNS/Name Resolution مطرح است. اگر Server دیده می‌شود اما Access Denied می‌گیری، مسیر به Authentication و Permission نزدیک می‌شود. Share Permission و NTFS هر دو روی Effective Access اثر دارند و Group Membership نیز مهم است. Inheritance شکسته یا Deny صریح می‌تواند نتیجه متفاوت بسازد. SMBv1 نباید راه‌حل عمومی برای تجهیزات قدیمی باشد؛ نسخه‌های قدیمی و ناامن باید طبق توصیه Vendor جایگزین یا غیرفعال شوند. قبل از تغییر Permission وضعیت فعلی را مستند کن، چون بازکردن دسترسی برای «تست» می‌تواند اطلاعات محرمانه را در معرض قرار دهد. عبارت «Share باز نمی‌شود» را به مرحله مشخصی از Name Resolution، SMB، Authentication یا Permission تبدیل کن تا بررسی جهت پیدا کند.

خرابی Printer می‌تواند از Device و Network شروع شود یا داخل Print Server، Queue، Driver و Client باشد. Scope را مشخص کن: فقط یک User نمی‌تواند Print کند یا همه کاربران؟ خود Printer Test Page می‌گیرد؟ IP آن قابل دسترس است؟ اگر همه کاربران مشکل دارند، Device، Network یا Print Server اولویت بیشتری دارد. اگر فقط یک Client درگیر است، Driver، Queue و Policy همان Client را بررسی کن. Queue گیرکرده ممکن است چند Job خراب داشته باشد و Spooler را تحت فشار بگذارد. Restart Spooler می‌تواند موقتاً صف را آزاد کند، اما قبل از آن Jobها و Eventها را ثبت کن. اگر Printer از DHCP استفاده می‌کند و IP تغییر کرده، Standard TCP/IP Port قدیمی ممکن است هنوز به Address قبلی اشاره کند؛ Reservation یا IP Plan درست از تکرار جلوگیری می‌کند. Driver ناسازگار نیز ممکن است فقط با یک Application خطا بدهد. در معماری Print Server، مسیر Client تا Server و Server تا Printer دو زنجیره جدا هستند. مشکل «چاپ نمی‌کند» را به Device، Network، Queue، Server یا Client محدود کن تا به‌جای تغییرهای تصادفی، همان لایه معیوب را بررسی کنی.

نرم‌افزارهای سازمانی معمولاً چند Dependency دارند: Client، DNS، Web/App Server، Database، Authentication، Certificate و Storage. وقتی CRM باز نمی‌شود، Ping به Server فقط یک حلقه را بررسی می‌کند. باید معماری سرویس را بدانیم: Client به کدام FQDN و Port وصل می‌شود؟ App Server به کدام Database و با چه Accountی دسترسی دارد؟ Certificate معتبر است؟ Service Account قفل یا Password آن منقضی نشده؟ Disk Server فضا دارد؟ اگر صفحه باز می‌شود ولی Login Fail است، مسیر عیب‌یابی با حالتی که TCP Connection اصلاً ساخته نمی‌شود متفاوت است. در SQL-based Application، Service می‌تواند Running باشد ولی Database Offline یا Storage بسیار کند باشد. Event Log برنامه و Log دیتابیس سرنخ بیشتری از Ping می‌دهند. تغییر Connection String یا Firewall بدون شناخت معماری خطرناک است. بهتر است قبل از Incident برای سرویس‌های مهم Dependency Map داشته باشی. در تست نیز هر لایه را جدا بررسی کن: Name Resolution، Port، TLS، Authentication، Query ساده و در پایان Business Function واقعی. هدف تبدیل «نرم‌افزار کار نمی‌کند» به دقیق‌ترین نقطه ممکن در زنجیره است.

در RouterOS وسوسه زیادی وجود دارد که هر مشکل را فوراً در Firewall جست‌وجو کنیم، اما Packet ممکن است حتی به مرحله Firewall نرسیده باشد. ابتدا Interfaceهای فیزیکی و مجازی را ببین: Running هستند؟ Link Flap یا Error دارند؟ IP روی Interface یا Bridge درست قرار گرفته؟ Bridge Portها عضو Bridge مورد انتظار هستند؟ اگر VLAN Filtering فعال است، PVID و VLAN Table باید با Design هماهنگ باشد. Bridge در RouterOS می‌تواند بخش مهمی از Switching لایه ۲ را انجام دهد و Hardware Offload نیز روی نحوه عبور و مشاهده ترافیک اثر دارد. اگر Client Gateway را نمی‌بیند، ARP و Bridge Host/MAC را بررسی کن تا بفهمی Frame و IP تا کجا می‌رسند. تغییر Bridge Port یا VLAN روی Router تولیدی می‌تواند Management خودت را هم قطع کند، پس قبل از Change مسیر جایگزین دسترسی و Backup/Export Configuration داشته باش. ترتیب منطقی این است: Link و Interface، Bridge/VLAN، IP، Route و بعد Firewall/NAT. این ترتیب کمک می‌کند به جای نگاه کردن به ده‌ها Rule، ابتدا ثابت کنی Packet اصلاً وارد مسیر مورد انتظار شده است.

برای عیب‌یابی دسترسی میان شبکه‌ها یا اینترنت در RouterOS باید Routing، NAT، Firewall و Connection Tracking را کنار Packet Flow ببینی. ابتدا Route به Destination و Route برگشت را تأیید کن. بعد اگر ارتباط NAT می‌شود، Rule مربوط به Source/Destination و Out Interface را بررسی کن. Firewall Filter بر اساس Chain و ترتیب Ruleها تصمیم می‌گیرد؛ Rule بالاتر ممکن است قبل از Rule مورد انتظار Packet را Accept یا Drop کند. Counter Ruleها ارزش زیادی دارند چون نشان می‌دهند Packet واقعاً به آن Rule رسیده یا نه. اگر Counter تغییر نمی‌کند، Match Condition یا مسیر Packet با فرض تو متفاوت است. Connection Tracking وضعیت Sessionها را نگه می‌دارد و FastTrack می‌تواند روی مسیر پردازش و بعضی ابزارهای مشاهده اثر بگذارد. مستندات MikroTik برای Packet Flow و Connection Tracking این تعامل‌ها را توضیح می‌دهد. Disable کردن کل Firewall برای تست Production نه امن است و نه تشخیصی. بهتر است با Rule موقت بسیار محدود، Log روی Match دقیق یا Address List آزمایشی فرضیه را بسنجی و بعد آن را حذف کنی. عبارت «Firewall مشکل دارد» را به Chain، Rule، Match و Counter مشخص تبدیل کن تا بتوانی تصمیم RouterOS را روی همان Packet ببینی.

در بسیاری از شبکه‌های کوچک MikroTik هم Router است، هم DHCP Server و گاهی DNS Resolver/Forwarder. اگر Client IP نمی‌گیرد، DHCP Server مربوط به Interface/VLAN، Pool، Network و Lease را بررسی کن. اگر IP می‌گیرد ولی Gateway یا DNS اشتباه است، Network Statement و Optionها مهم‌اند. Lease Bound فقط نشان می‌دهد Address تخصیص یافته و سلامت Route یا DNS را ثابت نمی‌کند. اگر Clientها MikroTik را به‌عنوان DNS می‌گیرند، Serverهای Upstream، Allow Remote Requests و Cache روی Resolution اثر دارند. در شبکه Domain باید Design روشنی برای DNS داخلی وجود داشته باشد؛ ترکیب تصادفی Public DNS و DNS داخلی می‌تواند AD را دچار مشکل کند. یک Lease سالم و خراب را مقایسه کن. اگر فقط یک VLAN مشکل دارد، Instance DHCP یا Relay همان VLAN را ببین. برای DNS، Query مستقیم به MikroTik و سپس Upstream کمک می‌کند نقطه شکست روشن شود. Log و Packet Sniffer نیز برای دیدن درخواست DHCP/DNS مفیدند. DHCP، DNS و Routing را سه سرویس مستقل ببین؛ اینترنت داشتن Router به‌تنهایی هیچ تضمینی درباره سلامت دو سرویس دیگر نمی‌دهد.

در VPN چند مرحله جدا وجود دارد: Negotiation و Authentication تونل، دریافت Address یا ساخت Interface، Route به شبکه‌های مقصد، Firewall/NAT، DNS و در نهایت خود سرویس داخلی. کاربری که می‌گوید «VPN وصل است ولی Share باز نمی‌شود» احتمالاً مرحله اول را گذرانده اما یکی از مراحل بعدی مشکل دارد. بعد از اتصال، IP و Routeهای Client را ببین. در Split Tunnel فقط Prefixهای مشخص از VPN عبور می‌کنند؛ در Full Tunnel ممکن است Default Route تغییر کند. اگر شبکه خانه کاربر با Subnet شرکت Overlap داشته باشد، Route می‌تواند به LAN محلی برود نه Tunnel. DNS نیز بسیار رایج است: IP Server قابل دسترس است ولی Name داخلی Resolve نمی‌شود. Firewall روی Router و Server باید Source Network VPN را طبق Policy مجاز بداند و Route برگشت نیز وجود داشته باشد. در Site-to-Site، دو سمت باید Route و Policy سازگار داشته باشند. Logهای VPN برای شکست Authentication یا Phaseها مفیدند، اما وقتی Tunnel Established است باید تمرکز را به Routing، DNS و Access Policy منتقل کنی. «Connected» را با «قابل استفاده بودن همه سرویس‌ها» یکی ندان.

RouterOS ابزارهایی دارد که عیب‌یابی عمیق را از حدس به مشاهده تبدیل می‌کنند. Torch دید زنده‌ای از Traffic روی Interface می‌دهد و برای مشاهده Source/Destination، Protocol و حجم Traffic مناسب است. Packet Sniffer می‌تواند Packetهای ورودی، خروجی یا عبوری را Capture و بر اساس Interface، Address و Protocol Filter کند. مستندات MikroTik توضیح می‌دهد Capture را می‌توان برای تحلیل بعدی ذخیره کرد، اما Hardware Offload ممکن است باعث شود برخی ترافیک‌های Bridge در Sniffer دیده نشوند؛ بنابراین نبود Packet در Capture همیشه به معنی نبود Traffic نیست و باید مسیر پردازش را بفهمی. Logging Ruleهای Firewall هم برای Test Match مفید است ولی Logging زیاد روی Production می‌تواند بار و حجم Log را افزایش دهد. قبل از Capture مشخص کن دنبال چه Flowی هستی: Source، Destination، Port و Interface. Capture بدون Filter در شبکه شلوغ تحلیل را سخت می‌کند. سؤال‌های خوب این‌اند: آیا Packet وارد Router شد؟ از Interface خروجی بیرون رفت؟ پاسخ برگشت؟ کدام Rule Counter خورد؟ این اطلاعات نقطه Drop را بسیار دقیق‌تر می‌کند.

وقتی ESXi Host در vCenter به حالت Not Responding یا Disconnected می‌رود، Reboot فوری Host کار درستی نیست. Broadcom برای این وضعیت علت‌های متعددی مطرح می‌کند: Management Network، Packet Loss یا Gateway، LACP/Physical Network، Storage Latency یا APD/PDL، فشار CPU/RAM و پاسخ‌ندادن Agentهایی مثل hostd و vpxa. ابتدا مشخص کن Host از طریق Management IP یا Host Client مستقیماً قابل دسترس است و VMهای روی آن واقعاً Running هستند یا نه. سپس Management Network را از سمت Host و vCenter بررسی کن: IP، Gateway، DNS/FQDN و Portهای مدیریتی. اگر vCenter Heartbeat دریافت نکند Host Not Responding می‌شود، اما این الزاماً به معنی خاموش بودن VMها نیست. Eventهای vCenter و Logهای ESXi Timeline را می‌دهند. Storage مشکل‌دار نیز می‌تواند Management Agentها را کند یا غیرپاسخ‌گو کند. Reconnect در بعضی شرایط مفید است، اما اگر Incident تکرار می‌شود باید Root Cause را پیدا کنی. وضعیت Compute، Network، Storage و Agentها را از Connection State در vCenter جدا ببین.

شبکه VM چند لایه دارد: IP داخل Guest، Virtual NIC، Port Group، vSwitch یا Distributed Switch، vmnic/Uplink فیزیکی و در نهایت Physical Switch/VLAN. اگر VM شبکه ندارد، این زنجیره را به ترتیب دنبال کن. ابتدا داخل Guest IP، Gateway و DNS را بررسی کن. سپس در vSphere ببین vNIC Connected و Connect at Power On است و به Port Group درست وصل شده. VLAN ID Port Group باید با Trunk فیزیکی هماهنگ باشد. بعد وضعیت vmnic و Uplink Teaming را بررسی کن. اگر فقط VMهای یک Port Group مشکل دارند اما Management Network سالم است، احتمال خرابی کلی Host کمتر است. اگر همه VMهای Host ارتباط را از دست داده‌اند، Uplink یا Physical Switch اهمیت بیشتری پیدا می‌کند. در Distributed Switch نیز وضعیت VDS و Configuration آن مهم است. Broadcom در عیب‌یابی شبکه ESXi از Packet Capture و بررسی مسیر Physical استفاده می‌کند. برای مشکل «VM اینترنت ندارد»، مسیر را بین Guest، Port Group، vSwitch، Uplink و Physical Network مرحله‌به‌مرحله محدود کن و چند لایه را هم‌زمان تغییر نده.

Datastore فقط محل فایل VM نیست؛ فضای آزاد و Latency آن روی Power On، Snapshot، Swap و عملکرد VM اثر دارد. اگر Datastore به ظرفیت بحرانی نزدیک شود، Snapshot Delta ممکن است نتواند رشد کند و عملیات Backup یا خود VM با Error روبه‌رو شود. Snapshotهای قدیمی با ادامه Write فضای بیشتری مصرف می‌کنند و Broadcom تأکید می‌کند Snapshot جای Backup نیست. هنگام Incident ابتدا Capacity و Free Space Datastore را ببین و مشخص کن مصرف توسط کدام VM یا Snapshot بالا رفته است. حذف دستی VMDK یا Delta از Datastore بسیار خطرناک است؛ Snapshot Manager و روش پشتیبانی‌شده را استفاده کن. Consolidation Needed نیز باید با فضای کافی و علت ایجاد بررسی شود. Performance فقط Capacity نیست؛ Storage Latency می‌تواند چند VM و حتی Management Agentهای Host را هم‌زمان کند کند. اگر چند VM روی یک Datastore مشترک کند شده‌اند، Storage یک Failure Domain محتمل است. در Datastore Full سراغ پاک‌کردن تصادفی فایل‌ها نرو؛ Snapshot Chain، Backup، Latency و ظرفیت آینده را کنار هم بررسی کن.

وقتی Backup Job Fail می‌شود، اولین کار نباید اجرای دوباره و دوباره Job باشد. Session را باز کن و ببین Failure در کدام Stage رخ داده است: اتصال به Source، Snapshot، Guest Processing، انتقال Data، Repository Write، Merge/Retention یا Verification. هر Stage Dependency متفاوت دارد. Veeam امکان مشاهده History/Logs و Export Support Information را برای Troubleshooting فراهم می‌کند. Error دقیق، Component، زمان و Job Name را ثبت کن. بعد ظرفیت Repository، Connectivity، Credential، Proxy/Transport و وضعیت VMware Snapshot را بر اساس Error بررسی کن. اگر Job Success است اما Restore Test انجام نشده، Restoreability هنوز ثابت نشده است؛ Health Check و Recovery Verification در طراحی مناسب به اعتبارسنجی کمک می‌کنند. Repository کم‌فضا، Chain ناسالم یا Credential تغییرکرده می‌تواند Failure دوره‌ای ایجاد کند. Retry موفق Root Cause را از بین نمی‌برد. RPO واقعی را با زمان آخرین Restore Point سالم بسنج، نه Schedule روی کاغذ. بعد از Fix فقط سبزشدن Job را معیار نهایی ندان و یک Restore یا Verification متناسب انجام بده.

فرض کن کاربران می‌گویند Internet دارند و چند سایت باز می‌شود، اما یک Domain مشخص باز نمی‌شود. اولین نتیجه نباید «اینترنت خراب است» باشد. Scope را مشخص کن: همه کاربران شرکت یا فقط یک Client؟ با Mobile Data همان سایت باز می‌شود؟ Name سایت Resolve می‌شود و به چه IP؟ اگر DNS پاسخ ندارد، مسیر DNS را بررسی کن. اگر IP به دست می‌آید، Port 443 یا 80 را مستقل تست کن. Ping ممکن است توسط سایت Block باشد و معیار مناسبی برای HTTPS نیست. اگر TCP برقرار است اما Browser خطای Certificate/TLS می‌دهد، Date/Time سیستم، Certificate Chain، TLS Inspection یا Proxy را بررسی کن. اگر فقط شبکه شرکت مشکل دارد، Firewall، Web Filter یا DNS Filter مطرح می‌شود. اگر فقط یک Browser درگیر است، Proxy/Extension و Cache همان Client را جدا کن. همچنین ممکن است مشکل Routing فقط روی یک ISP یا مسیر دیده شود؛ Traceroute و مقایسه مسیر دیگر کمک می‌کند. در این سناریو باید عبارت «سایت باز نمی‌شود» را به یکی از بخش‌های DNS، Route، Port، TLS، Policy یا Application محدود کنی.

در این سناریو Ping موفق فقط نشان می‌دهد نوعی ارتباط IP/ICMP تا Server وجود دارد. برای بازشدن Share به Name Resolution، Port و Service SMB، Authentication و Permission نیاز داریم. Share را با FQDN و در صورت نیاز IP تست کن. اگر با IP باز می‌شود ولی Name نه، DNS مطرح است. اگر هیچ‌کدام باز نمی‌شود، Port SMB و Service روی Server را بررسی کن. اگر Share باز می‌شود اما Access Denied می‌گیری، Connectivity تا حد زیادی برقرار است و باید Credential، Group Membership، Share Permission و NTFS Permission را ببینی. Session قدیمی با Credential دیگر نیز می‌تواند رفتار متفاوتی ایجاد کند. Eventهای SMB/Security در Client و Server کمک می‌کنند. در Domain، Time و Authentication نیز اثر دارند. Permission را برای تست به Everyone Full Control تغییر نده؛ Effective Access را برای User مشخص بررسی کن. این سناریو نمونه روشن این اصل است که Ping فقط یک حلقه از زنجیره سرویس را تأیید می‌کند و هر حلقه بعدی هنوز باید تست شود.

سه الگوی مهم را همیشه در ذهن داشته باش. اول، Client IP معتبر دارد ولی Internet ندارد: IP، Prefix، Gateway و DNS را با Known Good مقایسه کن، Gateway را تست کن، بعد IP بیرونی را جدا از Name بررسی کن و در Router به Default Route، WAN، NAT و Firewall برس. دوم، فقط یک User مشکل دارد و بقیه سالم‌اند: همان User را روی Machine دیگر و User سالم را روی همان Machine مقایسه کن تا Account/Profile از Device جدا شود؛ DNS، Credential Cache، Group Membership، Proxy و Endpoint Security تفاوت‌های مهم‌اند. سوم، مشکل Intermittent است و وقتی می‌رسی همه چیز سالم شده: در این حالت باید قبل از رخداد Logging و Monitoring هدفمند آماده کنی، ساعت دقیق Incident را از User بگیری و آن را با Event، Counter، WAN Flap، Backup Job، DHCP Lease یا Wi‑Fi Roaming تطبیق دهی. در هر سه سناریو بعد از Fix همان تستی را که Fail می‌شد دوباره اجرا کن، اثر جانبی Change را بسنج و Root Cause را فقط وقتی قطعی بنویس که Evidence از آن پشتیبانی کند. اگر مسئله نیاز به Escalation دارد، Scope، Timeline، Tests، Results، Version و Logهای مرتبط را منتقل کن. در پایان Incident یک Runbook قابل استفاده بساز تا دفعه بعد تیم از صفر شروع نکند.