التكامل بين Private Link وDNS على نطاق واسع

مقالة
04/28/2023

توضح هذه المقالة كيفية دمج Azure Private Link لخدمات PaaS مع مناطق Azure Private DNS في بنيات الشبكة المحورية.

مقدمة

يقوم العديد من العملاء بإنشاء البنية الأساسية للشبكة في Azure باستخدام بنية الشبكة المحورية والمركز، حيث:

يتم نشر الخدمات المشتركة للشبكات (مثل الأجهزة الظاهرية للشبكة أو بوابات ExpressRoute/VPN أو خوادم DNS) في الشبكة الظاهرية المركزية (VNet).
تكلم تستهلك الشبكات الظاهرية الخدمات المشتركة عن طريق نظير الشبكة الظاهرية.

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

يوفر الجهاز الظاهري للشبكة المركزية (NVA)، مثل Azure Firewall، اتصالا صادرا عن الإنترنت.

تقوم العديد من فرق التطبيقات بإنشاء حلولها باستخدام مجموعة من موارد Azure IaaS وPaaS. يمكن نشر بعض خدمات Azure PaaS (مثل SQL Managed Instance) في الشبكات الظاهرية للعميل. ونتيجة لذلك، تظل نسبة استخدام الشبكة خاصة داخل شبكة Azure وهي قابلة للتوجيه بالكامل من أماكن العمل.

ولكن لا يمكن نشر بعض خدمات Azure PaaS (مثل Azure Storage أو Azure Cosmos DB) في الشبكات الظاهرية للعميل ويمكن الوصول إليها عبر نقطة النهاية العامة الخاصة بهم. في بعض الحالات، يتسبب هذا التكوين في خلاف مع نهج أمان العميل. قد لا تسمح حركة مرور الشركة بنشر موارد الشركة أو الوصول إليها (مثل قاعدة بيانات SQL) عبر نقاط النهاية العامة.

يدعم Azure Private Link الوصول إلى قائمة بخدمات Azure عبر نقاط النهاية الخاصة، ولكنه يتطلب تسجيل سجلات نقطة النهاية الخاصة هذه في منطقة DNS خاصة مقابلة.

توضح هذه المقالة كيف يمكن لفرق التطبيقات نشر خدمات Azure PaaS في اشتراكاتها التي يمكن الوصول إليها فقط عبر نقاط النهاية الخاصة.

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

تكامل Private Link وDNS في بنيات الشبكة المحورية

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

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

يظهر الرسم التخطيطي التالي بنية عالية المستوى نموذجية لبيئات المؤسسة مع دقة DNS المركزية وحيث يتم تحليل الاسم لموارد Private Link عبر Azure DNS الخاص:

رسم تخطيطي لبنية عالية المستوى بدقة DNS مركزية وتحليل الاسم لموارد Private Link.

من الرسم التخطيطي السابق، من المهم تمييز ما يلي:

تحتوي خوادم DNS المحلية على معيدات توجيه شرطية تم تكوينها لكل منطقة DNS عامة لنقطة النهاية الخاصة، تشير إلى خوادم 10.100.2.4 DNS ومستضافة 10.100.2.5 في الشبكة الظاهرية للمركز.
تستخدم خوادم 10.100.2.4 DNS والمستضافة 10.100.2.5 في الشبكة الظاهرية للمركز محلل DNS المقدم من Azure (168.63.129.16) كمرسل توجيه.
يجب ربط الشبكة الظاهرية للمركز بأسماء منطقة DNS الخاصة لخدمات Azure (مثل privatelink.blob.core.windows.net، كما هو موضح في الرسم التخطيطي).
تستخدم جميع شبكات Azure الظاهرية خوادم DNS المستضافة في الشبكة الظاهرية المركزية (10.100.2.4 و 10.100.2.5) كخوادم DNS الأساسية والثانوية.
إذا كانت خوادم 10.100.2.410.100.2.5 DNS وغير موثوقة لمجالات شركة العميل (على سبيل المثال، أسماء مجالات Active Directory)، فيجب أن يكون لديها معيدات توجيه شرطية لمجالات الشركة الخاصة بالعميل، مشيرا إلى خوادم DNS المحلية (172.16.1.10 و 172.16.1.11) أو خوادم DNS المنشورة في Azure والمخولة لمثل هذه المناطق.

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

