مشاركة عبر

الوصول الصادر الافتراضي في Azure

في Azure، عندما تقوم بنشر آلة افتراضية (VM) في شبكة افتراضية بدون طريقة اتصال صادرة محددة بشكل صريح، يقوم Azure تلقائيا بتعيين عنوان IP عام صادر. يتيح عنوان IP هذا الاتصال الصادر من الموارد إلى الإنترنت ونقاط النهاية العامة الأخرى داخل Microsoft. يُشار إلى هذا الوصول باسم الوصول الصادر الافتراضي.

أمثلة على الاتصال الصادر الصريح للأجهزة الظاهرية هي:

  • نشر في شبكة فرعية مقترنة ببوابة NAT.
  • تم نشره في تجمع الواجهة الخلفية لموازن التحميل القياسي مع تحديد القواعد الصادرة.
  • تم نشره في تجمع الخلفية لموازن تحميل عام أساسي.
  • الأجهزة الظاهرية ذات عناوين IP العامة المقترنة بها صراحة.

رسم تخطيطي لخيارات الصادر الصريحة.

كيفية ووقت توفير الوصول الصادر الافتراضي

إذا تم نشر جهاز ظاهري (VM) دون أسلوب اتصال صادر صريح، يقوم Azure بتعيين عنوان IP عام افتراضي صادر. عنوان IP هذا، المعروف باسم عنوان IP الافتراضي للوصول الصادر، مملوك لشركة Microsoft ويمكن تغييره دون إشعار. لا يوصى به لأحمال عمل الإنتاج.

رسم تخطيطي لشجرة القرار للوصول الصادر الافتراضي.

Note

في بعض الحالات، لا يزال يتم تعيين عنوان IP صادر افتراضي للأجهزة الظاهرية في شبكة فرعية غير خاصة، حتى عند تكوين أسلوب صادر صريح - مثل بوابة NAT أو UDR الذي يوجه نسبة استخدام الشبكة إلى NVA/جدار حماية -. هذا لا يعني أنه يتم استخدام عناوين IP الصادرة الافتراضية للخروج ما لم تتم إزالة هذه الطرق الصريحة. لإزالة عناوين IP الصادرة الافتراضية تماما، يجب جعل الشبكة الفرعية خاصة، ويجب إيقاف الأجهزة الظاهرية وإلغاء تخصيصها.

Important

بعد 31 مارس 2026، سيتم استخدام الشبكات الظاهرية الجديدة افتراضيا لاستخدام الشبكات الفرعية الخاصة، مما يعني أنه يجب تمكين طريقة صادرة صريحة للوصول إلى نقاط النهاية العامة على الإنترنت وداخل Microsoft. لمزيد من المعلومات، راجع الإعلان الرسمي. نوصي باستخدام أحد أشكال الاتصال الصريحة التي تمت مناقشتها في القسم التالي. للأسئلة الأخرى، راجع القسم "الأسئلة المتداولة: تغيير السلوك الافتراضي إلى الشبكات الفرعية الخاصة".

الأمان: يتعارض الوصول الافتراضي إلى الإنترنت مع مبادئ انعدام الثقة.
الوضوح: يفضل الاتصال الصريح على الوصول الضمني.
الاستقرار: عنوان IP الصادر الافتراضي ليس مملوكا للعميل ويمكن أن يتغير، مما يؤدي إلى حدوث اضطرابات محتملة.

بعض الأمثلة على التكوينات التي لا تعمل عند استخدام الوصول الصادر الافتراضي:

  • يمكن أن تؤدي بطاقات واجهة الشبكة المتعددة على جهاز ظاهري إلى عناوين IP صادرة غير متسقة
  • يمكن أن يؤدي تحجيم مجموعات مقياس الجهاز الظاهري Azure إلى تغيير عناوين IP الصادرة
  • عناوين IP الصادرة ليست متسقة أو متصلة عبر مثيلات مجموعة مقياس الآلة الافتراضية

الاضافه الي ذلك

  • لا تدعم عناوين IP الافتراضية للوصول الصادر الحزم المجزأة
  • لا تدعم عناوين IP الافتراضية للوصول الصادر عمليات اتصال ICMP

كيف يمكنني الانتقال إلى طريقة صريحة للاتصال العام (وتعطيل الوصول الصادر الافتراضي)؟

