چگونه مشکلات ارتباطی شبکه را رفع کنیم؟ چگونه مشکل ارتباطات شبکه را پیدا کنیم؟ در این سری آموزشی قصد دارم به شما آموزش تکنیک های مختلف رفع اشکال های ارتباطی در شبکه ، بین کامپیوتر هایی که از سیستم عامل ویندوز استفاده می کنند را توضیح بدهم . در حال حاضر سخت افزار ها و نرم افزارهایی که در شبکه ها استفاده می شود تا حد زیادی قابل اتکا و اعتماد هستند اما گهگاه پیش می آید که همین تجهیزات نرم افزاری و سخت افزاری با مشکلاتی مواجه می شوند. اولین گام در شروع رفع اشکال شبکه یادگیری مفهوم و مکانیزم کاری شبکه است که در دوره آموزش نتورک پلاس یاد داده می شود.
در این سری از آموزشها شما را با روش هایی آشنا می کنم که بتوانید براحتی مشکلات ارتباطی شبکه که در سیستم عامل ویندوز به وجود می آیند . باعث می شود که کامپیوتر موجود نتواند با سایر کامپیوترها به درستی ارتباط برقرار کند را شناسایی و براحتی آنها را رفع کنید . برای دوستانی که به تازگی با پروتکل TCP/IP آشنایی پیدا کردند احترام قائل می شیم و از ابتدای ابتدا موارد رو آموزش خواهیم داد تا به کم کم به مسائل پیشرفته برسیم .
وقتی که یک کامپیوتر نمی تواند با کامپیوترهای دیگر ارتباط برقرار کند اولین مسئله بدست آوردن اطلاعاتی در خصوص مشکل بوجود آمده و شناسایی مشکل است . خوب اگر بخواهیم تخصصی تر صحبت کنیم می بایست تنظیمات انجام شده بر روی کامپیوتر مورد نظر را بررسی و آنها را مستند کنیم ، باید متوجه شویم که آیا این مشکل صرفا همین کامپیوتر را دچار مشکل کرده است یا اینکه بخشی از شبکه یا کامپیوتر های دیگر نیز دچار همین مشکل هستند ؟
-------------------------------------------------
برای دسترسی به مجموعه بهترین دوره های آموزش شبکه های کامپیوتری ( مبانی شبکه ، نتورک پلاس ، مانیتورینگ و ... ) مقدماتی تا پیشرفته با ارائه گواهینامه و فیلم رایگان همین الان کلیک کن
--------------------------------------------------
رفع اشکالات شبکه نیاز به یادگیری شبکه بصورت اصولی و درک کردن نحوه کارکرد تجهیزات ، ارتباطات و ... دارد که شما در دوره آموزش نتورک پلاس مهندس نصیری در این لینک ، می توانید به بهترین شکل به این آموزشها دسترسی داشته باشید.
برای مثال فرض را بر این بگیرید که کامپیو تری نمی تواند با یک سرور خاص در شبکه ارتباط برقرار کند . دانستن همین مسئله شاید کمک زیادی به شما برای رفع ایراد بوجود آمده نکند ، اما در نظر بگیرید که با کمی توجه و بررسی متوجه می شوید که نه تنها این کامپیوتر نمیتواند با سرور مورد نظر ، بلکه با سایر سرور ها و کامپیوترهای شبکه نیز نمی تواند ارتباط بر قرار کند ، همین مسئله می تواند مشخص کند که مشکل اصلی از خود کامپیوتر مورد نظر است و می تواند قطعی کابل ، غیر فعال شدن کارت شبکه ، غیر فعال شدن پورت مورد نظر در سویچ شبکه و یا تنظیمات اشتباه در شبکه باشد .
همچنین اگر دیدید که کامپیوتر می تواند با سرورهای دیگر ارتباط برقرار کند و صرفا با یک یا چند سرور نمی تواند ارتباط برقرار کند ، این خود می تواند یک مسئله جالب در زمینه رفع ایراد شبکه باشد که می بایست دقیقتر بررسی شود . در این موارد معمولا شما باید این مسئله را بررسی کنید که سرورهایی که نمیتوان با آنها ارتباط برقرار کرد از چه تنظیمات مشترکی استفاده کرده اند و اشتراک ها آنها را بیابید . آیا همه آنها در یک subnet در شبکه قرار دارند ؟
اگر اینطور است ممکن است مشکل از مسیریابی باشد . اگر چندین کامپیوتر نمی توانند با یک سرور خاص ارتباط برقرار کنند به احتمال قریب به یقین مشکل از سرور است و نه از کامپیوترها ، مگر اینکه به تازگی بر روی آن کامپیوترها تنظیمات جدیدی انجام شده باشد . در بیش از 90% موارد مشکل اصلی از فعالیت سرور است . هدف از مطرح کردن مشکل بالا این بود که شما می توانید براحتی با انجام چند تست ساده اطلاعات بسیار خوبی در زمینه مشکل بوجود آمده در شبکه بدست بیاورید . تست هایی که در جلوتر به آموزش آنها خواهم پرداخت به ندرت به شما دلیل بوجود آمدن مشکل را نمایش می‌دهند ، اما به شما کمک خواهند کرد که محدوده مشکل بوجود آمده را آنقدر کوچک کنید که به مشکل اصلی رسیده و بتوانید آنرا حل کنید .
دستور PING ساده ترین و راحت ترین دستور تشخیص مشکل مربوط به پروتکل TCP/IP است که تا کنون ساخته شده است . اطلاعاتی که از این دستور می‌توان بدست آورد واقعا گرانبهاست و می توان آنرا بهترین ابزار رفع ایراد شبکه نامگذاری کرد .
در ساده ترین حالت ممکن با تایپ کردن دستور PING و آدرس مقصد میتوانید بفهمید که کامپیوتر می‌تواند با وسایل دیگر در شبکه ارتباط برقرار کند یا خیر .اولین چیزی که به شما در هنگام رفع ایراد شبکه توصیه میکنم این است که یک command prompt باز کرده و دستور Ping را به همراه آدرس IP مقصد که در واقع همان کامپیوتری خواهد بود که در برقراری ارتباط با آن مشکل دارید در آن وارد کرده و enter را بزنید . پس از اینکه اینکار را کردید کامپیوتر مقصد می بایست با چهار پاسخ یا Reply مانند شکل زیر به شما جواب دهد .
شکل الف : ماشین مورد نظر می بایست با چهار پاسخ یا Reply به شما جواب دهد
پاسخی که از این کامپیوتر دریافت می‌کنید در حقیقت به شما می‌گوید که چه مقدار زمان طول می‌کشد که 30 بایت اطلاعات که از کامپیوتر شما به آن کامپیوتر ارسال شده و ماشین مقصد به آنها پاسخ داده است . برای مثال در شکل الف شما دیدید که زمانی که این 30 بایت اطلاعات ارسال و دریافت شد کمتر از 4 میلی ثانیه بود . وقتی شما دستور Ping را وارد می‌کنید چهار حالت ممکن است پیش بیاید که هر کدام مفهوم خاص خود را دارند :
حالت اول : ماشین مقصد پاسخ را با چهار Reply ارجاع می‌دهد بدین معنا که ارتباط با استفاده از پروتکل TCP/IP به درستی برقرار است.
حالت دوم : ماشین مقصد همانند شکل ب پاسخ را با چهار request time out می‌دهد ، اگر به شکل الف دقت کرده باشید می‌بینید که هر پاسخ یا Reply با یک TTL=128 به پایان می‌رسد. . TTL مخفف کلمه Time To Live می‌باشد. این به این معناست که هر کدام از چهارquery فرستاده و دریافت شده توسط دستور Ping می‌بایست ظرف مدت حداکثر 128 میلی ثانیه پاسخ داده شوند . عدد TTLدر هنگام بازگشت از مقصد و پس از عبور از هر Hop یکی کم می شود . یک Hop زمانی میشود که یک بسته از یک شبکه به شبکه ای دیگر منتقل میشود . در مورد Hop در همین سری از مقالات مفصل صحبت خواهم کرد .
شکل ب : اگر هر چهار پاسخ بصورت request timed out بازگردد حتما مشکل ارتباطی وجود دارد .
فرقی نمی‌کند که سرعت شبکه شما چقدر است ،در صورتیکه هر چهار پاسخ بصورت Timed Out داده شود به این معناست که TTL قبل از رسیدن به مقصد و دریافت پاسخ منقضی ( Expire ) شده است . در این مواقع سه حالت وجود دارد :
حالت سوم : در این حالت بعضی از بسته ها دریافت و برخی نیز دریافت نمی‌شوند مثلا دو تا Reply from دریافت کرده و دو تا هم Request time out و این به این معناست که یا کابل کشی مشکل دارد ، سخت افزار مشکل دارد و یا ترافیک بسیاری در شبکه وجود دارد .
حالت چهارم : در این حالت شما بعد از وارد کردن دستور Ping پیغام خطایی مانند شکل ج دریافت می‌کنید .
شکل ج : این نوع خطا به معنی این است که تنظیمات TCP/IP درست انجام نشده است .
خطای PING: transmit failed به معنای این است که تنطیمات TCPIP کامپیوتری که از روی آن دستور ping را وارد کرده اید درست انجام نشده است . اشکالی که الان در تصویر مشاهده می‌کنید ویژه سیستم عامل های ویندوز سون و ویستا هست و در سیستم عامل های قدیمی تر مانند ویندوز XP ، در صورتیکه تنظیمات TCPIP به درستی انجام نشده باشد خطای Destination Host Unreachable دریافت خواهید کرد .
بهترین دوره برای رفع اشکال شبکه های مایکروسافت ، دوره آموزش MCSA مایکروسافت است.
چه باور کنید و چه باور نکنید ، این غیر معمول نیست که دستور Ping با موفقیت کار خود را انجام دهد و هیچ پیام خطایی نیز مشاهده نشود ، حتی در مورد دو کامپیوتر در شبکه که در برقراری ارتباط مشکل دارند نیز می تواند به همین شکل باشد . اگر این اتفاق افتاد پس مطمئن باشید که زیرساختار های شبکه به درستی کار خود را انجام می‌دهند و حداقل الان میدانیم که شبکه در لایه TCP/IP مشکلی ارتباطی ندارد . البته این خبر خوبی است که Ping جواب می دهد ، این پاسخ نشان دهنده این است که شبکه مشکل چندان جدی ندارد .
اگر ارتباطات معمول بین شبکه ای بین دو کامپیوتر دچار مشکل شده است اما این دو همدیگر را ping می کنند ( مطمئن شوید که از هر دو کامپیوتر یکدیگر را Ping می کنید ) ، شما باید چیزهای دیگری را تست کنید . در این حالت به جای اینکه با آدرس IP کامپیوتر مقصد را Ping کنید سعی کنید با FQDN سیستم مقابل یا همان نام DNS سیستم مقابل را Ping کنید ، مانند شکل د .
شکل د : سعی کنید با استفاده از Fully Qualified Domain Name یا همان FQDN مقصد را Ping کنید .
اگر با آدرس IP میتوانید مقصد را Ping کنید اما با نام کامپیو تر نمی‌توانید اینکار را انجام دهید به احتمال بسیار زیاد شما مشکل DNS دارید . ممکن است سیستم مورد نظر از آدرس DNS ُ سرور اشتباهی استفاده کرده باشد و یا اینکه DNSسرور مورد نظر رکورد مناسبی برای ماشین مقصد در خود موجود ندارد و به زبان فنی تر در DNS ُ سرور A رکورد ماشین مورد نظر ایجاد نشده است .
اگر به شکل د نگاه کنید خواهید دید که در کنار نام FQDN کامپیوتر مقصد آدرس IP آن نیز وجود دارد ، این به این معنا است که کامپیوتر توانسته است نام DNS ای کامپیوتر مقصد را به درستی دریافت کند . در اینجا به آدرس IP توجه کنید که مربوط به همان کامپیوتری باشد که شما قصد متصل شدن به آنرا دارید ، ممکن است IP این کامپیتور عوض شده باشد . اگر دیدید که آدرس IP بازگشت داده شده توسط DNS سرور با آدرس مورد نظر شما متفاوت است ، بدانید که در DNS سرور رکورد اشتباهی اضافه شده است که باعث این عمل شده است.
در این مقاله از مجموعه مقالات رفع ایرادهای ارتباطی شبکه های ویندوزی و پیرو مقاله قبلی به ادامه رفع مشکلات ارتباطی بین شبکه های ویندوزی خواهم پرداخت ، در اینجا قصد دارم شما را با رفع مشکلات ناشی از تنظیمات نادرست کارت شبکه و تنظیمات IP ماشین برای پیدا کردن دلیل اصلی مشکل بپردازم .
در قسمت قبلی شما را با نحوه استفاده از دستور Ping و برخی از تست های ساده ارتباطی شبکه آشنا کردیم و همچنین در مورد تجزیه و تحلیل نتایج بدست آمده از این دستور نیز صحبت کردیم . در این مقاله قصد دارم شما را با یک سری دیگر از تست های ساده شبکه برای تحلیل وضعیت فعلی ارتباطی شبکه آشنا کنم .
در مقاله قبلی شما یاد گرفتید که چگونه از دستور Ping برای انجام تست های ساده ارتباطی شبکه استفاده کنید . اما اگر همچنان در برقراری ارتباط بین ماشین‌های شبکه و یا شبکه های دور مشکل دارید ، جند روش و نکته دیگر در مورد دستور Ping وجود دارد که شما را در بدست آوردن نتایج بهتر یاری میکند . قبل از اینکه به شما این روش ها را آموزش بدهم ، بسیار مهم است که شما بدانید که تنظیمات شبکه ماشینی که در برقراری ارتباط با شبکه دچار مشکل است چگونه انجام شده است .
دستورالعمل انجام اینکار در نسخه های مختلف ویندوز متفاوت هستند اما من در اینجا برای درک بهتر مسائل از ویندوز سرور 2003 به عنوان ماشین نمونه استفاده میکنم .اولین نکته ای که در مورد تمظیات شبکه می بایست مورد بررسی قرار بگیرد این است که آیا ماشین مورد نظر آدرس IP خود را بصورت دستی دریافت کرده است
و یا اینکه بصورت اتوماتیک اینکار انجام می شود . برای انجام اینکار کافیست به control Panel رفته و به قسمت Network Connection رفته و بر روی Connection مورد نظر خود راست کلیک کرده و گزینه Properties را انتخاب کنید . در این حالت شما تنظیمات کارت شبکه خود را مشاهده خواهید کرد ، مانند شکل الف .
شکل الف : مشخصات و تنظیمات انجام شده بر روی کارت شبکه مورد نظر
خوب در همین قسمت اسکرول را پایین بیاورید تا بتوانید قسمت را با عنوان Internet Protocol ( TCP/IP) را مشاهده کنید ، در سایر نسخه های ویندوز که از IP نسخه 6 پشتیبانی می‌کنند ممکن است شما با نام نسخه مورد نظر نیز این گزینه را مشاهده کنید . این گزینه را انتخاب کنید و بر روی Properties کلیک کنید که تنظیمات مربوطه باز شود ، همانند شکل ب .
شکل ب : تنظیمات مربوطه به Internet Protocol Version 4 ( TCP/IP)
وقتی به این صفحه رسیدید می بایست مهم است که یک سری از تنظیمات مربوط به IP را چک کنید ، خصوصا موارد زیر را چک کنید :
قبل از اینکه شروع به کار کنیم در نظر داشته باشید که اگر کامپیوتری دارای چند کارت شبکه باشد در تنظیمات شبکه ای موجود در Control Panel نیز شما چند کارت شبکه مشاهده خواهید کرد . این بسیار مهم است که بدانید کدام کارت شبکه به کدام شبکه متصل شده است در غیر اینصورت هر کاری که شما انجام بدهید بی اثر خواهد بود .اگر مطمئن نیستید که کدام کارت شبکه به کدام شبکه متصل است میتوانید در بالای شکل الف قسمت Adapter Type را مشاهده کنید و با توجه به آن تعیین کنید که کارت شبکه به کدام شبکه متصل شده است .
اگر در این مورد نیز شک دارید بهتر است که به قیمت Network Connections بروید و بعد از آن کابل شبکه را جدا کنید ، هر کدام از Connection ها که علامت ضربدر قرمز رنگ بر روی آن مشاهده شد به شبکه درست متصل شده است .خوب شما بصورت دستی مشاهده کردید که تنظیمات آدرسی دهی شبکه به چه شکل است اما این تنظیمات ممکن است آن طوری نباشد که به نظر می‌رسد و می بایست توسط خود سیستم نیز تست شود ، برای اینکار اول یک پنجره Command Prompt را باز کنید و دستور زیر را وارد کنید :
IPCONFIG /ALL
ممکن است برای یک نفر تشخیص اینکه تنطیمات مربوط به شبکه یک کارت شبکه درست است یا نه سخت باشد اما با استفاده از دستور IPCONFIG شما واقعا متوجه می‌شوید که چه تنظیماتی بر روی Connection شما انجام شده است . برای مثال به تصویری که در شکل ج وجود دارد نگاه کنید . وقتی شما دستور IPCONFIg /ALL را وارد می‌کنید اولین کاری که بکنید این است که کارت شبکه درست را پیدا کنید . در این حالت تشخیص کارت شبکه مورد نظر کار ساده ای است چون فقط یک کارت و Connection شبکه داریم .
در نظر داشته باشید که دستور IPCONFIG به شما شماره مربوط به Conection را نمایش می دهد ( در اینجا Local Area Connection 2 نمایش داده شده است ) . اگر به شکل الف را مجددا نگاه کنید ،مشاهده خواهید کرد که در قسمت Properties مربوطه همین اسم نمایش داده شده است . با استفاده از همین مسئله و همچنین چک کردن فیزیکی کارت شبکه شما براحتی می توانید متوجه شوید که با کدام کارت شبکه کار می کنید .
شکل ج : دستور IPCONFIG /all کلیه تنظیمات مربوط به کارت شبکه را بصورت کامل به شما نشان می دهد .
حتما اولین چیزی که در مورد شکل ج به ذهن شما می رسد این است که نتیجه دستور چندین آدرس IP مختلف را برای یک Connection نشان می دهد . نتیجه ای که از دستور می بینید در حقیقت حاصل اجرای دستور بر روی یک وب سرور بوده است ، من اینکار را بر روی یک وب سرور انجام دادم و به دلیل اینکه این وب سرور چندین آدرس IP مختلف و همچنین چندین وب سایت محتلف را میزبانی می کند نتیجه به شکل بالا در آمده است .
اینکار را برای این انجام دادم که شما متوجه باشید که ممکن است بر روی یک Connection چندین آدرس IP وجود داشته باشد و صرفا با نگاه کردن به کارت شبکه و گرفتن Properties در محیط گرافیکی ممکن است نتیجه درست را دریافت نکنید . TCP//IPبه یاد داشته باشید که همیشه آن چیزی نیست که شما می بینید . در این حالت فعلی تنظیمات IP که در شکل ب مشاهده کردید همچنان پابرجاست . در شکل ب شما آدرس اصلی کارت شبکه را مشاهده کردید و این در حالی است که سرور ممکن است چندین آدرس IP داشته باشد .
قد بعدی در رفع ایراد شبکه این است که بدانید Connection در تنظیمات IP خود از آدرس IP ثابت استفاده می کند یا بصورت اتوماتیک IP دریافت می کند . اگر ماشین از آدرس ثبت استفاده می کند اولین چیزی که می بایست چک کنید این است که آدرس IP ، Subnet Mask ، Default Gateway و آدرس DNS سرور را چک کنید که با اطلاعاتی که در Properties مربوط به تنظمیات TCP/IP مشاهده شده است یکی باشد .
اگر ماشین از سیستم آدرس دهی اتومایک استفاده می کند اولین چیزی که می بایست چک شود این است که آیا آدرس IP که الان بر روی سیستم قرار گرفته است با رنج آدرسی که توسط سرویس DHCP که بصورت اتوماتیک ارائه می شود یکسان است یا خیر ؟
اگر شما در شبکه ای مشغول رفع ایراد هستید که با این رنج IP آشنایی ندارید ، حتما باید پیگیر باشید که این رنج آدرس را بیابید . در این حالت چنیدن وضعیت آدرس را ممکن است مشاهده کنید که هرکدام برای خود معنا و مفهوم خاصی دارد .اولین گزینه مشهودی که ممکن است در مورد مشکلات مربوط به IP پیش بیاید ، دریافت شدن آدرس IP به شماره 0.0.0.0 است ، معمولا این حالت می تواند سه نتیجه را در بر داشته باشد :
اگر این آدرس ( 0.0.0.0 ) را دریافت کردید ، حتما از این دستورات استفاده کنید :
IPCONFIG /RELEASE IPCOFIG /RENEW ICONFIG /ALL
این دستورات به سیستم می گوید که اولا کلیه تنظیمات آدرسی که در حال حاضر بر روی سیستم وجود دارند را بی خیال شوند و بعد از آن درخواست آدرس جدید را در شبکه ارائه داده و در نهایت هم تنظیمات جدید شبکه را به ما نشان دهد . در بیشتر اوقات همین دستورات مشکل ما را رفع می کند اما بعضی اوقات هم حل نمی کند اما ما را به رسیدن و شناسایی مشکل اصلی راهنمایی می کند .یکی دیگر از مواردی که ممکن است بسیار با آن برخورد داشته باشید این است که Connection شما آدرس IP در یافت می کند در حالتی که تنظیمات برای دریافت آدرس اتوماتیک انجام شده است .
بعد از اینکه به تنظمیات نگاه کنید متوجه خواهید شد که Connection آدرس IP در محدوده 169.254.x.x و Subnet Mask به شماره 255.255.x.x دریافت کرده است ، به محض اینکه با چنین موردی مواجه شدید بدانید که این بدین معنای است که ماشین مورد نظر نتوانسته است از طریق DHCP سرور آدرس دریافت کند و از این رنج IP که به آن APIPA می باشد استفاده کرده است ، در این حالت نیز می توانید از سه دستور قبلی جهت برطرف کرد مشکل استفاده کنید.
در این مقاله و در ادامه مباحث به شما آموزش می دهم که بتوانید از صحت تنظیمات انجام شده بر روی کارت شبکه خود و پرتکل TCPIP اطمینان حاصل کنید . در مقاله قبلی از همین سری مقالات به شما آموزش دادیم که چگونه می توانید بفهمید که آدرس IP های موجود بر روی کارت شبکه شما چیست و همچنین آدرس IP اصلی کارت شبکه شما چیست . قدم بعدی این است که مطمئن شوید که آدرس دهی در پروتکل TCPIP چگونه انجام شده است و از صحت آن اطمینان حاصل کنید .
اولین قدم که شما باید بردارید این اس که local-host را Ping کنید ، چندین راه برای اینکار وجود دارد که راحتترین آن وارد کردن دستور زیر در Command Prompt است :
Ping localhost
وقتی این اسم را Ping می کنید ویندوز آدرس IP به شماره 127.0.0.1 را Ping خواهد کرد . فارق از اینکه چه آدرس IP بر روی کارت شبکه شما تنظیم شده است به محض وارد کردن دستور بالا آدرس 127.0.0.1 Ping خواهد شد . بنابراین وارد کردن دستور بالا مترادف دستور پایین است :
Ping 127.0.0.1
بعد از اینکه دستور بالا را وارد کردید ، باید چهار پاسخ درست مانند تصویر الف دریافت کنید .
شکل الف : شما با ping کردن آدرس Local host خود می توانید صحت تنظیمات TCP/IP کارت شبکه خود را چک کنید .
Ping کردن آدرس IP مربوطه به Local Host هیچ مشکلی را در برقراری ارتباط با یک کامپیوتر دیگر در شبکه حل نخواهد کرد. این دستور صرفا به شما می گوید که تنظیمات کارت شبکه و TCPIP مربوطه به کامپیوتر شما به درستی کار می کند یا خیر.
در صورتیکه آدرس IP مربوط به کامپیوتر خود را Ping کردید و خطای destination host unreachable را دریافت کردید ، مطمئن باشید که تنظیمات TCPIP مربوط به کارت شبکه خود را به درستی انجام نداده اید و با اینکه کارت شبکه دچار مشکل فیزیکی است و خراب شده است . تجربه به من ثابت کرده است که معمولا در چنین مواقعی تیک مربوط به TCP /IP را برداشته و یا این امکان را Uninstall کنید و مجددا تیک را زده و سرویس را نصب کنید ، در 90 درصد مواقع این راهکار مشکل شما را برطرف می کند .
در قسمت قبلی و در ادامه مطالب مربوط به رفع اشکال ارتباطات شبکه ، به شما توصیه کردم که تمامی تنظیمات مربوط به شبکه و کارت شبکه خود را مستند کنید ، در همین راستا شما می بایست تنظیمات و آدرس DNS Server و همچنین آدرس Default Gateway را نیز تست و مستند کنید .اگر فرض را بر این بگیریم که دستگاهی که قرار است با آن ارتباط برقرار کنید در شبکه راه دور است و یا اینکه در یک Segment جداگانه ای در شبکه قرار گرفته است و شما برای برقراری ارتباط با آن می بایست از یک روتر عبور کنید .
دومین قدم بعد از تست تنظیمات Local Host ، چک کردن ارتباط با روتر یا همان Default Gateway با دستور Ping است . شما براحتی با افزودن آدرس IP مربوط به Default Gateway در مقابل دستور Ping می توانید براحتی اینکار را انجام دهید . برای مثال اگر به شکل ب نگاه کنید خواهید دید که تنظیمات TCP/IP من به من می گوید که آدرس مربوط به Default Gateway آدرس 147.100.100.100 است .
من هم براحتی همین آدرس را Ping می کنم . اگر درست جواب داد معلوم می شود که کامپیوتر من می تواند با Default Gateway به درستی ارتباط برقرار کند . همچنین این دستور به شما می گوید که ارتباطات بین شبکه نیز تا حدی درست کار می کند ، حداقل در سطح این مورد درست کار کرده است .
شکل ب : Ping کردن آدرس مربوط به Default Gateway به ما می گوید که بسته های اطلاعاتی ما براحتی می توانند به روتر منتقل شوند و با آن ارتباط برقرار کنند .
در پاراگراف بالا به این نکته اشاره کردیم که ارتباطات در سطح شبکه بین کامپیوتر من و Default Gateway مشکل خاصی ندارد . اما این تضمینی نیست که شما بتوانید نامها را به آدرس IP تبدیل کنید و معلوم نیست که سرویس DNS شما به درستی کار میکند یا نه .
در حال حاضر شما مطمئن نیستید که آیا نامها به آدرس های IP به درستی تبدیل می شوند یا خیر . در قسمت اول از این سری مقالات به شما آموزش دادم که چگونه ارتباط و نحوه کار و تست DNS را با استفاده از همین دستور Ping آزمایش کنید و مطمئن شوید که DNS سرور به درستی کار می کند .
اما چندین روش دیگر نیز در همین رابطه وجود دارد که شما می توانید براحتی فرآیند Name Resolution را آزمایش کنید . یکی از این روش ها این است که همانند شکل ج آدرس IP مربوط به DNS سرور را Ping کنید . این به شما تضمین نمیدهد که فرآیند Name Resolution به درستی انجام می شود اما به شما آموزش می دهد که مطمئن شوید که ارتباط شما در سطح IP و شبکه به درستی برقرار می شود .
شکل ج : شما باید مطمئن شوید که کامپیوتر شما می تواند در سطح شبکه و پروتکل IP با DNS سرور ارتباط برقرار کند.
مرحله بعدی آزمایش ، استفاده از دستور NSLookup است . این دستور برای بررسی صحت عملکرد فرآیند Name Resolution استفاده می شود . در اینجا براحتی شما می توانید با وارد کردن دستور NSLookup و نام FQDN آدرس مقصد صحت این فرآیند را تست کنید . شکل د به شما نشان می دهد که نتیجه وارد کردن دستور NSlookup و آدرس مقصد که به درستی ارتباط برقرار کرده اند چگونه است.
شکل د : دستور NSLookup به شما می گوید که آیا DNS سرور شما فرآیند تبدیل نام با آدرس IP را به درستی انجام می دهد یا خیر.
اگر تاکنون از دستور NSLookup استفاده نکرده اید ممکن است در شکل د کمی ابهام برای شما پیش بیاید و گمان کنید که نتیجه دستور دارای اشکال است . اما اگر کمی دقت کنید می بینید که اولین قسمتی که در نتیجه دستور NSLookup نمایش داده شده است مربوطه به DNS سرور شبکه داخلی است .
شما به این دلیل از این بابت مطمئن هستید برای اینکه در نتیجه دستور آدرس DNS سرور شبکه داخلی خود را مشاهده می کنید . بهرحال در ادامه نتیجه بعدی دستور شما آدرس IP و نام سروری را که در جلوی دستور NSlookup وارد کرده اید را مشاهده می کنید . همیشه در نظر داشته باشید که به محض اینکه مشاهده کردید این آدرس نمایش داده شده است Query که توسط دستور شما انجام شده است به درستی انجام شده است و نتیجه کار بدون اشکال است .
اگر فرآیند Name Resolution یا تبدیل اسم با IP دچار مشکل شد حتما DNS سرور دچار مشکل است . اما نوع مشکل ممکن است خیلی گسترده باشد به حدی که تمامی مشکلاتی که مربوط به DNS می شود ممکن است در این مورد صادق باشد .
برای مثال ممکن است که سرور DNS ارتباط با اینترنت نداشته باشد یا اینکه قسمت Forwarders درست کار نمی کند و طبیعتا DNS سرور نمی تواند به درستی با سرور های اینترنتی میزبان دامنه های اینترنتی ارتباط برقرار کند ، ممکن است سرویس DNS متوقف شده باشد !!! و چندین و چند مشکل دیگر . معمولا همین مشکل برای بسیاری از Client های شبکه بوجود می آید چون همگی آنها از یک آدرس DNS سرور مشترک استفاده می کنند .
اگر فرآیند تبدیل نام و عملیات بالا به درستی انجام شده حتما با آدرس IP که توسط دستور برای هدفی که در نظر گرفته بودید را بررسی کنید که آدرس درست باشد . شما می توانید اینکار را براحتی با مقایسه بین آدرس IP بدست آمده و آدرس IP واقعی سرور هدف مشخص کنید .
این دو آدرس بایستی مشابه یاشد ، در مواقعی پیش می آید که ممکن است این دو آدرس IP با هم همخوانی نداشته باشند که منجر به مشکلات ارتباطی در شبکه خواهد شد .اگر دیدید که این دو آدرس با همدیگر متفاوت هستند چند احتمال وجود دارد .
احتمال اول هجوم بدافزارها به کامپیوتر Client و آلوده کردن آن است و احتمال دوم این است که از طریق یک حمله هکری از نوع DNS Poisoning سیستم آلوده شده باشد ، در این نوع حمله هکر کش DNS سیستم مقصد خود را آلوده کرده بطوریکه درخواستهای کاربر به جای آدرس مقصد به آدرس مورد نظر هکر هدایت می شود .
اگر با اینگونه مشکلات مواجه شدید ابتدا از نرم افزار آنتی ویروس یا ضد بدافزار خود سیستم استفاده کرده و آنرا اسکن کنید ، سعی کنید از نر مافزارهای آنتی ایکس استفاده کنید که توانایی شناسایی تعداد بیشتری از انواع ویروس ها و بد افزارهای را دارند . اگر این راهکار باعث رفع مشکل نشد از دستور زیر برای خالی کردن کش DNS کامپیوتر مورد نظر استفاده کنید :
IPCONFIG /FLUSHDNS
شما نمونه ای از این دستور را در شکل ح مشاهده می کنید . همیشه به یاد داشته باشید که در صورتیکه آدرس کش DNS به آدرسی متفاوت از آدرس اصلی سرور مورد نظر اشاره کرد ، لزوما دلیلی بر این نیست که حمله هکری به آن کامپیوتر انجا شده است و DNS Cache Poisoning انجام شده است . برخی اوقات کامپیوتر مورد نظر آدرس IP جدیدی دریافت می کند که باعث می شود کش DNS تحت تاثیر آن قرار بگیرد .
شکل ح : در صورتیکه حدس می زنید کش DNS دچار مشکل شده است با استفاده از دستور فوق آنرا خالی کنید.
نتیجه :در این مقاله به شما آموزش دادیم که چگونه تنظیمات مربوط به TCP/IPپروتکل استک خود سیستم را بررسی کنید و مطمئن شوید که دارای اشکال نیست . بعد از آن به شما یاد گرفتید که چگونه صحت ارتباط بین DNS سرور و Default Gateway و همچنین سیستم کامپیوتر مورد نظر را آزمایش کنید و مشکلات مربوط به DNS Name Resolution را بررسی کنید . در قسمت بعدی شما را با مشکلات معمول دیگری نیز آشنا خواهم کرد که براحتی با استفاده از همین دستور Ping قابل بررسی و اشکال زدایی هستند ، همچنین شما را با برخی از مشکلات مربوط به مسیریابی نیز آشنا می کنیم.
در ادامه سری مقالات رفع ایرادهای شبکه مربوط به سیستم عامل های شرکت مایکروسافت در مورد اشکالات مربوط به ز بین رفتن بسته های اطلاعاتی در شبکه یا Packet Loss صحبت خواهیم کرد و به شما آموزش می دهیم که چگونه مسیری که یک بسته اطلاعاتی در شبکه طی می کند که به مقصد مورد نظر برسد را بررسی و تحلیل کنید . در چند مقاله قبلی از همین سری آموزش رفع اشکال شبکه در مورد استفاده هایی که می توان از دستور Ping برای پیدا کردن اشکال و رفع آن در شبکه کرد صحبت کردیم . در این مقاله می خواهم به شما بعضی از روشها و تکنیکهای جالبتر را برای رفع اشکال آموزش بدهم .
در مقاله قبلی در مورد دستور Ping صحبت کردیم و شرایط مختلفی که در آن دستور به درستی کار می کند و نتایج موفقیت آمیز دارد و همچنین شرایطی که دستور نتایج موفقیت آمیزی را نشان نمی دهد را بررسی کردیم . در نتیج قبلی دیدیم که هر چهار بازگشت یا Reply که توسط آدرس مقصد ارسال می شود موفقیت آمیز بود اما در برخی اوقات پیش می آید که یکی یا چندین بازگشت یا Reply به درستی بازگشت نداشته و پیام Request Time Out دریافت می کنید .
در اینگونه موارد ما در شبکه باصطلاح از بین رفتن بسته های اطلاعاتی یا Packet Loss داریم .در اینگونه موارد کامپیوتر مبدا و کامپیوتر مقصد هر دو به درستی در شبکه فعالیت می کنند اما در این میان یا بهتر بگوییم در مسیر ارتباطی بین ایندو مشکلاتی وجود دارد که باعث می شود بسته های به درستی به مقصد نرسند.
پروتکل TCP/IP به گونه ای طراحی شده است که در صورتیکه بسته اطلاعاتی در شبکه دچار مشکل شده و به مقصد نرسد و یا نتواند از مقصد تاییدیه دریافت بسته را دریافت کند ، مجددا تلاش در ارسال و دریافت بسته خواهد کرد اما همیشه یادتان باشد که از بین رفتن بسته های اطلاعاتی در شبکه یا Packet Loss قاتل کارایی در شبکه است. نکته جالب اینجاست که اگر یک لینک کند شبکه داشته باشید که بدون Packet Loss فعالیت می کند خیلی خیلی بهتر از لینک شبکه سریعی است که دارای Packet Loss است .
نکته بسیار جالب و البته بسیار مشکل آفرین در خصوص Packet Loss این است که بسیار بسیار ممکن است شناسایی مکان بروز چنین مشکلی دشوار باشد . بله ، شما وقتی که بسته ارسالی پروتکل ICMP که توسط دستور Ping مورد استفاده قرار می گیرد دچار مشکل شود براحتی متوجه می شوید که Packet Loss رد شبکه وجود دارد ، اما بسته اطلاعاتی ICMP بسیار سبک است و براحتی از شبکه های مختلف گذر کرده و بودن مشکل ممکن است پاسخ دهد !!
اما ممکن است Packet Loss برای پروتکل های دیگری به غیر از ICMP در محیط واقعی بوجود بیایند که واقعا پیگیر یو شناسایی مشکل در اینگونه موارد دشوار است زیرا پاسخی که دستور Ping ارائه می دهد نشان می دهد که شبکه Packet Loss ندارد اما در حقیقت وجود دارد !!!
اگر احساس می کنید که در لینک های ارتباطی خود Packet Loss دارید اما پاسخ های دستور Ping چنین چیزی را نشان نمی دهد ، شما می توانید با بزرگتر کردن اندازه بسته های ICMP در دستور Ping دقیقا این مسئله را چک کنید . بسته های اطلاعاتی با حجم بالاتر نسبت به بسته های اطلاعاتی با اندازی کوچکتر بسیار مستعد تر برای از بین رفتن در لینک های ارتباطی مشکل ساز در شبکه هستند . اگر می خواهید از دستور Ping با حجم بسته اطلاعاتی بزرگتری استفاده کنید بایستی از سویچ –L استفاده کنید.
بکار بردن این سویچ در دستور Ping بسیار ساده است بطوریکه شما براحتی میتوانید بعد از نوشتن دستور Ping و آدرس مقصد ، سویچ –L را نوشته و بعد از آن سایز بسته اطلاعاتی ICMP را بر حسب بایت وارد کنید . برای مثال فرض را بر این بگیرید که شبکه شما در برقراری ارتباط با یک سرور دچار مشکل است
شما برای تست این موضوع از دستور Ping استفاده می کنید اما پاسخی که دریافت می کنید نشان می دهد که ارتباط مشکلی ندارد و به نظر دستور با موفقیت پاسخ داده است . بنابراین شما به دستور Ping می گویید که بسته اطلاعاتی ICMP خود را با حجم 1024 بایت به مقصد ارسال کند و بازگشت را آزمایش کند . برای اینکار شما دستور ping را بایستی ب شکل زیر وارد کنید :
Ping 192.168.1.1 –l 1024
در شکل الف یک مثال واقعی در همین مورد و چگونگی کارکرد دستور Ping با اضافه شدن حجم بسته ICMP را مشاهده می کنید.
شکل الف : اضافه کردن سویچ L- به ادامه دستور Ping برای اضافه کردن اندازه بسته ICMP ارسالی .
مبحث بعدی که می خواهیم در مورد آن صحبت کنیم و ارتباط نزدیکی نیز با دستور Ping دارد مبحث TTL یا Time To Live است . اگر به شکل الف خوب نگاه کنید متوجه خواهید شد که هر بسته پاسخ دریافتی از طریق دستور Ping با جوابی مثل TTL=64 پاسخ داده شده است .همانطوری که میدانید اینترنت ترکیبی از هزازان هزان مسیریاب است که به همدیگر متصل شده اند .هر مسیریاب بطور متوسط به دو مسیریاب دیگر متصل شده است .
تفکری که در پس این ساختار است این است که در صورتیکه یکی از لینک های ارتباطی قطع شد قادر باشیم از لینک ارتباطی دیگر برای رسیدن به مقصد مورد نظر استفاده کنیم .مشکل این ساختار این است که در برخی اوقات مواردی پیش می آید که بسته اطلاعاتی به جای اینکه به سمت مقصد مورد نظر هدایت شود در یک چرخه یا Cycle از مسیریابها می افتند و هرگز به مقصد مورد نظر نمی رسد .
اینجا زمانی است که مفهوم TTL بوجود می آید ، شما TTL را به عنوان یک ساختار خودتخریب برای بسته اطلاعاتی در نظر بگیرید . عدد مربوط به TTL معمولا عدد بزرگی است البته این عدد بسته به نوع سیستم عاملی که شما استفاده می کنید می تواند متفاوت و متغیر باشد . هر وقت که بسته اطلاعاتی از یک مسیریاب عبور می کند به اصطلاح بسته اطلاعاتی یک HOP انجام داده است ، هر بار که یک HOP انجام شود از عدد TTL یکی کم می شود .
در یادگیری شبکه های کامپیوتری ، دوره آموزش لینوکس اسنشیالز را به عنوان مکمل همیشه در نظر داشته باشید
زمانی که این عدد به صفر برسد بسته اطلاعاتی بصورت خودکار تخریب شده و از بین می رود . این کار باعث می شود که بسته های اطلاعاتی که از بین رفته اند در شبکه باقی نمانده و از مسیر ارتباطی خارج شده و ترافیک شبکه را آزاد کنند . فقط تصور کنید که اینکار اگر انجام نشود چه مقدار ترافیک در محیط اینترنت باقی مانده و چه ترافیک عظیمی این شبکه را در بر می گیرد .
یکی دیگر از مواردی که TTL در آن بسیار کاربردی است استفاده از دستور tracert برای رفع اشکال ارتباطی است که کاملا مبتنی بر مقدار TTL است. استفاده از دستور Ping برای رفع ایراد در شبکه های کوچک و متوسطی کاربرد دارد که مقصد مورد نظر فاصله چندانی با دستگاه متقاضی ندارد ، اما در محیط اینترنت و در جایی که شاید هزاران هزار کیلومتر با شما فاصله دارد و یا شبکه های گسترده شاید چندان کاربردی نباشد .
بسته اطلاعاتی ICMP که توسط دستور Ping تولید می شود برای رسیدن به مقصد مورد نظر ممکن است از چندین و چند مسیریاب عبور کند تا به مقصد مورد نظر برسد.شما ممکن است در مواردی به این موضوع برخورد کنید که دستگاه مبدا و دستگاه مقصد هر دو به درستی کار می کنند اما یکی از مسیریابهایی که در ای بین قرار دارد دچار مشکل شده است .در اینگونه موارد شما می توانید از دستور tracert برای پیدا کردن مسیریاب مشکل دار استفاده کنید.
مبنای اصلی دستور tracert دستور Ping است . تفاوت اصلی این دستور با دستور Ping این است که ای دستور بسته اطلاعاتی ICMP را با TTL مقدار 1 ارسال میکند و به محض اینکه به اولین Hop رسید به دلیل اینکه TTL از بین می رود پیام بازگشت به کامپیوتر مبدا ارسال می کند . این پیام شامل اطلاعاتی است که مسیریاب مورد نظر که پیام بازگشت را ارسال کرده است در اختیار کامپیوتر مبدا قرار می دهد . اطلاعات اولین Hop نگهداری شده و اینبار بسته اطلاعاتی ICMP دیگری با TTL مقدار 2 ارسال می شود و از Hop اول عبور کرده و همان عملیات را برای مسیریاب دومی نیز انجام می دهد .
این فرآیند هر بار با اضافه کردن مقدار TTL ادامه پیدا می کند تا اینکه بسته اطلاعاتی به مقصد مورد نظر برسد . در اینجا لیستی از کلیه مسیریابهایی که در بین راه مبدا و مقصد قرار گرفته اند نمایش داده می شود. شما در بسیاری اوقات می توانید مشکلات مسیریابی بین روترها را نیز رفع اشکال کنید و متوجه مکانی که دچار اشکال شده است بشوید .استفاده از دستور tracert بسیار مشابه استفاده از دستور Ping است. براحتی دستور tracert را وارد کرده و در جلوی آن آدرس IP مقصد و یا FQDN مقصد را وارد کنید .شکل ب نمایش نتایج دستور tracert را نشان می دهد.
شکل ب : دستور tracert مسیر ترافیک مربوط به مسیریابهای بین مبدا و مقصد را به شما نمایش می دهد.
چندین نکته وجود دارد که در زمان استفاده از دستور tracert می بایست مورد توجه قرار دهید. اولین نکته این است که برخی از میزبان ها از فایروال برای بلاک کردن بسته های ICMP استفاده می کنند. در این مواقع شما چندین علامت ستاره را مشاهده خواهید کرد که از نمایش اطلاعات مسیریاب جلوگیری می کنند .
نکته بعدی که باید در نظر داشته باشید این است که هر مسیریاب نیز به خودی خود و مانند مقصد دارای آدرس IP خاص خودش است . بدون توجه به اینکه این آدرس برای یک مسیریاب در نظر گرفته شده است یا برای یک میزبان ، هر آدرس IP برای خود یک موقعیت جغرافیایی دارد . در برخی اوقات این موقعیت های جغرافیایی نیز توسط دستور tracert نمایش داده می شود. اگر نیاز به اطلاعات بیشتری در این زمینه بودید ابزارهای گرافیکی نیز وجود دارند که نتایج دستور tracert را بصورت گرافیکی به شما نمایش می دهند. در شکل ج نمونه ای از این ابزارها را مشاهده می کنید .
شکل ج : شما می توانید شکل جغرافیایی مسیر یابها و مسیرها را بصورت گرافیکی مشاهده کنید .
نتیجه : در این مقاله به شما آموزش دادیم که برای تست Packet Loss در شبکه چگونه اندازه بسته اطلاعاتی ارسالی توسط دستور Ping را افزایش دهیم . پس از آن دستور tracert را به شما معرفی کردیم . در ادامه مقاله بعدی به شما نحوه تحلیل کردن نتایج دستور tracert را آموزش خواهم داد.
در ادامه سری مقالات رفع مشکلات ارتباطی شبکه به بررسی و تحلیل نتایج بدست آمده از دستور TRACERT می پردازیم . در مقاله قبلی از همین سری مقالات به شما آموزش دادیم که چگونه از دستور TRACERT برای پیدا کردن مشکلات ارتباطی شبکه بین کامپیوتر مبدا و سرور مقصد که ممکن است در شبکه ای خیلی خیلی دور قرار داشته باشد استفاده کنیم و بعد از آن روش ساده ای از نحوه استفاده از این دستور را به شما آموزش دادیم ، در این مقاله به شما آموزش می دهیم که چگونه نتایج حاصل از اجرای آن دستور را تحلیل کنید .
خوب برای اینکه راحت تر موضوع را درک کنید من قبلا دستور Tracert را برای مقصد www.espn.com اجرا کرده ام ، اگر می پرسید چرا این دامنه را انتخاب کرده اید به این دلیل است که مطمئن هستم این آدرس مقصد بسته های ICMP را بلوکه نمی کند و به آنها پاسخ می دهد . خوب در ادامه اجرای دستور فوق را با نتایج حاصل شده را مشاهده می کنید ، در تمام طول این مقاله از نتیجه این دستور استفاده می کنیم :
C:\Users\Administrator>TRACERT www.espn.com Tracing route to www.espn.com [199.181.132.250] over a maximum of 30 hops: 2 ms 1 ms <1 ms 147.100.100.100 10 ms 10 ms 9 ms 208.104.224.1 9 ms 9 ms 9 ms 208.104.1.13 9 ms 8 ms 9 ms 208.104.0.13 10 ms 9 ms 10 ms 208.104.0.1 11 ms 14 ms 10 ms 165.166.125.193 11 ms 10 ms 11 ms gig-1-1-3.core01.ncchrl.infoave.net [165.166.22.61] 31 ms 31 ms 30 ms 64.200.130.17 38 ms 39 ms 40 ms hrndva1wcx2-pos15-3-oc48.wcg.net [64.200.240.213] 31 ms 31 ms 31 ms 64.200.249.170 31 ms 30 ms 31 ms 4.68.110.5 48 ms 35 ms 35 ms vlan99.csw4.Washington1.Level3.net [4.68.17.254] 32 ms 31 ms 33 ms ae-92-92.ebr2.Washington1.Level3.net [4.69.134.157] 60 ms 53 ms 54 ms ae-2.ebr3.Chicago1.Level3.net [4.69.132.69] 86 ms 71 ms 70 ms ae-3.ebr2.Denver1.Level3.net [4.69.132.61] 137 ms 103 ms 102 ms ae-2.ebr2.Seattle1.Level3.net [4.69.132.53] 95 ms 95 ms 95 ms ae-23-52.car3.Seattle1.Level3.net [4.68.105.36] 94 ms 95 ms 95 ms WALT-DISNEY.car3.Seattle1.Level3.net [4.71.152.22] * * * Request timed out. 97 ms 95 ms 98 ms 199.181.132.250 Trace complete.
اگر به نتیجه دستور Tracert بالا نگاه کنید خواهید دید که در هر خط چندین نوع اطلاعات وجود دارد که نمایش داده شده است . اولین قسمت از نتایج بدست آمده در چپ ترین قسمت نتیجه عددی است که به شماره Hop متعلق است . همانطوری که قبلا هم گفتیم دستور Tracert بوسیله ارسال بسته های Ping به آدرسم مقصد کار می کند . در هنگام صدور این دستور توسط سیستم عامل این دستور ابتدا بسته اطلاعاتی Ping را با TTL 1 به اولین Hop ارسال میکند و اولین Hop این عدد 1 را تبدیل به 0 کرده و اطلاعات و نتیجه حاصل را به دستور باز می گرداند .
در ابتدا درخواست با TTL مقدار 1 ارسال می شود و همین مسئله اطمینان حاصل می کند که در اولین Hop درخواست ارسال شده از بین خواهد رفت . در این هنگام اطلاعات مربوط به آن Hop نمایش داده می شود و در ادامه بسته ICMP مجددا ارسال خواهد شد اما اینبار با مقدار 2 ارسال میشود .
این فرآیند کم و زیاد کردن و همچنین نمایش اطلاعات آنقدر ادامه می یابد تا اینکه بسته مورد نظر به مقصد برسد . در این هنگام دستور TRACERT به شما تعداد HOP ها و همچنین مسیری که بسته اطلاعاتی طی کرده است تا به مقصد مورد نظر برسد را نمایش خواهد داد .
اگر به آخرین خط نتایج بازگشت داده شده توسط دستور نگاه کنید عدد 20 را مشاهده می کند که بدین معناست که 20 عدد HOP در میان مبدا و مقصد وجود داشته است که بسته ما از این میان عبور کرده است و به مقصد رسیده است .سه قسمت دیگر موجود در ادامه هر خط از نتیجه ، مشخص کننده مقدار زمانی است که بسته برای رسیدن به هر یک از این روترها یا بهتر بگوییم HOP ها زمان برده است . اگر دقت کرده باشید در هر خط از این نتایج که ادامه پیدا کرده و از هر HOP عبور می کند به زمان آن هم اضافه می شود . همیشه دو نکته بسیار مهم است که در مورد زمان عبور بسته های بین HOP ها می بایست بدانید .
اما همیشه به خاطر داشته باشید که این لزوما نتیجه نهایی نیست و احتمالات دیگری نیز ممکن است وجود داشته باشد . Tracert زمانی که HOP در دسترس نباشد نیز سه عدد ستاره را به عنوان پاشخ نمایش خواهد داد . خوب در اینجا یک سئوال مهم پیش میاد که چگونه میتوانیم متوجه شویم که یک HOP پورتهای ICMP را بلاک کرده است و یا اینکه در دسترس نیست !!
این مسئله ممکن است کمی گمراه کننده باشد.در اینجا باید به این نکته جالب توجه داشته باشید که در صورتیکه لینک ارتباطی شما در دسترس نباشد و روتر دچار مشکل شده باشد در هر کجای مسیر که باشد پیام Trace Completed را دریافت خواهید کرد و تست به پایان می رسد. یک نشانه خوب برای اینکه متوجه شویم لینک ما قطع شده است وجود این است که در هر جایی که لینک ما قطع شده یا دچار مشکل می شود مابقی مسیر بصورت ستاره نمایش داده میشود و HOP های بعدی همگی نتایج ستاره ای نمایش می دهند و پیغام Request Timed Out را نمایش می دهند. برای مثال در قسمت پایین و در ادامه من وب سایت www.brienposey.com را با دستور Tracert تست می کنم و نتایج را نمایش می دهم:
C:\Users\Administrator>TRACERT www.brienposey.com Tracing route to www.brienposey.com [24.235.10.4] over a maximum of 30 hops: 1 ms 1 ms <1 ms 147.100.100.100 8 ms 12 ms 8 ms 208.104.224.1 9 ms 8 ms 9 ms 208.104.1.9 10 ms 9 ms 8 ms 208.104.0.9 10 ms 12 ms 11 ms 208.104.0.5 12 ms 10 ms 9 ms 165.166.18.1 15 ms 23 ms 13 ms gig2-2-1.c01.scclma.infoave.net [165.166.22.17] 13 ms 12 ms 13 ms 66.192.166.9 31 ms 30 ms * peer-01-ge-0-0-0-1.asbn.twtelecom.net [64.129.249.10] 56 ms 57 ms 55 ms bb2-p6-0.ipltin.sbcglobal.net [151.164.242.59] 55 ms 53 ms 55 ms ded2-g8-0.ipltin.sbcglobal.net [151.164.42.159] 59 ms 56 ms 56 ms Winnet-1148485.cust-rtr.ameritech.net [66.73.221.254] 64 ms 63 ms 68 ms 216-24-2-237.ip.win.net [216.24.2.237] 68 ms 68 ms 64 ms fa0-0.cust-gw2.noc.win.net [216.24.30.69] * * * Request timed out. * * * Request timed out. * * * Request timed out. * * * Request timed out. * * * Request timed out. * * * Request timed out. * * * Request timed out. * * * Request timed out. * * * Request timed out. * * * Request timed out. * * * Request timed out. * * * Request timed out. * * * Request timed out. * * * Request timed out. * * * Request timed out. * * * Request timed out. Trace complete.
اگر نتایج بالا را مشاهده کنید قطعی لینک را به وضوح مشاهده خواهید کرد اما این بصورت قطعی پاسخ مشکل ما نخواهد بود . بهترین نتیجه از این دستور این است که چندین مقصد مختلف را با دستور آزمایش کنیم و نتایج حاصل را با هم مقایسه کنیم . همیشه در نظر داشته باشید که تعداد زیاد HOP نشان دهنده این است که مقصد از شما فاصله زیادتری دارد و هرچقدر هم این مسیر از ما دورتر باشد رفع ایراد آن دشوار تر خواهد بود .
در صورتیکه شما از مسیرهای مختلف و از سایت های مختلف مسیر را تست کنید بهترین نتیجه ممکن را در خصوص قطعی لینک بدست خواهید آورد. آخرین قسمت هر خط از پاسخی که توسط دستور Tracer نمایش داده می شود نام مسیریابی است که به درخواست ICMP فرستاده شده پاسخ داده است.
دستور Tracert تا حد امکان سعی می کند که نام روتر را به شما نمایش دهد اما در بسیاری از مواقع این امر امکانپذیر نیست . برای مثال اگر به نتایج بالا دقت کنید خواهید دید که بیش از نیمی از روتر ها با نام مشخص شده اند و این در حالی است که بقیه آنها با نام مشخص نشده اند. البته این چندان اهمیتی در اصل موضوع رفع ایراد ندارد.
نکته جالب این است که ممکن است میزبان یا همان هاستی که شما برای آن تست را انجام می دهید همیشه شناسایی نشود !!! برای مثال در اولین تستی که در همین مقاله با دستور Tracert انجام دادیم و با زدن دستور Tracert www.espn.com انجام شد بلافاصله دستور Tracert آدرس IP به شماره 199.181.132.250 را بازگرداند.
اگر شما آخر نتیجه دستور مثال بالا را نادیده بگیرید خواهید دید که دستور Tracert در نهایت به مقصد خواهد رسید اما مقصد را معملا با نام نمایش نخواهد داد ( حداقل در مثال ما ) . این رفتار یک مشکل نیست بلکه یک طراحی است . دلیل اینکه من برای شما مثال بالا را بکار بردم ای است که شما معملا دستور Tracert را برای یک وب سایت بکار نمی برید و البته من فکر میکنم که در مثال بالا به دلیل این نتایج به مشکل خورد که ما با نام مقصد را تعیین کردیم و نه با آدرس IP مقصد.