هناك شرطان يجب أن يكونا صحيحين لفرق التطبيق لإنشاء أي موارد Azure PaaS مطلوبة في اشتراكهم:

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

ملاحظة

إذا كانت FQDNs في قواعد الشبكة المستندة إلى دقة DNS مطلوبة لاستخدامها في Azure Firewall ونهج جدار الحماية (تسمح لك هذه الإمكانية بتصفية نسبة استخدام الشبكة الصادرة باستخدام أي بروتوكول TCP/UDP -بما في ذلك NTP وSSH وRDP والمزيد-). يجب تمكين وكيل DNS لجدار حماية Azure لاستخدام FQDNs في قواعد الشبكة الخاصة بك، ثم يتم إجبار تلك الشبكات الظاهرية المحورية على تغيير إعداد DNS الخاص بها من خادم DNS المخصص إلى وكيل DNS لجدار حماية Azure. يتطلب تغيير إعدادات DNS للشبكة الظاهرية المحورية إعادة تشغيل جميع الأجهزة الظاهرية داخل تلك الشبكة الظاهرية.

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

التكوين المطلوب من قبل فريق النظام الأساسي

تتضمن متطلبات تكوين فريق النظام الأساسي إنشاء مناطق DNS الخاصة، وإعداد تعريفات النهج، ونشر النهج، وإعداد تعيينات النهج.

إنشاء مناطق خاصة بنظام أسماء المجالات

إنشاء مناطق DNS خاصة في اشتراك الاتصال المركزي لخدمات Private Link المدعومة. لمزيد من المعلومات حول هذه الإعدادات، راجع تكوين نظام أسماء النطاقات لنقطة نهاية خاصة في Azure

في هذه الحالة، حساب التخزين مع كائن ثنائي كبير الحجم هو المثال. يترجم إلى إنشاء privatelink.blob.core.windows.net منطقة DNS خاصة في اشتراك الاتصال.

لقطة شاشة تعرض منطقة DNS الخاصة في اشتراك الاتصال.

تعريفات السياسة

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

Deny نقطة النهاية العامة لنهج خدمات PaaS.

يمنع هذا النهج المستخدمين من إنشاء خدمات Azure PaaS مع نقاط النهاية العامة ويعطيهم رسالة خطأ إذا لم يحددوا نقطة النهاية الخاصة عند إنشاء المورد.

قد تختلف قاعدة النهج الدقيقة بين خدمات PaaS. بالنسبة لحسابات Azure Storage، انظر إلى الخاصية networkAcls.defaultAction التي تحدد ما إذا كانت الطلبات من الشبكات العامة مسموحا بها أم لا. في هذه الحالة، قم بتعيين شرط لرفض إنشاء نوع مورد Microsoft.Storage/storageAccounts إذا لم تكن Denyالخاصية networkAcls.defaultAction . يوضح تعريف النهج التالي السلوك:
```
{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Storage/storageAccounts"
        },
        {
          "field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction",
          "notEquals": "Deny"
        }
      ]
    },
    "then": {
      "effect": "Deny"
    }
  }
}
```
Deny القدرة على إنشاء منطقة DNS خاصة باستخدام نهج البادئة privatelink .

استخدم بنية DNS مركزية مع معيد توجيه شرطي ومناطق DNS خاصة مستضافة في الاشتراكات التي يديرها فريق النظام الأساسي. من الضروري منع مالكي فرق التطبيقات من إنشاء مناطق DNS الخاصة ب Private Link وربط الخدمات باشتراكاتهم.

تأكد من أنه عندما يقوم فريق التطبيق الخاص بك بإنشاء نقطة نهاية خاصة، يتم تعيين الخيار إلى Integrate with private DNS zoneNo في مدخل Microsoft Azure.

