عیب‌یابی IPv4 و Subnetting

جمع‌آوری اطلاعات و بررسی IP/Prefix

قبل از تغییر تنظیمات، وضعیت فعلی را ثبت کن. روی Windows دستور ipconfig /all، روی Linux دستور ip addr و ip route و روی macOS ابزارهای مربوط به Network Settings یا ifconfig/ipconfig می‌توانند اطلاعات لازم را نشان دهند. چیزی که نیاز داریم IP، Prefix یا Mask، Gateway و نحوه دریافت آدرس است.

C:\> ipconfig /all
IPv4 Address . . . . . : 192.168.10.70
Subnet Mask  . . . . . : 255.255.255.192
Default Gateway  . . . : 192.168.10.1

همین سه خط ممکن است مشکل را نشان دهند. /26 یعنی Client در شبکه 192.168.10.64/26 است، ولی Gateway برابر .۱ در شبکه 192.168.10.0/26 قرار دارد. پس Gateway از دید Client Local نیست و Configuration مشکوک است. اول مطمئن شو IP داخل Host Range معتبر Subnet است. اگر Client روی Network Address یا Broadcast تنظیم شده باشد، Configuration اشتباه است. مثلاً در 192.168.10.64/26، آدرس .64 Network و .127 Broadcast است و Hostهای معمول بین .۶۵ تا .۱۲۶ قرار می‌گیرند. بعد نوع Address را هم ببین. اگر Client انتظار دارد از DHCP شبکه سازمان آدرس بگیرد ولی 169.254.x.x دارد، مسیر عیب‌یابی به سمت DHCP یا Connectivity اولیه می‌رود. Prefix اشتباه می‌تواند رفتار عجیبی بسازد. فرض کن دو سیستم 192.168.10.20 و 192.168.10.100 هستند. اگر یکی /24 و دیگری /26 باشد، دید آن‌ها نسبت به Local و Remote یکسان نیست. ممکن است یک طرف مقصد را Local بداند و طرف دیگر مسیر متفاوتی انتخاب کند. در عیب‌یابی باید Prefix دو طرف و Gatewayها را کنار هم ببینی. فقط مقایسه IP کافی نیست.

عیب‌یابی IPv4 از جمع‌آوری داده شروع می‌شود، نه تغییر Configuration. روی Client ابتدا IP، Prefix، Gateway و روش دریافت آدرس را ببین. در Windows خروجی ipconfig /all معمولاً اطلاعات لازم را می‌دهد. اگر IP از Range مورد انتظار نیست، قبل از Ping اینترنت باید بفهمی این آدرس از کجا آمده و آیا با VLAN و DHCP همان بخش سازگار است. اگر آدرس 169.254.x.x دیده می‌شود، سیستم IPv4 Link-Local گرفته و احتمالاً Configuration قابل مسیریابی مورد انتظار را از DHCP دریافت نکرده است. این نتیجه هنوز ثابت نمی‌کند DHCP Server خاموش است؛ ممکن است VLAN، Trunk، DHCP Relay، Port یا خود Client مشکل داشته باشد. تست بعدی باید مسیر درخواست DHCP را محدود کند. Prefix را دقیقاً با Address Plan مقایسه کن. IP درست با Mask اشتباه می‌تواند از نظر ظاهری طبیعی باشد ولی تصمیم Local/Remote را خراب کند. به همین دلیل «IP درست است» جمله کاملی نیست؛ باید بگویی IP و Prefix هر دو مطابق طراحی هستند.

Gateway و مسیر تست از نزدیک به دور

Gateway باید داخل Subnet Client قرار بگیرد و از نظر Link و VLAN قابل دسترس باشد. ابتدا محاسبه Subnet را انجام بده، بعد خود Gateway را Ping کن. اگر Ping Gateway شکست خورد، هنوز رفتن سراغ DNS یا Remote Server زود است.

ping 192.168.10.1

موفق نبودن Ping همیشه به معنی خاموش بودن Gateway نیست، چون ICMP ممکن است فیلتر شود. ولی در شبکه داخلی که انتظار پاسخ داریم، نتیجه یک سرنخ مهم است و باید با ARP، Interface Status و Configuration تکمیل شود. یک ترتیب عملی می‌تواند این باشد: Link را بررسی کن، IP/Mask/Gateway را ثبت کن، نوع Address را تشخیص بده، Network و Host Range را حساب کن، Gateway را از نظر Subnet بررسی کن، بعد Reachability را تست کن. اگر این مراحل سالم بودند، سراغ Routing، DNS یا Application برو. این ترتیب باعث می‌شود یک مشکل ساده Prefix با تغییرات بی‌ربط در DNS یا Firewall پیچیده نشود. CCNA روی Troubleshoot کردن IPv4 Address Configuration، Assignment و Subnetting تاکید دارد، پس باید بتوانی از داده واقعی به علت نزدیک شوی. بعد Gateway را بررسی کن. Gateway باید در همان Subnet Client باشد و Interface مربوط روی Router یا L3 Switch فعال باشد. Ping Gateway تست خوبی برای شروع است، چون اگر پاسخ بدهد بخشی از اتصال Local، ARP و رسیدن تا دستگاه Layer 3 را تأیید می‌کند. اگر پاسخ نمی‌دهد، هنوز دلیل کافی برای تغییر DNS وجود ندارد.

