استكشاف أخطاء الشبكة وإصلاحها - إصلاح مشكلات الشبكة بشكل أسرع‎

غالبًا ما تكون مشكلات الشبكة فريدة من نوعها ويصعب حلها في بعض الأحيان. عادةً ما يتطلب استكشاف الأخطاء وإصلاحها التعامل مع الأشياء غير المرغوب فيها إتقان المعرفة المفاهيمية فقط، وليس معرفة التفاصيل اللازمة لتكوين الشبكة. لحل المشكلة بشكل صحيح وسلس، تحتاج إلى فهم واضح لشبكة LAN بأكملها، وفهم كبلات الشبكة، والبيئة الكهربائية، وكيفية عمل TCP/IP على الشبكة، وعلى مضيف واحد، وتوجيه البيانات بين طبقات مكدس البروتوكول، وما إلى ذلك. هذه الأمور مهمة جدًا لإصلاح الشبكة ومفيدة جدًا لمعرفة جزء استكشاف الأخطاء وإصلاحها من شهادة Cisco أو جزء آخر من تكنولوجيا المعلومات.

بعض النصائح التالية مفيدة في استكشاف مشكلات الشبكة وإصلاحها:

1. لا تتجاهل الأمور الواضحة. تعد كابلات الشبكة الفضفاضة مشكلة شائعة. يجب فحص المقابس والموصلات والكابلات والمحاور والمفاتيح. يمكن أن تتسبب الأشياء الصغيرة في حدوث مشكلات كبيرة.

2. معظم المشاكل ناجمة عن عوامل بشرية (أخطاء). من خلال توفير معلومات حول تكوين الشبكة والدور أو تقديم التدريب في هذا المجال، يمكن القضاء على معظم الأخطاء.

3. ينبغي الانتباه إلى طريقة حل المشكلة، وينبغي استخدام المعلومات التي تم جمعها أثناء كل اختبار لتوجيه الاختبار الخاص بك، إذا لم تتمكن من ضمان بيئة الاختبار الأصلية التي اخترتها، فلا تنقل إلى بيئة اختبار أخرى بناءً على افتراضات ذاتية في.

4. يجب عليك توسيع نطاق تفكيرك وأن تكون مرنًا. لا تعتقد أن هناك أسبابًا كثيرة للمشكلة. لا تعتقد أن المشكلة التي وجدتها على مستوى التطبيق لا تسببها المستوى التالي. يعتقد بعض الأشخاص دائمًا أن الشبكة معيبة، بينما يعتقد آخرون دائمًا أن هناك مشكلة في الطرف البعيد. بعض الأشخاص متأكدون جدًا من أنهم يعرفون سبب المشكلة، بغض النظر عن نتائج الاختبار. لا تكرر هذه الأخطاء. اختبر كل موقف ممكن وقرر أفعالك بناءً على نتائج الاختبار.

5. استخدم عدة أدوات بسيطة لاستكشاف الأخطاء وإصلاحها. بالنسبة لمعظم مشكلات برامج TCP/IP، يكفي استخدام عدد قليل من الأدوات البسيطة لحل المشكلة، ومن الجدير أن تأخذ الوقت الكافي لتعلم كيفية استخدام أداة الخدمة الجديدة. نظرًا لأن أسباب العديد من مشكلات الشبكة بسيطة، فمن الممكن غالبًا العثور على إجابة إذا كان لديك فهم واضح للمشكلة. لسوء الحظ، هذا ليس هو الحال دائمًا! فيما يلي بعض الأدوات البسيطة التي يمكن أن تساعدك في حل أصعب المشكلات.

Ping: يمكن العثور على أداة الأمر هذه على أنظمة Linux/Unix، وDos، وWindows 9x، وWindows NT، وأنظمة أخرى.

تستطيع هذه الأداة اختبار ما إذا كان نظامك قادرًا على الوصول إلى مضيف بعيد. هذه الميزة البسيطة مفيدة جدًا لاختبار اتصالات الشبكة، بغض النظر عن التطبيق الذي تم اكتشاف المشكلة فيه. تتيح لك أداة Ping اختبار طبقة اتصال الشبكة (الطبقة السفلية) أو طبقة التطبيق (الطبقة العليا). إذا أظهرت أداة Ping أن رسالة الحزمة يمكن أن تذهب إلى النظام البعيد وتعود، فقد تكون مشكلة المستخدم في الطبقة العليا؛ إذا تعذر إرجاع رسالة الحزمة، فقد يكون الفشل في طبقة البروتوكول السفلية أو الطبقة المادية.

