قبل أيام PowerShell Test-NetConnection cmdlet، كان لدينا العديد من الأدوات سطر الأوامر المختلفة التي يمكننا اختيارها لتحديد مشاكل الاتصال بالشبكة المختلفة.
كان لدينا ping لاختبار صدى ICMP والردود؛ tracert لمعرفة أين قد تكون حزمنا تتساقط؛ nslookup لأداء استعلامات DNS ضد خوادم DNS الخاصة بنا؛ telnet للتحقق من فتح المنافذ TCP، ومجموعة متنوعة من الأدوات الأخرى. كانت هناك أداة لكل شيء.
مع إدخال PowerShell v4 على Windows 8.1 و Windows Server 2012 R2، أصبح هذا النهج الفردي لحل المشكلات تحديد مشكلات الاتصال قديمًا.
اسمحوا لي أن أقدم لكم الأمر الجديد والقوي Test-NetConnection cmdlet. فكر في PowerShell Test-NetConnection كـ ping، tracert، nslookup، telnet، وبعض الأدوات الأخرى الملفوفة في مجموعة واحدة من الأدوات لحل المشاكل.
حل المشكلات باستخدام Test-NetConnection
دعونا نرى ما يمكننا فعله باستخدام أمر Powershell test-netconnection ونرى كيف يمكننا استخدامه عندما نكون في موقف غير محظوظ من تحديد مشكلة الاتصال بالشبكة.
لتوضيح هذا، سأستخدم PowerShell Test-NetConnection لتحليل مشكلة شائعة في العالم الحقيقي: “لا يمكنني الوصول إلى موقع XYZ!”
ما يجهله معظم المستخدمين هو أن عرض موقع على متصفح الويب يعتبر بحد ذاته إنجازًا مذهلاً نظرًا لعدد الأجزاء المتحركة التي يجب أن تعمل معًا لتحقيق ذلك. على الأقل، ينطوي العملية على:
- وجود اتصال بالإنترنت.
- وجود مسار إلى خادم DNS الخاص بك.
- الاتصال بخادم DNS لحل عنوان URL.
- وجود مسار إلى عنوان IP الذي يحل عنوان URL إلى.
- فتح منفذ TCP 80.
- وما إلى ذلك، وما إلى ذلك.
تأكيد اتصالك بالإنترنت
للبدء في عملية تحليل المشكلة، ستحتاج أولاً إلى التحقق من وجود اتصال بالإنترنت. يمكنك فعل ذلك ببساطة عن طريق تشغيل PowerShell Test-NetConnection بدون تحديد معلمات. ومع ذلك، إذا كنت ترغب في الحصول على مزيد من المعلومات، فأقترح استخدام معلمة InformationLevel مع الوسيطة Detailed.
هذا الأمر البسيط يتحقق من توصيلك المحلي وتوصيلك بالإنترنت ويؤكد أن عميل DNS الخاص بك يمكنه حل الأسماء الموجهة إلى خادم DNS الخاص بك كل ذلك في ضربة واحدة. اعتبره فحصًا عامًا لصحة اتصالك بالشبكة. يتحقق هذا الأمر من ثلاثة من العمليات الخمسة اللازمة لعرض موقع على الويب في عملية واحدة!
استخدم Test-NetConnection لاختبار اتصالك بمضيف موقع الويب
سنحتاج الآن إلى توجيه جهود الإصلاح إلى مضيف موقع الويب المعني. دعونا نستخدم google.com كمثال. يمكنك أيضًا استخدام جهاز كمبيوتر عن بُعد.
يمكننا استخدام Test-NetConnection مع معلمة ComputerName للتأكد في وقت واحد من إمكانية حل مضيف موقع الويب في DNS، ووجود مسار TCP للوصول إلى عنوان IP الذي يتم حله بالاسم، والتحقق من إمكانية البينغ له.
على الرغم من أن هذه الخطوة تتحقق تقنيًا من وجود مسار إلى خادم الويب google.com، إلا أنني أرغب في العثور على معلومات أكثر تفصيلاً حول الراوترات التي يتدفق من خلالها حزم بياناتي للوصول إلى خادم الويب google.com. للقيام بذلك، سأستخدم معلمة TraceRoute للحصول على قائمة.
التأكد من فتح منفذ TCP الخاص بك
اختبارنا النهائي هو التحقق من أن منفذ TCP الذي نتوقع أن يعمل عليه خادم الويب مفتوح. في هذه الحالة، نظرًا لأننا نحدد فقط google.com، سأفترض أنها منفذ TCP 80. للقيام بذلك، سنضيف ببساطة معلمة أخرى إلى Test-NetConnection. نظرًا لأن Test-NetConnection يفهم منفذ TCP القياسي لبعض الخدمات المختلفة، لا نحتاج حتى إلى معرفة رقم المنفذ. يمكنني فقط تمرير HTTP إلى معلمة CommonTCPPort وستقوم بالعمل بدلاً مني.
ومع ذلك، إذا كان الموقع قد يعمل تحت منفذ مختلف، مثل 8080، يمكنك تحديد منفذ TCP مباشرة باستخدام معلمة Port بدلاً من ذلك.
لقد قمنا الآن باختبار كل متطلبات الاتصال الموضحة في بداية هذه المقالة. إذا لم نتمكن بعد من عرض الموقع الإلكتروني في هذا الوقت، فقد تأكدنا من أن المشكلة ليست بسبب عميلنا، ويمكننا تمرير المشكلة إلى Google أو ربما خادم DNS منخفض المستوى.