إذا قمت بتحديد Yes، فإن Azure Policy يمنعك من إنشاء نقطة النهاية الخاصة. في تعريف النهج، يرفض القدرة على إنشاء نوع مورد Microsoft.Network/privateDnsZones إذا كانت المنطقة تحتوي على البادئة privatelink . يعرض تعريف النهج التالي البادئة privatelink :
```
{
  "description": "This policy restricts creation of private DNS zones with the `privatelink` prefix",
  "displayName": "Deny-PrivateDNSZone-PrivateLink",
  "mode": "All",
  "parameters": null,
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Network/privateDnsZones"
        },
        {
          "field": "name",
          "contains": "privatelink."
        }
      ]
    },
    "then": {
      "effect": "Deny"
    }
  }
}
```
DeployIfNotExists نهج لإنشاء سجل DNS المطلوب تلقائيا في منطقة DNS الخاصة المركزية.

تظهر أمثلة النهج التالية طريقتين لتحديد الذي privateDNSZoneGroup تم إنشاؤه على نقطة نهاية خاصة.

يعتمد النهج الأول على groupId بينما يستخدم النهج الثاني كلا من privateLinkServiceId و groupID. استخدم النهج الثاني عندما groupId سيتصادم (تصادم) مع مورد آخر.

على سبيل المثال، groupId يتم استخدام SQL لكل من Cosmos DB وSynapse Analytics. إذا تم نشر كلا النوعين من الموارد وتم تعيين النهج الأول لإنشاء privateDNSZoneGroup على إدخال نقطة النهاية الخاصة، يتم إنشاؤه وتعيينه إلى منطقة DNS الخاصة غير الصحيحة، إما من Cosmos DB أو Synapse Analytics. ثم قد يتم التبديل بين كل منطقة من المناطق بسبب التصادم groupId الذي تبحث عنه السياسة الأولى في قاعدة سياستها.

للحصول على قائمة بموارد groupIdالارتباط الخاص، راجع عمود الموارد الفرعية في ما هي نقطة النهاية الخاصة؟.

تلميح

تتم باستمرار إضافة التعريفات المضمنة في نهج Azure وحذفها وتحديثها. يوصى بشدة باستخدام النهج المضمنة مقابل إدارة النهج الخاصة بك (عند توفرها). استخدم AzPolicyAdvertizer للعثور على النهج المضمنة الموجودة التي لها الاسم التالي ل 'xxx ... لاستخدام مناطق DNS الخاصة'. بالإضافة إلى ذلك، لدى مناطق هبوط Azure (ALZ) مبادرة نهج، تكوين خدمات Azure PaaS لاستخدام مناطق DNS الخاصة، والتي تحتوي على نهج مضمنة أيضا وتحديثها بشكل دوري. إذا لم يكن النهج المضمن متوفرا لموقفك، ففكر في إنشاء مشكلة على موقع الملاحظات azure-policyAzure Governance · يتبع المجتمع عملية مقترحات النهج المضمنة الجديدة على مستودع Azure Policy GitHub.

النهج الأول `DeployIfNotExists` - المطابقة في `groupId` فقط

يتم تشغيل هذا النهج إذا قمت بإنشاء مورد نقطة نهاية خاصة باستخدام خدمة خاصة groupId. groupId هو معرف المجموعة التي تم الحصول عليها من المورد البعيد (الخدمة) الذي يجب أن تتصل به نقطة النهاية الخاصة هذه. ثم يقوم بتشغيل نشر privateDNSZoneGroup داخل نقطة النهاية الخاصة، والتي تربط نقطة النهاية الخاصة بمنطقة DNS الخاصة. في المثال، groupId ل Azure Storage blobs هو blob. لمزيد من المعلومات حول groupId خدمات Azure الأخرى، راجع تكوين Azure Private Endpoint DNS، ضمن عمود Subresource . عندما يعثر النهج على groupId في نقطة النهاية الخاصة، فإنه ينشر privateDNSZoneGroup داخل نقطة النهاية الخاصة، ويربطه بمعرف مورد منطقة DNS الخاص المحدد كمعلمة. في المثال، معرف مورد منطقة DNS الخاص هو:

/subscriptions/<subscription-id>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/privateDnsZones/privatelink.blob.core.windows.net

يوضح نموذج التعليمات البرمجية التالي تعريف النهج:

