امنیت
فهرست مطالب
از آنجایی که بروز مشکل در فرآیند پیاده‌سازی شبکه‌های کامپیوتری اجتناب‌ناپذیر است، توانایی عیبیابی آی‌پی (IP) یک مهارت حیاتی محسوب می‌شود. به بیان دقیق‌تر، اگر فردی باشید که ابزارهای لازم برای تشخیص و رفع مشکلات اجتناب‌ناپذیر را دارد، هنگام حل این مسائل به قهرمان سازمان خود تبدیل خواهید شد. شیرینی ماجرا این است که معمولا می‌توانید یک شبکه IP را بدون حضور در محل تعمیر کنید!
در این مقاله قصد داریم “راهکارهای پیشنهادی سیسکو” در ارتباط با عیبیابی آی‌پی را مورد بررسی قرار دهیم. برای شروع اجازه دهید کار را با یک سناریو آغاز کنیم. متاسفانه، حمید نمی‌تواند وارد ویندوز سرور شود. چه کاری باید انجام دهد؟ با تیم فنی مایکروسافت تماس برقرار کند و به آن‌ها اعلام کند سیستم عامل سرور آن‌ها بی‌فایده است، آیا در این حالت تمام مشکلات او حل می‌شود؟ پاسخ قطعا منفی است. بنابراین، باید دست به کار شود و گام به گام به سراغ شناسایی و برطرف کردن مشکل برود.
اجازه دهید روش عیبیابی پیشنهادی سیسکو بر مبنای یک رویکرد گام به گام و واضح را بررسی کنیم. این مراحل بسیار ساده هستند؛ ابتدا تصور کنید در محل مشتری هستید که شکایت دارد قادر نیست با یک سرور که اتفاقا در یک شبکه راه دور قرار دارد، ارتباط برقرار کند. در این سناریو، چهار مرحله عیبیابی که سیسکو توصیه می‌کند به شرح زیر است:
۱. از پنجره خط فرمان، به آدرس IP میزبان محلی پینگ کنید (ما در اینجا پیکربندی صحیح را فرض می‌کنیم، اما همیشه پیکربندی IP را نیز بررسی کنید!). اگر این دستور با موفقیت انجام شود، کارت رابط شبکه (NIC) به درستی کار می‌کند، اگر با شکست روبرو شود، مشکلی در NIC وجود دارد. فقط به این نکته توجه داشته باشید که موفقیت در این مرحله لزوما به این معنی نیست که یک کابل به NIC متصل است، بلکه فقط به این معنی است که پشته پروتکل IP روی میزبان می‌تواند از طریق درایور LAN با NIC ارتباط برقرار کند:
C:\>ping 127.0.0.1
Pinging 127.0.0.1 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Ping statistics for 127.0.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
۲. از پنجره خط فرمان، به آدرس IP میزبان محلی پینگ کنید (ما در اینجا پیکربندی صحیح را فرض می‌کنیم، اما همیشه پیکربندی IP را نیز بررسی کنید!). اگر این دستور با موفقیت انجام شود، کارت رابط شبکه (NIC) به درستی کار می‌کند، اگر با شکست روبرو شود، مشکلی در NIC وجود دارد. فقط به این نکته توجه داشته باشید که موفقیت در این مرحله لزوما به این معنی نیست که یک کابل به NIC متصل است، بلکه فقط به این معنی است که پشته پروتکل IP روی میزبان می‌تواند از طریق درایور LAN با NIC ارتباط برقرار کند:
C:\>ping 172.16.10.1
Pinging 172.16.10.1 with 32 bytes of data:
Reply from 172.16.10.1: bytes=32 time
Reply from 172.16.10.1: bytes=32 time
Reply from 172.16.10.1: bytes=32 time
Reply from 172.16.10.1: bytes=32 time
Ping statistics for 172.16.10.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
۳. از پنجره خط فرمان، آدرس IP درگاه پیش‌فرض (روتر) را پینگ کنید. اگر دستور پینگ کار کند، به این معنی است که NIC به شبکه متصل است و می‌تواند در شبکه محلی ارتباط برقرار کند. اگر با شکست روبرو شود، شما یک مشکل فیزیکی در شبکه محلی دارید که می‌تواند در هر جایی از NIC تا روتر باشد:
C:\>ping 172.16.10.1
Pinging 172.16.10.1 with 32 bytes of data:
Reply from 172.16.10.1: bytes=32 time
Reply from 172.16.10.1: bytes=32 time
Reply from 172.16.10.1: bytes=32 time
Reply from 172.16.10.1: bytes=32 time
Ping statistics for 172.16.10.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
۴. اگر مراحل ۱ تا ۳ موفقیت‌آمیز بودند، سعی کنید به سرور راه دور پینگ کنید. اگر این کار موفقیت‌آمیز بود، آنگاه می‌دانید که ارتباط IP بین میزبان محلی و سرور راه دور برقرار است. همچنین، می‌دانید که شبکه فیزیکی راه دور نیز به درستی کار می‌کند:
C:\>ping 172.16.20.2
Pinging 172.16.20.2 with 32 bytes of data:
Reply from 172.16.20.2: bytes=32 time
Reply from 172.16.20.2: bytes=32 time
Reply from 172.16.20.2: bytes=32 time
Reply from 172.16.20.2: bytes=32 time
Ping statistics for 172.16.20.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
اگر پس از انجام مراحل ۱ تا ۴ همچنان نتوانستید با سرور ارتباط برقرار کند، احتمالا با مشکل در ترجمه نام (Name Resolution) مواجه هستید و باید تنظیمات سیستم نام دامنه (DNS) خود را بررسی کنید. اما اگر پینگ به سرور راه دور با شکست روبرو شد، آنگاه می‌دانید که مشکل در شبکه فیزیکی راه دور وجود دارد و باید به سرور مراجعه کرده و مراحل ۱ تا ۳ را تا یافتن مشکل دنبال کنید.
مشکل در ترجمه نام (Name Resolution)
شایان ذکر است که مشکل در ترجمه نام (Name Resolution) زمانی رخ می‌دهد که سیستم شما قادر به تبدیل یک نام دامنه (مانند www.example.com) به آدرس آی‌پی عددی متناظر آن (مانند 192.168.1.1) نباشد. همان‌‌گونه که می‌دانید، آدرس آی‌پی، مقداری عددی است که کامپیوترها برای برقراری ارتباط با یکدیگر در شبکه از آن استفاده می‌کنند. این فرآیند تبدیل ترجمه نام، معمولا توسط سرورهای سیستم نام دامنه (DNS) انجام می‌شود. هنگامی که شما یک آدرس وب یا نام یک سرور شبکه را در مرورگر یا یک برنامه دیگر وارد می‌کنید، کامپیوتر شما ابتدا سعی می‌کند آدرس آی‌پی مربوط به آن نام را از یک سرور DNS به دست آورد. اگر این فرآیند به هر دلیلی با مشکل مواجه شود، کامپیوتر شما نمی‌تواند آدرس آی‌پی صحیح را پیدا کند و در نتیجه نمی‌تواند با سرور مورد نظر ارتباط برقرار کند. این مشکل می‌تواند به دلیل عوامل مختلفی باشد، از جمله تنظیمات نادرست DNS بر روی کامپیوتر، مشکلات مربوط به سرورهای DNS (مانند در دسترس نبودن یا پاسخ ندادن آن‌ها)، مشکلات در اتصال شبکه بین کامپیوتر و سرورهای DNS، یا حتی مشکلات مربوط به فایل‌های پیکربندی DNS محلی در سیستم. در نتیجه، کاربر ممکن است با پیغام‌های خطا مانند “صفحه وب یافت نشد” یا “نمی‌توان به سرور متصل شد” مواجه شود، حتی اگر اتصال اینترنت به ظاهر برقرار باشد. تشخیص و رفع این مشکل معمولا شامل بررسی تنظیمات DNS سیستم عامل و شبکه، اطمینان از درستی آدرس‌های سرور DNS پیکربندی شده، و در صورت لزوم، استفاده از ابزارهایی برای تست و عیبیابی ارتباط با سرورهای DNS است.
بررسی پارامترهای آی‌پی در سیستم‌های عامل از طریق دستورات اختصاصی
پیش از آنکه به بررسی مشکلات مربوط به آدرس آی‌پی و نحوه رفع آن‌ها بپردازیم، می‌خواهم به چند دستور پایه اشاره کنم که می‌توانید از آن‌ها برای عیبیابی شبکه از طریق کامپیوترهای شخصی ویندوزی، دستگاه‌های سیسکو، و همچنین میزبان‌های MAC و لینوکس استفاده کنید. به خاطر داشته باشید که اگرچه این دستورات ممکن است کار یکسانی انجام دهند، اما نحوه پیاده‌سازی آن‌ها متفاوت است.
- ping: از درخواست و پاسخ ICMP echo برای آزمایش اینکه آیا پشته آی‌پی یک گره (دستگاه شبکه) مقداردهی اولیه شده و در شبکه فعال است یا خیر، استفاده می‌کند.
- traceroute: با استفاده از تایم‌آوت‌های TTL و پیام‌های خطای ICMP، فهرستی از روترها در مسیر رسیدن به یک مقصد شبکه را نمایش می‌دهد. این دستور در خط فرمان ویندوز کار نمی‌کند.
- tracert: عملکردی مشابه traceroute دارد، اما یک دستور مخصوص سیستم عامل ویندوز است و روی روترهای سیسکو کار نمی‌کند.
- arp -a: نگاشت‌های آدرس آی‌پی به مک آدرس را در یک کامپیوتر شخصی ویندوزی نمایش می‌دهد.
- show ip arp: عملکردی مشابه arp -a دارد، اما جدول ARP را روی یک روتر سیسکو نمایش می‌دهد. همانند دستورات traceroute و tracert، دستورات arp -a و show ip arp نیز بین ویندوز و سیسکو قابل تعویض نیستند.
- ipconfig /all: این دستور که فقط در خط فرمان ویندوز قابل استفاده است، پیکربندی شبکه را نمایش می‌دهد.
- ifconfig: سیستم‌عامل‌های مک و لینوکس از این دستور برای دریافت جزئیات آدرس آی‌پی دستگاه محلی استفاده می‌کنند.
- ipconfig getifaddr en0: در سیستم‌عامل‌های مک یا لینوکس، اگر به شبکه بی‌سیم متصل هستید، از این دستور برای یافتن آدرس IP خود استفاده کنید. اگر از طریق اترنت متصل هستید، به جای en0 از en1 استفاده کنید.
- curl ifconfig.me: این دستور، آدرس آی‌پی عمومی اینترنت را در ترمینال سیستم‌عامل‌های مک یا لینوکس نمایش می‌دهد.
- curl ipecho.net/plain ; echo: این دستور نیز آدرس آی‌پی عمومی اینترنت را در ترمینال سیستم‌عامل‌های مک یا لینوکس نمایش می‌دهد.
اگر پس از اجرای تمام این مراحل و در صورت لزوم، استفاده از دستورات مناسب، با مشکلی روبرو شویم چه کاری باید انجام دهیم؟ چگونه یک خطای پیکربندی آدرس آی‌پی را برطرف کنیم؟ وقت آن است که به گام بعدی بپردازیم: تشخیص و رفع مشکل موجود!
تشخیص مشکلات آدرس آی‌پی
معمول است که یک میزبان (کامپیوتر)، روتر یا سایر دستگاه‌های شبکه با آدرس آی‌پی، ماسک زیرشبکه یا دروازه پیش‌فرض اشتباه پیکربندی شوند. از آنجایی که این اتفاق خیلی زیاد رخ می‌دهد، باید بدانید چگونه خطاهای پیکربندی آدرس آی‌پی را پیدا کرده و برطرف کنید. یک روش خوب برای شروع، ترسیم طرح شبکه و آدرس‌دهی آی‌پی است. اگر این کار قبلا انجام شده باشد، خوش شانس هستید، زیرا با وجود منطقی بودن، به ندرت انجام می‌شود. حتی اگر انجام شده باشد، معمولا قدیمی یا نادرست است. بنابراین در هر صورت، بهتر است که از ابتدا شروع کنید. پس از اینکه شبکه خود را به طور دقیق، از جمله طرح آدرس‌دهی آی‌پی را ترسیم کردید، برای تعیین مشکل، باید آدرس آی‌پی، ماسک و آدرس دروازه پیش‌فرض هر میزبان را بررسی کنید. البته، این فرض بر این است که شما مشکل لایه فیزیکی ندارید، یا اگر داشتید، قبلا آن را برطرف کرده‌اید. برای درک بهتر موضوع به شکل زیر دقت کنید.
کاربری در بخش فروش تماس می‌گیرد و به شما می‌گوید که نمی‌تواند به سرور A در بخش بازاریابی دسترسی پیدا کند. از او می‌پرسید که آیا می‌تواند به سرور B در بخش بازاریابی دسترسی پیدا کند، اما او نمی‌داند زیرا مجوز ورود به آن سرور را ندارد. اکنون چه کاری باید انجام دهید؟
ابتدا، کاربر را باید از طریق چهار مرحله عیبیابی که در بخش قبلی آموختید راهنمایی کنید. فرض کنید مراحل 1 تا 3 کار می‌کنند اما مرحله 4 با شکست مواجه می‌شود. با نگاهی به شکل، آیا می‌توانید مشکل را تعیین کنید؟ به نشانه‌ها در نقشه شبکه توجه کنید. لینک WAN بین روتر آزمایشگاه A و روتر آزمایشگاه B ماسک /27 را نشان می‌دهد. شما باید از قبل بدانید که این ماسک 255.255.255.224 است و تشخیص دهید که همه شبکه‌ها از این ماسک استفاده می‌کنند. آدرس شبکه 192.168.1.0 است. زیرشبکه‌ها و میزبان‌های معتبر شما کدامند؟
256 – 224 = 32، بنابراین زیرشبکه‌های ما 0، 32، 64، 96، 128 و غیره خواهند بود. بنابراین، با نگاهی به شکل، می‌توانید ببینید که زیرشبکه 32 توسط بخش فروش استفاده می‌شود. لینک WAN از زیرشبکه 96 استفاده می‌کند و بخش بازاریابی از زیرشبکه 64 استفاده می‌کند.
در ادامه، باید مشخص کنید که محدوده آدرس‌های میزبان معتبر برای هر زیرشبکه کدام هستند. با توجه به آنچه قبلا آموخته‌اید، اکنون باید بتوانید به راحتی آدرس زیرشبکه، آدرس‌های پخشی (broadcast) و محدوده‌های آدرس‌های میزبان معتبر را تعیین کنید. برای شبکه محلی (LAN) بخش فروش، آدرس‌های میزبان معتبر از 33 تا 62 هستند و آدرس پخش 63 است، زیرا زیرشبکه بعدی 64 است، درست است؟ برای شبکه محلی بخش بازاریابی، آدرس‌های میزبان معتبر از 65 تا 94 (آدرس پخش 95) و برای لینک WAN، از 97 تا 126 (آدرس پخش 127) هستند. با بررسی دقیق شکل، می‌توانید تشخیص دهید گیت‌وی پیش‌فرض (default gateway) روی روتر آزمایشگاه B نادرست است. آن آدرس، آدرس پخشی برای زیرشبکه 64 است، بنابراین به هیچ وجه نمی‌تواند یک آدرس میزبان معتبر باشد!
نکته: اگر سعی کنید آن آدرس را روی رابط روتر آزمایشگاه B پیکربندی کنید، با خطای ماسک نادرست مواجه خواهید شد. روترهای سیسکو اجازه نمی‌دهند آدرس‌های زیرشبکه و پخشی را به عنوان آدرس‌های میزبان معتبر وارد کنید!
اجازه دهید برای درک بهتر موضوع به مثالی دیگری اشاره داشته باشیم. در شکل زیر، مشکل دیگری را در یک شبکه مشاهده می‌کنیم.
کاربری در شبکه محلی فروش نمی‌تواند به سرورB دسترسی پیدا کند. شما از کاربر می‌خواهید که چهار مرحله عیبیابی اساسی را انجام دهد و متوجه می‌شوید که میزبان می‌تواند با شبکه محلی ارتباط برقرار کند اما با شبکه راه دور نه. اگر همان مراحلی را که برای حل مشکل قبلی استفاده کردید دنبال کنید، مشاهده می‌کنید که ابتدا، لینک WAN دوباره ماسک زیرشبکه مورد استفاده را ارائه می‌دهد: /29 یا 255.255.255.248. با فرض آدرس‌دهی کلاسیک (classful addressing)، برای حل این مشکل باید زیرشبکه‌های معتبر، آدرس‌های پخشی و محدوده‌های آدرس‌های میزبان معتبر را تعیین کنید.
ماسک 248 یک بلوک با اندازه 8 است (256 – 248 = 8)، بنابراین زیرشبکه‌ها هم شروع و هم افزایش‌شان با مضرب‌های 8 انجام می‌شود. با نگاهی به شکل، می‌بینید که شبکه محلی فروش در زیرشبکه 24، شبکه WAN در زیرشبکه 40 و شبکه محلی بازاریابی در زیرشبکه 80 قرار دارند. اکنون می‌توانید مشکل را ببینید؟ محدوده آدرس‌های میزبان معتبر برای شبکه محلی فروش 25 تا 30 است و پیکربندی به نظر درست می‌رسد. محدوده آدرس‌های میزبان معتبر برای لینک WAN در بازه 41 تا 46 است و این نیز درست به نظر می‌رسد. محدوده آدرس‌های میزبان معتبر برای زیرشبکه 80 در بازه 81 تا 86 است، با یک آدرس پخشی 87 است، زیرا زیرشبکه بعدی 88 است. همچنین، سرور B با آدرس پخشی زیرشبکه پیکربندی شده است.
نویسنده: حمیدرضا تائبی
اشتراک‌گذاری
مطالب مشابه
۳ اردیبهشت ۱۴۰۴
۲ اردیبهشت ۱۴۰۴