نظرة عامة على الشبكات الفرعية الخاصة

  • يؤدي إنشاء شبكة فرعية لتكون خاصة إلى منع أي أجهزة ظاهرية على الشبكة الفرعية من استخدام الوصول الصادر الافتراضي للاتصال بنقاط النهاية العامة.
  • لا يزال بإمكان الأجهزة الظاهرية الموجودة على شبكة فرعية خاصة الوصول إلى الإنترنت (أو أي نقاط نهاية عامة داخل Microsoft) باستخدام اتصال صادر صريح.

    Note

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

كيفية تكوين الشبكات الفرعية الخاصة

  • من مدخل Microsoft Azure، حدد الشبكة الفرعية وحدد خانة الاختيار لتمكين الشبكة الفرعية الخاصة كما هو موضح:

لقطة شاشة لمدخل Azure تعرض خيار الشبكة الفرعية الخاصة.

  • باستخدام PowerShell، يأخذ البرنامج النصي التالي أسماء مجموعة الموارد والشبكة الظاهرية ويتكرر عبر كل شبكة فرعية لتمكين الشبكة الفرعية الخاصة.
$resourceGroupName = ""
$vnetName = ""
 
$vnet = Get-AzVirtualNetwork -ResourceGroupName $resourceGroupName -Name $vnetName
 
foreach ($subnet in $vnet.Subnets) {
    if ($subnet.DefaultOutboundAccess -eq $null) {
        $subnet.DefaultOutboundAccess = $false
        Write-Output "Set 'defaultoutboundaccess' to \$false for subnet: $($subnet.Name)"
    } 
    elseif ($subnet.DefaultOutboundAccess -eq $false) {
        # Output message if the value is already $false
        Write-Output "already private for subnet: $($subnet.Name)"
    }
}
Set-AzVirtualNetwork -VirtualNetwork $vnet
  • باستخدام CLI، قم بتحديث الشبكة الفرعية مع az network vnet subnet update وتعيينها --default-outbound إلى "false"
az network vnet subnet update --resource-group rgname --name subnetname --vnet-name vnetname --default-outbound false
  • باستخدام قالب Azure Resource Manager، قم بتعيين قيمة المعلمة defaultOutboundAccess لتكون "خطأ"
{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "vnetName": {
      "type": "string",
      "defaultValue": "testvm-vnet"
    },
    "subnetName": {
      "type": "string",
      "defaultValue": "default"
    },
    "subnetPrefix": {
      "type": "string",
      "defaultValue": "10.1.0.0/24"
    },
    "vnetAddressPrefix": {
      "type": "string",
      "defaultValue": "10.1.0.0/16"
    }
  },
  "resources": [
    {
      "type": "Microsoft.Network/virtualNetworks",
      "apiVersion": "2023-11-01",
      "name": "[parameters('vnetName')]",
      "location": "westus2",
      "properties": {
        "addressSpace": {
          "addressPrefixes": [
            "[parameters('vnetAddressPrefix')]"
          ]
        },
        "subnets": [
          {
            "name": "[parameters('subnetName')]",
            "properties": {
              "addressPrefix": "[parameters('subnetPrefix')]",
              "defaultoutboundaccess": false
            }
          }
        ]
      }
    }
  ]
}

قيود الشبكات الفرعية الخاصة

  • لتنشيط أنظمة تشغيل الجهاز الظاهري أو تحديثها، مثل Windows، يلزم وجود أسلوب اتصال صادر صريح.

  • في التكوينات التي تستخدم المسارات المعرفة من قبل المستخدم (UDRs)، أي مسارات تم تكوينها مع فاصل نوع Internetالوثب التالي في شبكة فرعية خاصة.

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

      • يتم تطبيق مسار افتراضي للوجهة 0.0.0.0/0، مع نوع القفزة التالي من الجهاز الظاهري في الحالة العامة.

      • يتم تكوين مسار واحد أو أكثر إلى وجهات "علامة الخدمة" بنوع Internetالوثب التالي ، لتجاوز NVA/جدار الحماية. ما لم يتم تكوين طريقة اتصال صادرة صريحة أيضا لمصدر الاتصال بهذه الوجهات، فإن محاولات الاتصال بهذه الوجهات تفشل، لأن الوصول الخارجي الافتراضي غير متوفر افتراضيا في شبكة فرعية خاصة.

    • لا ينطبق هذا القيد على استخدام نقاط نهاية الخدمة، التي تستخدم نوع VirtualNetworkServiceEndpointقفزة تالية مختلف . راجع نقاط نهاية خدمة الشبكة الظاهرية.

  • لا تزال الأجهزة الظاهرية قادرة على الوصول إلى حسابات Azure Storage في نفس المنطقة في شبكة فرعية خاصة دون طريقة صريحة للصادر. يوصى باستخدام مجموعات أمان الشبكة للتحكم في اتصال الخروج.

  • لا تنطبق الشبكات الفرعية الخاصة على الشبكات الفرعية المفوضة أو المدارة المستخدمة لاستضافة خدمات PaaS. في هذه السيناريوهات، تتم إدارة الاتصال الصادر بواسطة الخدمة الفردية.