{
  "mode": "Indexed",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Network/privateEndpoints"
        },
        {
          "count": {
            "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].groupIds[*]",
            "where": {
              "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].groupIds[*]",
              "equals": "blob"
            }
          },
          "greaterOrEquals": 1
        }
      ]
    },
    "then": {
      "effect": "deployIfNotExists",
      "details": {
        "type": "Microsoft.Network/privateEndpoints/privateDnsZoneGroups",
        "roleDefinitionIds": [
          "/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7"
        ],           
        "deployment": {
          "properties": {
            "mode": "incremental",
            "template": {
              "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
              "contentVersion": "1.0.0.0",
              "parameters": {
                "privateDnsZoneId": {
                  "type": "string"
                },
                "privateEndpointName": {
                  "type": "string"
                },
                "location": {
                  "type": "string"
                }
              },
              "resources": [
                {
                  "name": "[concat(parameters('privateEndpointName'), '/deployedByPolicy')]",
                  "type": "Microsoft.Network/privateEndpoints/privateDnsZoneGroups",
                  "apiVersion": "2020-03-01",
                  "location": "[parameters('location')]",
                  "properties": {
                    "privateDnsZoneConfigs": [
                      {
                        "name": "storageBlob-privateDnsZone",
                        "properties": {
                          "privateDnsZoneId": "[parameters('privateDnsZoneId')]"
                        }
                      }
                    ]
                  }
                }
              ]
            },
            "parameters": {
              "privateDnsZoneId": {
                "value": "[parameters('privateDnsZoneId')]"
              },
              "privateEndpointName": {
                "value": "[field('name')]"
              },
              "location": {
                "value": "[field('location')]"
              }
            }
          }
        }
      }
    }
  },
  "parameters": {
    "privateDnsZoneId": {
      "type": "String",
      "metadata": {
        "displayName": "privateDnsZoneId",
        "strongType": "Microsoft.Network/privateDnsZones"
      }
    }
  }
}

النهج الثاني `DeployIfNotExists` - المطابقة في `groupId`&`privateLinkServiceId`

يتم تشغيل هذا النهج إذا قمت بإنشاء مورد نقطة نهاية خاصة مع خدمة خاصة groupId و privateLinkServiceId. groupId هو معرف المجموعة التي تم الحصول عليها من المورد البعيد (الخدمة) الذي يجب أن تتصل به نقطة النهاية الخاصة هذه. privateLinkServiceId هو معرف المورد للمورد البعيد (الخدمة) الذي يجب أن تتصل به نقطة النهاية الخاصة هذه. ثم قم بتشغيل نشر داخل privateDNSZoneGroup نقطة النهاية الخاصة، والتي تربط نقطة النهاية الخاصة بمنطقة DNS الخاصة.

في المثال، groupId ل Azure Cosmos DB (SQL) هو SQL ويجب أن يحتوي على privateLinkServiceIdMicrosoft.DocumentDb/databaseAccounts. لمزيد من المعلومات حول groupId و privateLinkServiceId لخدمات Azure الأخرى، راجع تكوين Azure Private Endpoint DNS، ضمن عمود Subresource . عندما يعثر groupId النهج على وفي privateLinkServiceId نقطة النهاية الخاصة، فإنه ينشر privateDNSZoneGroup داخل نقطة النهاية الخاصة. وهو مرتبط بمعرف مورد منطقة DNS الخاص الذي تم تحديده كمعلمة. يعرض تعريف النهج التالي معرف مورد منطقة DNS الخاص:

/subscriptions/<subscription-id>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/privateDnsZones/privatelink.documents.azure.com

يوضح نموذج التعليمات البرمجية التالي تعريف النهج:

{
  "mode": "Indexed",
  "policyRule": {
    "if": {
     "allOf": [
       {
         "field": "type",
         "equals": "Microsoft.Network/privateEndpoints"
       },
       {
         "count": {
           "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*]",
           "where": {
             "allOf": [
               {
                 "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].privateLinkServiceId",
                 "contains": "Microsoft.DocumentDb/databaseAccounts"
               },
               {
                 "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].groupIds[*]",
                 "equals": "[parameters('privateEndpointGroupId')]"
               }
             ]
           }
         },
         "greaterOrEquals": 1
       }
     ]
   },
    "then": {
      "effect": "[parameters('effect')]",
      "details": {
        "type": "Microsoft.Network/privateEndpoints/privateDnsZoneGroups",
        "roleDefinitionIds": [
          "/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7"
        ],           
        "deployment": {
          "properties": {
            "mode": "incremental",
            "template": {
              "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
              "contentVersion": "1.0.0.0",
              "parameters": {
                "privateDnsZoneId": {
                  "type": "string"
                },
                "privateEndpointName": {
                  "type": "string"
                },
                "location": {
                  "type": "string"
                }
              },
              "resources": [
                {
                  "name": "[concat(parameters('privateEndpointName'), '/deployedByPolicy')]",
                  "type": "Microsoft.Network/privateEndpoints/privateDnsZoneGroups",
                  "apiVersion": "2020-03-01",
                  "location": "[parameters('location')]",
                  "properties": {
                    "privateDnsZoneConfigs": [
                      {
                        "name": "cosmosDB-privateDnsZone",
                        "properties": {
                          "privateDnsZoneId": "[parameters('privateDnsZoneId')]"
                        }
                      }
                    ]
                  }
                }
              ]
            },
            "parameters": {
              "privateDnsZoneId": {
                "value": "[parameters('privateDnsZoneId')]"
              },
              "privateEndpointName": {
                "value": "[field('name')]"
              },
              "location": {
                "value": "[field('location')]"
              }
            }
          }
        }
      }
    }
  },
  "parameters": {
     "privateDnsZoneId": {
       "type": "String",
       "metadata": {
         "displayName": "Private Dns Zone Id",
         "description": "The private DNS zone to deploy in a new private DNS zone group and link to the private endpoint",
         "strongType": "Microsoft.Network/privateDnsZones"
       }
     },
     "privateEndpointGroupId": {
       "type": "String",
       "metadata": {
         "displayName": "Private Endpoint Group Id",
         "description": "A group Id for the private endpoint"
       }
     },
     "effect": {
       "type": "String",
       "metadata": {
         "displayName": "Effect",
         "description": "Enable or disable the execution of the policy"
       },
       "allowedValues": [
         "DeployIfNotExists",
         "Disabled"
       ],
       "defaultValue": "DeployIfNotExists"
     }
  }
}

تعيينات النهج

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

هام

بالإضافة إلى تعيين roleDefinition المحدد في النهج، تذكر تعيين دور مساهم منطقة DNS الخاصة في الاشتراك ومجموعة الموارد حيث تتم استضافة مناطق DNS الخاصة إلى الهوية المدارة التي تم إنشاؤها بواسطة DeployIfNotExists تعيين النهج الذي سيكون مسؤولا عن إنشاء سجل DNS لنقطة النهاية الخاصة وإدارته في منطقة DNS الخاصة. وذلك لأن نقطة النهاية الخاصة موجودة في اشتراك Azure لمالك التطبيق، بينما توجد منطقة DNS الخاصة في اشتراك مختلف (مثل اشتراك الاتصال المركزي).

بعد انتهاء فريق النظام الأساسي من التكوين:

اشتراكات Azure الخاصة بفرق التطبيقات جاهزة للفريق بعد ذلك لإنشاء خدمات Azure PaaS مع الوصول إلى نقطة النهاية الخاصة حصريا.
يجب على الفريق التأكد من تسجيل سجلات DNS لنقاط النهاية الخاصة تلقائيا (وإزالتها بمجرد حذف نقطة نهاية خاصة) من مناطق DNS الخاصة المقابلة.

تجربة مالك التطبيق

بعد أن ينشر فريق النظام الأساسي مكونات البنية الأساسية للنظام الأساسي (مناطق DNS الخاصة والنهج)، يتمتع مالك التطبيق بالتجربة التالية عند محاولة توزيع خدمة Azure PaaS في اشتراك Azure. هذه التجربة هي نفسها سواء كانوا يقومون بنشاطاتهم من خلال مدخل Microsoft Azure أو عملاء آخرين، مثل PowerShell أو CLI، نظرا لأن نهج Azure تحكم اشتراكاتهم.

