تشخيص مشكلة توجيه شبكة جهاز ظاهري - واجهة مستوى الاستدعاء Azure

في هذه المقالة، تقوم بنشر جهاز ظاهري (VM)، ثم تتحقق من التوصيلات بعنوان IP وعنوان URL. أنت تحدد سبب فشل الاتصال وكيف يمكنك حله.

إذا لم يكن لديك اشتراك في Azure، فأنشئ حساب Azure مجاني قبل أن تبدأ.

المتطلبات الأساسية

  • تتطلب هذه المقالة الإصدار 2.0 أو أحدث من Azure CLI. إذا كنت تستخدم Azure Cloud Shell، يتم تثبيت أحدث إصدار بالفعل.

  • وأوامر واجهة مستوى الاستدعاء Azure في هذه المقالة منسقة للتشغيل في Bash shell.

قم بإنشاء جهاز ظاهري

قبل أن تتمكن من إنشاء جهاز ظاهري، ينبغي عليك إنشاء مجموعة موارد لاحتواء الجهاز الظاهري. أنشئ مجموعة موارد باستخدام إنشاء مجموعة az. في المثال التالي، سيتم إنشاء مجموعة موارد باسم myResourceGroup في موقع eastus:

az group create --name myResourceGroup --location eastus

قم بإنشاء جهاز ظاهري VM باستخدام "az vm إنشاء". وإذا لم تكن مفاتيح SSH موجودة بالفعل في موقع المفتاح الافتراضي، ينشئها الأمر. لاستخدام مجموعة محددة من المفاتيح، استخدم الخيار --ssh-key-value. وينشئ المثال التالي جهازًا ظاهريًا باسم myVm:

az vm create \
  --resource-group myResourceGroup \
  --name myVm \
  --image Ubuntu2204 \
  --generate-ssh-keys

ويستغرق إنشاء جهاز ظاهري بضع دقائق. لا تتابع الخطوات المتبقية حتى يتم إنشاء الجهاز الظاهري وإرجاع واجهة مستوى الاستدعاء Azure للإخراج.

اختبار اتصال شبكة ما

لاختبار اتصال الشبكة مع Network Watcher، ينبغي عليك أولاً تمكين Network Watcher في المنطقة التي يوجد فيها الجهاز الظاهري الذي تريد اختباره، ثم استخدام إمكانية الوثب التالية لـ Network Watcher لاختبار الاتصال.

تمكين مراقب الشبكة

وإذا كان لديك بالفعل مراقب شبكة ممكّنًا في شرق الولايات المتحدة، انتقل إلى استخدام الوثب التالي. واستخدم أمر تكوين مراقب الشبكة az لإنشاء مراقب شبكة في شرق الولايات المتحدة:

az network watcher configure \
  --resource-group NetworkWatcherRG \
  --locations eastus \
  --enabled

استخدم القفزة التالية

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

قم باختبار الاتصال الصادر من الجهاز الظاهري إلى أحد عناوين IP لموقع www.bing.com:

az network watcher show-next-hop \
  --dest-ip 13.107.21.200 \
  --resource-group myResourceGroup \
  --source-ip 10.0.0.4 \
  --vm myVm \
  --nic myVmVMNic \
  --out table

وبعد بضع ثوان، يعلمك الناتج بأن نوع الوثب التاليهوالإنترنت، وأن routeTableIdهوSystem Route. ويتيح لك هذا الناتج معرفة أن هناك مسار نظام صالح إلى الوجهة.

اختبر الاتصال الصادر من الجهاز الظاهري إلى 172.31.0.100:

az network watcher show-next-hop \
  --dest-ip 172.31.0.100 \
  --resource-group myResourceGroup \
  --source-ip 10.0.0.4 \
  --vm myVm \
  --nic myVmVMNic \
  --out table

فيعلمك الناتج الذي تم إرجاعه بأنNone هو نوع الوثب التالي، وبأنrouteTableId هو أيضًاSystem Route. تتيح لك هذه النتيجة معرفة أنه، في حين يوجد مسار نظام صالح إلى الوجهة، لا توجد قفزة تالية لتوجيه حركة نقل البيانات إلى الوجهة.

عرض تفاصيل مسار ما

لتحليل التوجيه بشكل أكبر، راجع المسارات الفعالة لواجهة الشبكة مع الأمر az شبكة nic إظهار جدول مسار فعال:

az network nic show-effective-route-table \
  --resource-group myResourceGroup \
  --name myVmVMNic

وتم تضمين النص التالي في الناتج الذي تم إرجاعه:

{
  "additionalProperties": {
    "disableBgpRoutePropagation": false
  },
  "addressPrefix": [
    "0.0.0.0/0"
  ],
  "name": null,
  "nextHopIpAddress": [],
  "nextHopType": "Internet",
  "source": "Default",
  "state": "Active"
},

عندما استخدمت الأمرaz network watcher show-next-hopلاختبار الاتصال الصادر إلى 13.107.21.200 في استخدام الوثب التالي، استُخدم المسار الذي يحوي سابقة العنوان0.0.0.0/0** لتوجيه نسبة استخدام الشبكة إلى العنوان، إذ إنه لا يتضمن أي مسار آخر العنوان. وتُوجه جميع العناوين غير المحددة ضمن بادئة العنوان افتراضياً لمسار آخر إلى الإنترنت.

إلا أنه عند استخدام الأمر az network watcher show-next-hopلاختبار الاتصال الصادر إلى 172.31.0.100، أعلمك بأنه لم يكن هناك نوع وثب تالي. وفي الإخراج الذي تم إرجاعه، سترى النص التالي:

{
  "additionalProperties": {
    "disableBgpRoutePropagation": false
      },
  "addressPrefix": [
    "172.16.0.0/12"
  ],
  "name": null,
  "nextHopIpAddress": [],
  "nextHopType": "None",
  "source": "Default",
  "state": "Active"
},

كما ترى في الإخراج عن الأمرaz network watcher nic show-effective-route-table، على الرغم من وجود مسار افتراضي إلى السابقة 172.16.0.0/12 التي تتضمن عنوان 172.31.0.100،عنوان الوثب التاليهوNone. وينشئ Azure مسارًا افتراضيًا إلى 172.16.0.0/12، إلا أنه لا يحدد نوع الوثب التالي إلى أن يوجد سبب لذلك. فإذا، على سبيل المثال، أضفت نطاق العنوان 172.16.0.0/12 إلى مساحة عنوان الشبكة الظاهرية، يغير AzurenextHopType إلى الشبكة الظاهريةللمسار. ثم، قد يظهر الفحصالشبكة الظاهريةكنوعnextHopType.

تنظيف الموارد

عندما لم تعد هناك حاجة، يمكنك استخدام حذف مجموعة azلإزالة مجموعة الموارد وجميع الموارد التي تحويها:

az group delete --name myResourceGroup --yes

الخطوات التالية

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

بالنسبة إلى اتصالات الجهاز الظاهري الصادرة، يمكنك أيضًا تحديد زمن الانتقال ونسبة استخدام الشبكة المسموح بها وغير المسموح بها بين الجهاز الظاهري ونقطة نهاية، باستخدام إمكانية استكشاف أخطاء الاتصال وإصلاحها في Network Watcher. يمكنك مراقبة الاتصال بين جهاز ظاهري ونقطة نهاية، مثل عنوان IP أو عنوان URL بمرور الوقت باستخدام إمكانية مراقبة اتصال Network Watcher. لمزيد من المعلومات، راجع مراقبة اتصال الشبكة.