Important

عند تكوين تجمع الواجهة الخلفية لموازن التحميل بواسطة عنوان IP، فإنه يستخدم الوصول الصادر الافتراضي بسبب مشكلة معروفة مستمرة. للتكوين والتطبيقات الآمنة بشكل افتراضي مع الاحتياجات الصادرة المطلوبة، قم بإقران بوابة NAT بالأجهزة الظاهرية في تجمع الواجهة الخلفية لموازن التحميل لتأمين نسبة استخدام الشبكة. اطلع على المزيد حول المشكلات المعروفة الحالية.

إضافة أسلوب صادر صريح

  • قم بإقران بوابة NAT بالشبكة الفرعية لجهازك الظاهري. لاحظ أن هذه هي الطريقة الموصى بها لمعظم السيناريوهات.
  • إقران موازن تحميل قياسي تم تكوينه بقواعد صادرة.
  • قم بإقران عنوان IP عام قياسي بأي من واجهات شبكة الجهاز الظاهري.
  • أضف جدار حماية أو جهاز ظاهري للشبكة (NVA) إلى شبكتك الظاهرية وأشر إلى نسبة استخدام الشبكة إليها باستخدام مسار معرف من قبل المستخدم (UDR).

استخدام وضع التزامن المرن لمجموعات مقياس الجهاز الظاهري

  • مجموعات المقاييس المرنة آمنة بشكل افتراضي. لا تحتوي أي مثيلات تم إنشاؤها عبر مجموعات المقياس المرنة على عنوان IP الافتراضي للوصول الصادر المرتبط بها، لذلك مطلوب أسلوب صادر صريح. لمزيد من المعلومات، راجع وضع التنسيق المرن لمجموعات مقياس الجهاز الظاهري

الأسئلة الشائعة: مسح تنبيه IP الصادر الافتراضي

لماذا أرى تنبيها يوضح أن لدي عنوان IP صادر افتراضي على الجهاز الظاهري الخاص بي؟

هناك معلمة على مستوى شبكة الشبكة (defaultOutboundConnectivityEnabled) تتتبع ما إذا كان IP الصادر الافتراضي مخصصا لنسخة VM/Virtual Machine Scale Set. يستخدم هذا لإنشاء لافتة بوابة Azure لمجموعة مقياس الآلة الافتراضية/الآلة الافتراضية التي تشير إلى هذه الحالة. هناك أيضا توصيات محددة ل Azure Advisor مع هذه المعلومات لاشتراكاتك. إذا كنت ترغب في عرض أي من أجهزتك الافتراضية أو مجموعات مقياس الآلة الافتراضية التي لديها عنوان IP خارجي افتراضي مخصص لها، اتبع هذه الخطوات:

  1. اكتب 'Advisor' في شريط البحث في بوابة Azure ثم اختر هذا الخيار عند ظهوره.
  2. حدد "التميز التشغيلي"
  3. ابحث عن التوصيات 'إضافة طريقة صادرة صريحة لتعطيل الخروج الافتراضي' و/أو 'إضافة طريقة صادرة صريحة لتعطيل الإصدار الافتراضي لمجموعات مقياس الآلة الافتراضية' (لاحظ أن هذين عنصرين مختلفين)
  4. إذا كان أي من هذه البطاقات موجودة، اختر اسم التوصية المناسب وسترى بطاقات واجهة الشبكة (NICs) لجميع نسخ الماخن الافتراضية/مجموعة مقياس الآلة الافتراضية التي يتم تفعيل الإصدار الافتراضي.