إنشاء حساب تخزين من خلال مدخل Microsoft Azure. في علامة التبويب الأساسيات ، اختر الإعدادات التي تريدها، وقم بتوفير اسم لحساب التخزين الخاص بك، وحدد التالي.
في علامة التبويب networking، حدد Private endpoint. إذا حددت خيارا آخر غير نقطة النهاية الخاصة، فلن يسمح لك مدخل Microsoft Azure بإنشاء حساب التخزين في قسم Review + create في معالج التوزيع. يمنعك النهج من إنشاء هذه الخدمة إذا تم تمكين نقطة النهاية العامة.
من الممكن إنشاء نقطة النهاية الخاصة الآن أو بعد إنشاء حساب التخزين. يوضح هذا المثال إنشاء نقطة النهاية الخاصة بعد إنشاء حساب التخزين. حدد Review + create لإكمال الخطوة.
بعد إنشاء حساب التخزين، قم بإنشاء نقطة نهاية خاصة من خلال مدخل Microsoft Azure.
في قسم Resource ، حدد موقع حساب التخزين الذي أنشأته في الخطوة السابقة. ضمن المورد الفرعي الهدف، حدد Blob، ثم حدد Next.
في قسم التكوين ، بعد تحديد الشبكة الظاهرية والشبكة الفرعية، تأكد من تعيين التكامل مع منطقة DNS الخاصة إلى لا. وإلا، فإن مدخل Microsoft Azure يمنعك من إنشاء نقطة النهاية الخاصة. لن يسمح لك نهج Azure بإنشاء منطقة DNS خاصة بالبادئة privatelink .
حدد Review + create، ثم حدد Create لنشر نقطة النهاية الخاصة.
بعد بضع دقائق، يتم تشغيل النهج DeployIfNotExists . ثم يضيف التوزيع اللاحق dnsZoneGroup سجلات DNS المطلوبة لنقطة النهاية الخاصة في منطقة DNS المدارة مركزيا.
بعد إنشاء نقطة النهاية الخاصة، حددها، وراجع FQDN وIP الخاص بها:
تحقق من سجل النشاط لمجموعة الموارد حيث تم إنشاء نقطة النهاية الخاصة. أو يمكنك التحقق من سجل النشاط لنقطة النهاية الخاصة نفسها. ستلاحظ أنه بعد بضع دقائق، يتم تشغيل إجراء نهج DeployIfNotExist وتكوين مجموعة منطقة DNS على نقطة النهاية الخاصة:
إذا ذهب فريق الشبكات المركزية إلى privatelink.blob.core.windows.net منطقة DNS الخاصة، فسيؤكدون أن سجل DNS موجود لنقطة النهاية الخاصة التي أنشأتها، وأن كلا من الاسم وعنوان IP يتطابقان مع القيم داخل نقطة النهاية الخاصة.

في هذه المرحلة، يمكن لفرق التطبيقات استخدام حساب التخزين من خلال نقطة نهاية خاصة من أي شبكة ظاهرية في بيئة شبكة المركز والمتحدث ومن أماكن العمل. تم تسجيل سجل DNS تلقائيا في منطقة DNS الخاصة.

إذا قام مالك التطبيق بحذف نقطة النهاية الخاصة، تتم إزالة السجلات المقابلة في منطقة DNS الخاصة تلقائيا.

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

راجع DNS للموارد المحلية وموارد Azure. مراجعة الخطة للوصول عن بعد للجهاز الظاهري.

هام

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

فيما يلي ارتباطات مفيدة للمراجعة عند إنشاء نقطة نهاية خاصة باستخدام Bicep و HashiCorp Terraform.

لإنشاء نقطة نهاية خاصة باستخدام البنية الأساسية كتعلم برمجي:

التشغيل السريع إنشاء نقطة نهاية خاصة باستخدام Bicep.

إنشاء نقطة نهاية خاصة باستخدام HashiCorp Terraform azurerm_private_endpoint في سجل Terrafrom.

ومع ذلك، لا يزال بإمكانك إنشاء نقاط نهاية خاصة في أدوات البنية الأساسية كتعلم برمجي، إذا كان استخدام نهج DINE كما هو موضح في هذه المقالة يجب ترك جانب تكامل DNS خارج التعليمات البرمجية الخاصة بك والسماح لنهج DINE التي تحتوي على RBAC المطلوبة لمناطق DNS الخاصة بمعالجة هذا بدلا من ذلك.