ترتیب تست از نزدیک به دور کمک می‌کند هر مرحله یک فرضیه را حذف کند: Loopback یا Stack محلی در صورت نیاز، IP خود Interface، Gateway، یک مقصد Remote با IP، و در نهایت نام DNS. اگر 8.8.8.8 قابل دسترس است ولی نام سایت Resolve نمی‌شود، تازه DNS به مظنون جدی تبدیل می‌شود. اگر Gateway هم Ping نمی‌شود، مشکل پایین‌تر قرار دارد.

بررسی Interface و وضعیت شبکه

روی Router یا Layer 3 Switch، show ip interface brief برای دیدن سریع IP و وضعیت Interfaceها مفید است. بعد Configuration همان Interface را بررسی می‌کنیم تا Mask دقیق را ببینیم.

Router# show ip interface brief
Interface              IP-Address      Status      Protocol
GigabitEthernet0/0     192.168.10.1    up          up

Router# show running-config interface GigabitEthernet0/0
interface GigabitEthernet0/0
 ip address 192.168.10.1 255.255.255.0

اگر Client /26 باشد ولی Router Interface /24، طراحی Addressing دو طرف یکسان نیست و باید با مستندات مقایسه شود. برای Client معمولاً از نزدیک‌ترین بخش شروع کن. اول Link و IP خود سیستم، بعد Gateway، بعد یک مقصد Remote شناخته‌شده و بعد سرویس‌هایی مثل DNS. این ترتیب کمک می‌کند محدوده خرابی قدم‌به‌قدم کوچک شود.

۱) بررسی IP/Mask/Gateway
2) ping Default Gateway
3) ping یک IP در شبکه Remote
۴) بررسی DNS اگر IP کار می‌کند ولی Name نه

این ترتیب مطلق نیست، ولی از تغییرات تصادفی جلوگیری می‌کند. اگر Gateway هنوز در دسترس نیست، عوض کردن DNS هیچ کمکی به همان مشکل نمی‌کند. روی Cisco IOS وضعیت Interface و آدرس آن را با show ip interface brief و show running-config interface ... بررسی کن. up/up بودن Interface نشان می‌دهد Link پایه برقرار است، اما Prefix و VLAN هنوز باید کنترل شوند. اگر Interface administratively down است، قبل از بررسی Routing باید علت shutdown مشخص شود. هر خروجی فقط همان بخشی را که نشان می‌دهد تأیید می‌کند.

show ip interface brief
show running-config interface GigabitEthernet0/0
show ip route connected

Route متصل یا Connected Route باید با Prefix Interface سازگار باشد. اگر روی Interface 192.168.50.1/26 تنظیم شده، Router باید شبکه متصل متناظر را در Routing Table داشته باشد. اگر چیزی که در جدول می‌بینی با Address Plan نمی‌خواند، Configuration Mask را دوباره بررسی کن.

Duplicate IP و تفاوت DHCP با Static

Duplicate IP زمانی رخ می‌دهد که دو دستگاه یک IPv4 Address یکسان استفاده کنند. علائم می‌تواند قطع و وصل شدن ارتباط، تغییر MAC مرتبط با IP در جدول ARP یا هشدار سیستم‌عامل باشد. این مشکل معمولاً از Static IPهای بدون مستندات یا DHCP Pool نامناسب ایجاد می‌شود. برای حل، فقط یکی از دستگاه‌ها را Restart نکن. باید مشخص شود IP طبق Address Plan به کدام دستگاه تعلق دارد و منبع تخصیص تکراری اصلاح شود. Mask متفاوت در دو دستگاه گاهی ارتباط یک‌طرفه یا رفتار نامنظم می‌سازد. یک سیستم ممکن است مقصد را Local بداند و مستقیماً ARP کند، در حالی که طرف مقابل همان آدرس را Remote تشخیص دهد و پاسخ را به Gateway بفرستد. نتیجه می‌تواند به Topology و Routing بستگی داشته باشد و تشخیص را سخت کند. وقتی رفتار عجیب است، Mask دو طرف را حتماً با Address Plan مقایسه کن. فقط چون IPها درست به نظر می‌رسند، Prefix را سالم فرض نکن. قبل از اصلاح IP بپرس Address باید از DHCP بیاید یا Static باشد. اگر Client DHCP است، وارد کردن دستی یک IP شاید موقتاً ارتباط را برگرداند ولی علت اصلی را پنهان می‌کند. باید بفهمی چرا DHCP Address درست نداده.