كيف يمكنني مسح هذا التنبيه؟

  1. يجب استخدام طريقة صريحة للخروج لمجموعة مقياس الآلة الافتراضية/الآلة الافتراضية التي تم الإشارة إليها. انظر القسم أعلاه للحصول على خيارات مختلفة.
  2. يجب جعل الشبكة الفرعية خاصة لمنع إنشاء عناوين IP صادرة افتراضية جديدة.
  3. يجب إيقاف أي أجهزة ظاهرية قابلة للتطبيق في الشبكة الفرعية مع العلامة وإلغاء تخصيصها حتى تنعكس التغييرات في المعلمة على مستوى NIC ومسح العلامة. (لاحظ أن هذا صحيح أيضا في الاتجاه المعاكس ؛ من أجل إعطاء الجهاز عنوان IP صادرا افتراضيا بعد تعيين المعلمة على مستوى الشبكة الفرعية إلى خطأ ، يلزم إيقاف / إلغاء تخصيص الجهاز الظاهري.)

أنا أستخدم بالفعل طريقة صريحة للصادر، فلماذا ما زلت أرى هذا التنبيه؟

في بعض الحالات، لا يزال يتم تعيين عنوان IP صادر افتراضي للأجهزة الظاهرية في شبكة فرعية غير خاصة، حتى عند تكوين أسلوب صادر صريح - مثل بوابة NAT أو UDR الذي يوجه نسبة استخدام الشبكة إلى NVA/جدار حماية -. هذا لا يعني أنه يتم استخدام عناوين IP الصادرة الافتراضية للخروج ما لم تتم إزالة هذه الطرق الصريحة. لإزالة عناوين IP الصادرة الافتراضية تماما (وإزالة التنبيه)، يجب جعل الشبكة الفرعية خاصة، ويجب إيقاف الأجهزة الظاهرية وإلغاء تخصيصها.

الأسئلة الشائعة: تغيير السلوك الافتراضي إلى الشبكات الفرعية الخاصة

ماذا يعني جعل الشبكات الفرعية الخاصة افتراضيا ، وكيف سيتم تنفيذه؟

مع إصدار واجهة برمجة التطبيقات الذي تم إصداره بعد 31 مارس 2026، سيتم تعيين الخاصية defaultOutboundAccess للشبكات الفرعية في شبكات VNET الجديدة إلى "false" بشكل افتراضي. يجعل هذا التغيير الشبكات الفرعية خاصة بشكل افتراضي ويمنع إنشاء عناوين IP الصادرة الافتراضية للأجهزة الظاهرية في تلك الشبكات الفرعية. ينطبق هذا السلوك على جميع أساليب التكوين - قوالب ARM ومدخل Microsoft Azure وPowerShell وCLI. ستستمر الإصدارات السابقة من قوالب ARM (أو أدوات مثل Terraform التي يمكنها تحديد الإصدارات القديمة) في تعيين defaultOutboundAccess على أنها فارغة، مما يسمح ضمنيا بالوصول الصادر.

ماذا يحدث لشبكات VNET والأجهزة الظاهرية الحالية؟ ماذا عن الأجهزة الظاهرية الجديدة التي تم إنشاؤها في VNETs الحالية؟

لم يتم إجراء أي تغييرات على شبكات VNET الحالية. هذا يعني أن كلا من الأجهزة الظاهرية الحالية والأجهزة الظاهرية التي تم إنشاؤها حديثا في شبكات VNET هذه تستمر في إنشاء عناوين IP الصادرة الافتراضية ما لم يتم تعديل الشبكات الفرعية يدويا لتصبح خاصة.

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

لا يزال بإمكانك تكوين الشبكات الفرعية على أنها غير خاصة باستخدام أي طريقة مدعومة (قوالب ARM، المدخل، CLI، PowerShell). يضمن ذلك التوافق مع البنى الأساسية التي تعتمد على عناوين IP الصادرة الافتراضية وليست جاهزة بعد للانتقال إلى الشبكات الفرعية الخاصة.

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

لمزيد من المعلومات حول الاتصالات الصادرة في Azure، راجع:

  • Last updated on