استخدم اسم مضيف المستخدم أو عنوان IP لاستخدام أمر ping على المضيف البعيد أولاً. إذا كان التنفيذ ناجحًا، فسيستخدم المستخدم أمر ping للمضيف. إذا كان التنفيذ ناجحًا، فيجب عليك التركيز على تحليل المستخدم الذي يواجه المشكلة.

إذا نجح أمر ping الخاص بك وفشل أمر ping الخاص بالمستخدم، فيمكنك اختبار ملف تكوين نظام المستخدم مركزيًا ومقارنة المسار بينك وبين المستخدم والمضيف البعيد للعثور على الاختلافات.

إذا فشلت أنت والمستخدم في تنفيذ أمر ping، فإن رسالة الخطأ التي يعرضها أمر ping مفيدة ويمكن أن ترشدك خلال خطة الاختبار التالية. فيما يلي بعض الأنواع الأساسية من الأخطاء: مضيف غير معروف لا يمكن ترجمة اسم المضيف البعيد إلى عنوان IP بواسطة DNS (خادم اسم المجال)، قد يفشل DNS، قد يكون الاسم غير صحيح، بين نظامك والخادم البعيد قد تكون الشبكة خارج الخدمة. إذا كنت تعرف عنوان IP للمضيف البعيد، فيمكنك تجربة أمر ping مرة أخرى. إذا كان من الممكن الوصول إلى المضيف باستخدام عنوان IP الخاص به، فقد تكون المشكلة في DNS.

لا يمكن الوصول إلى الشبكة لا يوجد مسار للنظام المحلي إلى النظام البعيد. إذا كنت تستخدم عنوان IP في أمر ping، فأعد إدخال أمر ping باسم المضيف، مما يلغي إمكانية إدخال عنوان IP غير صحيح. إذا كنت تستخدم بروتوكول توجيه، فتأكد من تشغيله واستخدم nestat للتحقق من جدول التوجيه الخاص به.

لا توجد إجابة النظام البعيد لا يستجيب. تحتوي معظم أدوات الشبكة على أشكال مختلفة من المعلومات المتشابهة. يمكن لبعض الأنظمة طباعة إشارات ping لفقدان الحزمة بنسبة 100% وtelnet إلى مهلة الاتصال. تشير جميع رسائل الخطأ هذه إلى نفس المشكلة: يحتوي النظام المحلي على مسار إلى النظام البعيد، ولكنه لا يتلقى أي استجابات لرسائل الحزمة التي يرسلها إلى النظام البعيد. هناك العديد من الأسباب لهذه المشكلة، فقد لا يعمل المضيف البعيد، أو قد يكون المضيف المحلي أو البعيد غير مهيأ بشكل صحيح، أو يكون الخط الفاصل بين المضيفين المحليين والبعيدين غير طبيعي، وما إلى ذلك. لا يمكن استخدام سوى طرق أخرى لعزل سبب المشكلة.

لقد تم إلغاء العديد من اللغات، وأخيرًا ظهر سبب "إلغاء ping" إلى الواجهة. لم أفهم الأمر بشكل أعمق. يرجى تحملي. دعنا نستمر في رؤية محتوى ping بعد ping.

الشكل الأساسي لأمر ping هو: ping host [packetsize][count] (أنظمة مختلفة، تنسيق مختلف قليلاً) host هو اسم المضيف أو عنوان IP للمضيف البعيد الذي يتم اختباره. Packetsize اختياري ويحدد طول حزمة الاختبار (Byte)، والذي يتم استخدامه فقط عند استخدام حقل count. ومع ذلك، يبلغ طول الحزمة 56 بايت، وcount هو عدد الحزم المرسلة أثناء الاختبار. يتم تعيين count بشكل عام على قيمة أقل، وعادة ما يتم تعيينه على 4 أو 5.

لاختبار ما إذا كان بإمكانك الوصول إلى ly من الرابط، استخدم الأمر التالي: C:>ping ly إرسال ping إلى ly [222.222.222.15] باستخدام 32 بايت من البيانات: الرد من 222.222.222.15:bytes=32 الوقت=1ms TTL=128

الرد من 222.222.222.15: بايت = 32 الوقت = 1 مللي ثانية TTL = 128

