مقدمه
درک معنای ارور های مختلفی که ما، به عنوان ادمین‌های سیستم در حین کارهای روزمره خود با آن‌ها مواجه می‌شویم، کلید شناخت سریع و عیب‌یابی مشکلات و دردسرها است. بنابراین، در میان ارور های سیستم‌های distribute شده مدرن، پیام‌های “request timed out” و “destination host unreachable” رایج‌تر اند.
چنین ارور هایی ممکن است روز هر کسی را خراب کند. در واقع، ارور ها نشانه‌ای از طیف متنوعی از مشکلات هستند که قطعاً نیاز به توجه و اقدام فوری دارند.
در این آموزش، کمی به این ارور ها می‌پردازیم و در مورد برخی ابزارها برای کمک به troubleshoot کردن آن‌ها صحبت می‌کنیم.
پروتکل Internet Control Message
پروتکل Internet Control Message (ICMP) برای اولین بار همراه با پروتکل venerable IP (RFC791) طراحی شد و بر روی RFC792 تعریف شده است. که این به سال 1981 باز می‌گردد. هدف این پروتکل ارائه پیام‌های diagnostic و control به شبکه‌های IP است.
مانند هر یک از پروتکل‌های اینترنتی رایج دیگر، به عنوان مثال TCP یا UDP ، این پروتکل هم از طریق IP اجرا می‌شود. صرف نظر از اینکه برخی از عملکردهای اصلی آن در حال حاضر منسوخ شده‌اند، هنوز هم کاملاً مورد استفاده قرار می‌گیرد. بسیاری از پیام‌های control آن برای سیگنال شبکه یا ارور های مشکلات اتصال gateway های آن رخ می‌دهد. پیام‌های control رایج‌تر ICMP مرتبط با این مشکلات عبارت‌اند از:
Destination Host Unreachable
پیام کنترل “Destination Unreachable” شامل زیر کلاس “Destination Host Unreachable”می‌شود. این ارور زمانی اتفاق می‌افتد که میزبان کاربر یا gateway های آن نتوانند مسیری برای رسیدن به مقصد خود پیدا کنند.
بنابراین زمانی که این اتفاق می‌افتد، معمولاً دلیل آن نبود مسیرهای در دسترس و مناسب برای کاربر به مقصد است. باید توجه داشته باشیم که در عین غیرعادی بودن، پیکربندی‌های شبکه و فایروال یا اقدامات administrative ممکن است این پیام را ایجاد کنند.
Request Timeout
از سوی دیگر، “Request Timeout” با ناتوانی نرم افزار client در دریافت پاسخ (مثلاً به یک پیام echo request control) در مدت زمان مشخص مرتبط است. این یک پیام کنترل ICMP واقعی نیست.
این پیام زمانی ایجاد می‌شود که پس از مدتی، عواملی مانند ازدحام در شبکه، از کار افتادن یا پاسخ ندادن میزبان یا از دست دادن packet ها دست به دست هم دهند.
Time Exceeded
در مقابل، یک پیام کنترل ICMP به نام “Time Exceeded” وجود دارد که مربوط به زمان نیست، بلکه مربوط به مسافت است. هر زمان که network stack یک IP packet جدید ایجاد می‌کند، یک “Time to Live field” وارد می‌کند که به نام TTL نیز شناخته می‌شود. مشخصات IPv6 با حفظ عملکرد، باعث تغییر نام این فیلد به “Hop Limit” می‌شود.
در حین حرکت از طریق شبکه، هر بار که packet به hop بعدی می‌رود، مقدار TTL آن یک عدد کمتر می‌شود. به محض اینکه این مقدار به 0 برسد، یک پیام کنترل “Time Exceeded” به میزبان مبدأ packet ارسال می‌شود تا اطلاع دهد که packet مسافت طولانی‌تری را نسبت به TTL آن packet اصلی طی می‌کند.
این رفتار در این تصویر نشان داده شده است. client یک IP packet با یک starting TTL را به سمت سرور مقصد ارسال می‌کند. هر hop در مسیر، TTL را کاهش می‌دهد تا زمانی که به مقصد برسد:
حداکثر TTL ممکن ( یا محدودیت Hop در IPv6 ) 255 است. به این معنی که این بزرگترین فاصله hop مجاز برای یک مکالمه اینترنتی point-to-point است. افزایش این فاصله با پراکسی‌هایی در مسیر امکان‌پذیر است که می‌توانند بسته‌ها را از هم جدا کنند و بسته‌های جدید را جمع‌آوری کنند. حتی اگر این یک رفتار معمولی برای حملاتی در کلاس man-in-the-middle باشد.
Traceroute
می‌توان گفت که پیام کنترل Traceroute اکنون منسوخ شده است. این ممکن است برای مدیرانی که به طور روزانه از دستورات Traceroute یا tracert برای تشخیص مشکلات اتصال به شبکه استفاده می‌کنند، عجیب به نظر برسد.
واقعیت این است که در حال حاضر، عملکرد آن در واقع اضافی است. به هر حال با ارسال درخواست‌های پی‌در‌پی ICMP echo ، TCP SYN یا UDP probe packets و با افزایش تدریجی packet های ارسالی TTL ، از 1 به تعداد hop های مورد نیاز برای رسیدن به هدف.پیاده سازی شده است.
هنگامی که packet نمی‌تواند به مقصد خود برسد، یا TTL به صفر می‌رسد، یک پیام کنترل ICMP ارسال می‌شود. به این ترتیب، نرم افزار سرویس‌گیرنده، IP میزبان‌هایی را که پیام‌های کنترل ICMP مربوطه را ارسال کرده‌اند، ثبت می‌کند.
ابزارهای کمکی برای تشخیص مشکلات اتصال به شبکه
هنگامی که با ارور هایی مانند “request timed out” یا “destination host unreachable” مواجه می‌شویم، اولین کاری که باید انجام دهیم این است که علت اصلی آن را به طور دقیق مشخص کنیم.
هر سیستم عاملی که IP stack را پیاده‌سازی می‌کند، باید مجموعه‌ای از ابزارهای troubleshooting را در اختیار ادمین سیستم قرار دهد. در اینجا ما موارد رایج‌تر را بررسی خواهیم کرد.
Ping
اولین دستور تشخیص شبکه که به ذهنمان می‌رسد، Ping است. این ابزار تقریباً به اندازه خود پروتکل IP قدیمی است. با ارسال‌های درخواست‌های ICMP echo کار می‌کند. سپس زمان مورد نیاز برای دریافت پیام کنترل پاسخ echo را اندازه‌گیری می‌کند.
اگر این اتفاق در یک زمان خاص رخ ندهد، پیام‌های “Request timed out” را صادر می‌کند.
به عنوان مثال، برای بررسی وجود اتصال بین دو میزبان و بررسی تأخیر ارتباط آن‌ها (یکی از خروجی‌های ping زمان round-trip یا RTT است.) و از دست دادن packet ، می‌توانیم از روش زیر استفاده کنیم:ر
# ping -c 10 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=31.8 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=53 time=31.7 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=53 time=31.2 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=53 time=30.2 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=53 time=31.1 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=53 time=79.1 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=53 time=30.6 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=53 time=319 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=53 time=31.5 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=53 time=29.9 ms
--- 1.1.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9015ms
rtt min/avg/max/mdev = 29.904/64.621/319.028/86.009 ms
همان‌طور که می‌بینیم، پارامتر –c برای تعیین تعداد packet های probe استفاده می‌شود. در حین بررسی IP 1.1.1.1 با 10 packet ، می‌توانیم به نرخ از دست دادن packet 0% ، میانگین زمان round-trip 64 میلی‌ثانیه و میانگین انحراف استاندارد 86 میلی‌ثانیه برسیم.
نسخه فعلی دستور ping آپشن‌های زیادی دارد، که ما می‌توانیم همه آن‌ها را با استفاده از دستور ping –h ببینیم.
کاربردهای رایج ping
برای تخمین تأخیر و از دست دادن داده‌ها، گاهی اوقات به تعداد زیادی از packet ها و payload های بزرگتر احتیاج داریم. مانند:
# sudo ping -f -c 579 -s 1460 10.1.1.1
PING 10.1.1.1 (10.1.1.1) 1460(1488) bytes of data.
............
--- 10.1.1.1 ping statistics ---
579 packets transmitted, 567 received, 2.07254% packet loss, time 9249ms
rtt min/avg/max/mdev = 148.030/154.707/408.936/25.042 ms, pipe 14, ipg/ewma 16.000/149.251 ms
این دستور با تنظیم –f (سریعترین packet rate ممکن) و –s (اندازه packet payload )، load های بالاتری تولید می‌کند و گزینه –f فقط محدود به superuser می‌شود. در واقع، ما برای بررسی سیستم افراد دیگر، هرگز نباید از گزینه –f استفاده کنیم. زیرا این کار ترافیک جعلی درنظر گرفته می‌شود و ممکن است یک عامل مخرب تلقی شناخته شود.
در یک یادداشت جانبی، آپشن‌های –f و –s سابقه سوء استفاده توسط حملات DoS (حملات انکار سرویس) را داشته‌اند. مانند حمله Ping of Death ، که با هدف قرار دادن یک باگ packet fragmentation ، می‌توان یک سیستم چندمیلیون دلاری را به سادگی و با تنها یک دستور از بین ببرد:
# ping -s 65535 <host IP>
گرچه امروزه این حملات اهداف آسیب‌پذیر کمی دارند، پیام‌های کنترل ICMP توسط مهاجمان آینده‌نگر، به طور گسترده برای نقشه‌برداری از شبکه‌ها و اهداف بالقوه استفاده می‌شود.
به همین دلیل است که معمولاً برای کنترل اینکه چه پیام‌های کنترل ICMP می‌توانند به عناصر شبکه داخلی ارسال شوند و اینکه آن‌ها چه مقاصدی دارند، از ICMP استفاده می‌شود.
بهترین روش این است که اجازه دهید از ترافیک ICMP ورودی تنها برای تعداد انگشت‌شماری از هاست‌های داخلی نیازمند troubleshooting اساسی استفاده شود و خروجی را فقط به پیام‌های کنترل پاسخ و درخواست ICMP echo محدود کنید.
Traceroute
اگر پیام‌هایی مانند “destination host unreachable” را دیدیم، می‌دانیم که با کشف مسیریابی به آن هاست مشکل داریم. بر این اساس، برای تعیین دقیق محل وقوع، می‌توانیم از دستور traceroute استفاده کنیم.
این دستور hop های بین دو میزبان را ردیابی می‌کند.
ما می‌توانیم پروتکل مورد استفاده برای بررسی (از بین ICMP، UDP یا TCP) و تعداد و زمان‌بندی probe ها را انتخا ب کنیم، به router ها، gateway ها یا interface های مورد استفاده اشاره کنیم و سعی کنیم MTU (واحد انتقال حداکثری، به عنوان مثال بزرگترین payload بدون fragmentation ) را در طول مسیرها و یا با حدس زدن مسیر معکوس از هدف به هاست خودمان probe کنیم.
به عنوان مثال، بیایید مسیر را از هاست خودمان به DNS گوگل ترسیم کنیم:
# traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 10.0.2.1 4.162 ms 3.856 ms 3.705 ms
2 201.88.63.1 9.591 ms 9.481 ms 9.371 ms
3 100.120.69.45 9.265 ms 100.120.69.47 9.155 ms 9.991 ms
4 177.2.210.10 10.101 ms 100.120.22.7 10.107 ms 100.120.22.247 9.663 ms
5 100.120.24.241 33.581 ms 100.120.22.212 27.239 ms 27.133 ms
6 100.120.20.240 30.848 ms 100.120.20.246 28.394 ms 100.120.25.80 23.335 ms
7 * 72.14.198.152 30.368 ms *
8 * * *
9 8.8.8.8 28.958 ms 32.079 ms 31.915 ms
هدف گزینه -n حل نشدن hostname ها است. خروجی فرمان 9 hop را از local machine به DNS گوگل نشان می‌دهد. و نکات بسیار جالبی وجود دارد که باید به آن‌ها توجه کنید.
*
علامت‌های *، probe هایی را نشان می‌دهند که زمان آن‌ها تمام است. یافتن gateway هایی در شبکه که به سادگی به probe های این‌چنینی مانند hop هشتم پاسخ نمی‌دهند، غیر معمول نیست.
در برخی از hop ها، مانند سوم، چهارم، پنجم و ششم، ما پاسخ‌هایی از هاست‌های مختلف داشتیم. به این معنی که چندین مسیر در دسترس بود و probe های ما از gateway های مختلف حرکت کردند.
با اختلاف زمانی بین هر hop ، می‌توانیم آن‌هایی را ببینیم که زمان بیشتری را به زمان round-trip ما اضافه می‌کنند. بنابراین، اگر به طور مداوم اختلاف زمانی inter-hop بیش از 100 میلی‌ثانیه را مشاهده کنیم، احتمالاً مسیرهای بین‌المللی را می‌بینیم. اگر این مقدار بیش از 500 میلی‌ثانیه باشد، این احتمال وجود دارد که packet ها از طریق packet های ماهواره‌ای عبور کنند.
برای یک لیست کامل از تعداد گسترده‌ای از پارامترها، می‌توانیم دستور traceroute –help را صادر کنیم.
نتیجه‌گیری
در این آموزش، به طور خلاصه در مورد ارور های رایج مانند “Destination Host Unreachable” و “Request Timeout” صحبت کردیم. علاوه بر این، درک بهتری از نحوه ارتباط آن‌ها با یکدیگر و برخی ابزارهایی که برای تجزیه و تحلیل آن‌ها استفاده می‌کنیم کسب کردیم.
با این حال، چندین ابزار آنالیز شبکه وجود دارد که می‌تواند درک ما را از مسائل شبکه بالا ببرد.
گاهی لازم است عمیق‌تر شویم. با استفاده از ابزارهایی که می‌توانند آناتومی، هدرها و payload های packet های شبکه را نشان دهند، می‌توانید ترافیک را تحلیل کنید و محتوای آن را مرور کنید. برای این موضوع، می‌توانیم از Tcpdump یا یک تحلیلگر گرافیکی packet مانند Wireshark استفاده کنیم.
در مواقع دیگر، باید اطلاعات بیشتری در مورد خود شبکه و هاست‌های آن جمع‌آوری کنیم. بنابراین، می‌توانیم از Nmap استفاده کنیم. ابزاری که می‌تواند تجزیه و تحلیل بسیار دقیقی از هاست‌های یک شبکه انجام دهد و تشخیص دهد که در میان بسیاری از کاربردهایی دیگر، چه سرویس‌هایی را اجرا می‌کنند.
آخرین، اما نه کم‌اهمیت‌ترین موضوع این است که ما می‌تواینم برای شبیه‌سازی مشکلات شبکه و ارزیابی نحوه عملکرد سیستم‌هایمان در سناریوهای خاص خرابی شبکه، از دستور tc استفاده کنیم.
منبع: baeldung
Leave feedback about this