اگر دستگاه Static است، Address Plan را مرجع قرار بده و IP، Prefix و Gateway را با مقدار مستند مقایسه کن. روش عیب‌یابی بسته به منبع Address فرق می‌کند. Duplicate IP زمانی رخ می‌دهد که دو دستگاه یک IPv4 یکسان را در یک شبکه استفاده کنند. نتیجه می‌تواند قطع‌ووصلی، تغییر مداوم ARP Entry یا دسترسی یکی از دو دستگاه به جای دیگری باشد. اگر مشکل متناوب است و با خاموش شدن یک دستگاه حل می‌شود، Duplicate IP یکی از فرضیه‌های مهم است. DHCP Pool و Static Range را هم بررسی کن تا IP ثابت داخل Pool توزیع نشود. مشخص کن آدرس Client Static است یا از DHCP آمده. اگر فقط یک Client Static مشکل دارد و بقیه DHCP Clientها سالم‌اند، احتمال خطای دستی در IP/Mask/Gateway بیشتر می‌شود. اگر همه Clientهای یک VLAN IP نامعتبر می‌گیرند، مشکل مشترک‌تر است و باید DHCP Scope، Relay یا مسیر Layer 2 آن VLAN بررسی شود.

تحلیل سناریو و ثبت نتیجه تست‌ها

Client آدرس 10.20.30.126/26 و Gateway برابر 10.20.30.65 دارد. /26 Block Size برابر ۶۴ است. Subnetهای مربوط ۰-۶۳، ۶۴-۱۲۷ و ... هستند. Client .۱۲۶ و Gateway .۶۵ هر دو داخل 10.20.30.64/26 قرار دارند، پس از نظر Subnet درست‌اند. اگر ارتباط با Gateway قطع است، حالا بررسی Link، VLAN و Interface معنی دارد. اگر Gateway به جای .۶۵ برابر 10.20.30.1 بود، قبل از هر تست پیچیده یک خطای Addressing واضح داشتیم. همین محاسبه سریع جلوی اتلاف وقت را می‌گیرد. اگر مستند می‌گوید VLAN کاربران 10.20.30.0/24 است ولی DHCP به Clientها /26 می‌دهد، یکی از منابع اشتباه یا قدیمی است. Configuration واقعی Router، DHCP و Client را کنار هم قرار بده تا مشخص شود طراحی اجراشده چیست. هدف Troubleshooting پیدا کردن یک مقصر سریع نیست؛ باید داده‌ها با هم سازگار شوند. وقتی IP، Mask، Gateway و Network Boundary همه با یک طرح منطقی هماهنگ شدند، تازه می‌توانی Addressing را با اطمینان از فهرست علت‌ها کنار بگذاری. وقتی چند تغییر پشت سر هم انجام می‌دهی، ممکن است ندانی کدام تغییر مشکل را حل کرده. بهتر است هر مرحله را ثبت کنی: Configuration اولیه چه بود، چه Testی انجام شد، نتیجه چه بود و چه چیزی تغییر کرد. این کار هم برای یادگیری و هم برای Ticket و مستندسازی ارزش دارد.

اگر مشکل بعداً برگشت، همین سابقه کمک می‌کند دوباره از صفر حدس نزنی. Troubleshooting حرفه‌ای فقط پیدا کردن سریع مشکل نیست؛ باید بتوانی مسیر تشخیص را توضیح بدهی و نتیجه را قابل تکرار نگه داری. سناریوی ترکیبی را با ثبت نتیجه هر تست جلو ببر. مثلاً Client 10.20.30.126/26 دارد، Gateway 10.20.30.65 است و Gateway Ping می‌شود. این دو در شبکه 10.20.30.64/26 قرار دارند، پس Addressing پایه سازگار است. اگر مقصد Remote Ping نمی‌شود، مرحله بعد Routing یا Policy بعد از Gateway است؛ برگشتن به تعویض کابل بدون سرنخ منطقی نیست. مستندات را با واقعیت مقایسه کن. ممکن است روی Diagram شبکه VLAN 20 برابر 192.168.20.0/24 نوشته شده باشد ولی DHCP Scope اشتباهاً /23 باشد. اگر فقط به یک منبع اعتماد کنی، ممکن است خطا را نبینی. Address Plan، DHCP، Configuration Gateway و Client باید با هم سازگار باشند. در پایان عیب‌یابی علت، تغییر انجام‌شده و Verification را ثبت کن. مثلاً بنویس «Mask کلاینت /16 بود، طبق Address Plan به /24 اصلاح شد؛ Ping Gateway و Server داخلی موفق شد». چنین ثبت دقیقی هم برای Incident بعدی مفید است و هم نشان می‌دهد مشکل با حدس و Reset تصادفی حل نشده است.