الرد من 222.222.222.15: بايت = 32 الوقت = 1 مللي ثانية TTL = 128

الرد من 222.222.222.15: بايت = 32 الوقت = 1 مللي ثانية TTL = 128

إحصائيات Ping لـ 222.222.222.15:

الحزم: المرسلة = 4، المستلمة = 4، المفقودة = 0 (خسارة 0%)،

المسافة التقريبية ذهابًا وإيابًا بالمللي ثانية:

الحد الأدنى = 1 مللي ثانية، الحد الأقصى = 1 مللي ثانية، المتوسط ​​= 1 مللي ثانية يشير هذا الاختبار إلى أن الارتباط باتصال ly طبيعي جدًا، ولا يتم فقد أي حزم، والاستجابة سريعة. تستغرق الرحلة ذهابًا وإيابًا بين الارتباط وly في المتوسط ​​1 مللي ثانية. بالنسبة لاتصالات LAN، كلما قل فقدان الحزمة وكلما كان وقت الرحلة ذهابًا وإيابًا أصغر، كان الأمر طبيعيًا أكثر. TTL (وقت البقاء) = 128. يمكن أن تشير الإحصائيات التي يعرضها الأمر ping إلى المستوى التالي من مشكلات الشبكة. الإحصائيات الرئيسية هي: * كم من الوقت يستغرق انتقال الحزمة ذهابًا وإيابًا، والذي يتم عرضه بعد الوقت =.

* نسبة فقدان الحزمة. يتم عرضها في سطر الإحصائيات الإجمالية في نهاية إخراج ping.

* الترتيب الذي تصل به الحزم. مثل رقم تسلسل ICMP (icmp_seq) لكل حزمة.

إذا كان معدل فقدان الحزمة مرتفعًا، أو كان وقت الاستجابة بطيئًا للغاية، أو وصلت الحزم خارج الترتيب، فهناك احتمال أن يكون هناك خلل في الأجهزة؛ بالطبع، إذا حدثت هذه المواقف على شبكة WAN، فلا داعي للقلق كثيرًا.

في الشبكة المحلية، يكون وقت الذهاب والإياب مساويًا تقريبًا لـ 1 مللي ثانية، مع فقدان ضئيل أو معدوم للحزم، ويجب أن تصل كل حزمة بالترتيب.

إذا لم يكن الأمر كذلك، فهناك مشكلة في أجهزة الشبكة. في Ethernet، قد يكون ذلك بسبب: إنهاء الكابل غير المناسب (مقاومة الإنهاء)، كابل رديء، أجهزة نشطة رديئة (Hub، إلخ). تحقق أولاً من إنهاء الكابل، إنه أمر سهل للغاية، وتحقق مما إذا كان هناك مقاومة إنهاء. هذه واحدة من أكثر الطرق شيوعًا وبساطة للكشف عن الكابل عن طريق قياس مقاومة المنفذ بمقياس متعدد. إذا كانت مقاومة المنفذ المقاسة صفرًا، فإن الكابل به ماس كهربائي، والدائرة مفتوحة إلى ما لا نهاية. يشير 50 ​​أوم أو نحو ذلك إلى وجود مقاومة إنهاء تتساقط، والتي يجب أن تكون حوالي 25 أوم.

إن نتيجة اختبار ping البسيط، حتى لو نجحت، سترشدك خلال اختبارات أخرى لمساعدتك في العثور على المشكلة الأكثر احتمالية. ولكن للتعمق في المشكلة والعثور على السبب الأساسي، ستحتاج إلى أدوات تشخيص إضافية.

أخيرًا، تم تقديم بعض الأدوات المفيدة بشكل موجز: توفر netstat مجموعة متنوعة من المعلومات، والتي تُستخدم عادةً لعرض إحصائيات مفصلة لكل واجهة شبكة، ومقبس شبكة، وجدول توجيه شبكة، وما إلى ذلك.

يوفر Arp معلومات حول ترجمة عنوان IP الخاص بشبكة Ethernet، والتي يمكن استخدامها للكشف عن الأنظمة في الشبكة المحلية التي تم تكوينها باستخدام عنوان IP الخاطئ.

يوفر Ifconfig معلومات أساسية عن التكوين للواجهة. وهو مفيد للكشف عن عناوين IP وأقنعة الشبكات الفرعية وعناوين البث غير الصحيحة.