Integración de Private Link y DNS a escala

Artículo
01/30/2025

En este artículo se describe cómo integrar Azure Private Link para soluciones de plataforma como servicio (PaaS) que tienen zonas DNS privadas de Azure en arquitecturas de red en estrella tipo hub-and-spoke.

Introducción

Muchos clientes crean su infraestructura de red en Azure usando la arquitectura de red "hub-and-spoke", donde:

Los servicios compartidos de red, como las aplicaciones virtuales de red (NVA), las puertas de enlace de ExpressRoute/VPN o los servidores DNS, se implementan en la red virtual del centro de .
Las redes virtuales de radio consumen los servicios compartidos a través del emparejamiento de redes virtuales.

En las arquitecturas de red hub-and-spoke, los propietarios de aplicaciones suelen tener una suscripción de Azure, que incluye una red virtual (una radio) que está conectada a la red virtual del concentrador. En esta arquitectura, pueden implementar sus máquinas virtuales y tener conectividad privada a otras redes virtuales o a redes locales a través de ExpressRoute o VPN.

Una aplicación virtual de red central, como Azure Firewall, proporciona conectividad de salida a Internet. Además, ese dispositivo, combinado con otro servicio, como un proxy DNS de Azure Firewall, que se encuentra en el hub o cerca de él, se usa normalmente para personalizar el reenvío de DNS.

Muchos equipos de aplicaciones crean sus soluciones mediante una combinación de recursos IaaS y PaaS de Azure. Algunos servicios PaaS de Azure, como Azure SQL Managed Instance, se pueden implementar en redes virtuales de clientes. Como resultado, el tráfico permanece privado dentro de la red de Azure y es totalmente enrutable desde el entorno local.

Pero algunos servicios PaaS de Azure, como Azure Storage o Azure Cosmos DB, no se pueden implementar en las redes virtuales de un cliente y son accesibles a través de su punto de conexión público. En algunos casos, esta configuración provoca un conflicto con las políticas de seguridad de un cliente. Es posible que el tráfico corporativo no permita la implementación o el acceso de recursos corporativos, como una base de datos SQL, a través de puntos de conexión públicos.

Private Link admite el acceso a una lista de servicios de Azure a través de endpoints privados, pero requiere que registre esos registros de endpoints privados en una zona DNS privada correspondiente.

En este artículo se describe cómo los equipos de aplicaciones pueden implementar servicios PaaS de Azure en sus suscripciones que solo son accesibles a través de puntos de conexión privados.

En este artículo también se describe cómo los equipos de aplicaciones pueden garantizar que los servicios se integren automáticamente con zonas DNS privadas. Realizan la automatización a través de DNS privado de Azure, lo que elimina la necesidad de crear o eliminar manualmente registros en DNS.

Integración de Private Link y DNS en arquitecturas de red hub-and-spoke.

Las zonas DNS privadas normalmente se hospedan de forma centralizada en la misma suscripción de Azure donde se implementa la red virtual del concentrador. Esta práctica de hospedaje central se rige por la resolución de nombres DNS entre sedes y otras necesidades de resolución DNS central, como Windows Server Active Directory. En la mayoría de los casos, solo los administradores de redes e identidades tienen permisos para administrar registros DNS en las zonas.

Los equipos de aplicaciones tienen permisos para crear recursos de Azure en su propia suscripción. No tienen permisos en la suscripción de conectividad de red central, lo que incluye la administración de registros DNS en las zonas DNS privadas. Esta limitación de acceso significa que no tienen la capacidad de crear los registros DNS necesarios al implementar servicios PaaS de Azure con puntos de conexión privados.

En el diagrama siguiente se muestra una arquitectura típica de alto nivel para entornos empresariales con resolución DNS central y resolución de nombres para los recursos de Private Link a través de Dns privado de Azure:

En el diagrama anterior, es importante resaltar lo siguiente:

Los servidores DNS en las instalaciones tienen reenviadores condicionales configurados para cada zona DNS pública del punto de conexión privado, que apuntan al solucionador DNS privado hospedado en el concentrador de la red virtual.
La resolución privada DNS hospedada en la red virtual del centro de conectividad usa el DNS proporcionado por Azure (168.63.129.16) como reenviador.
La red virtual del centro de conectividad debe estar vinculada a los nombres de zona DNS privada para los servicios de Azure, como privatelink.blob.core.windows.net, como se muestra en el diagrama.
Todas las redes virtuales de Azure usan la resolución privada DNS hospedada en la red virtual del centro.
El resolver privado de DNS no es autoritativo para los dominios corporativos del cliente, como los nombres de dominio de Active Directory, porque es solo un reenviador. La resolución privada DNS debe tener reenviadores de puntos de conexión salientes a los dominios corporativos del cliente, que apuntan a los servidores DNS locales (172.16.1.10 y 172.16.1.11) o a los servidores DNS implementados en Azure que son autoritativos para dichas zonas.

Nota

Puede implementar un resolutor privado de DNS en la red virtual hub junto con la puerta de enlace de ExpressRoute. Sin embargo, debe asegurarse de que se permite la resolución de FQDN públicos y que se devuelvan respuestas válidas a través de un conjunto de reglas de reenvío de DNS al servidor DNS de destino. Algunos servicios de Azure dependen de la capacidad de resolver nombres DNS públicos para funcionar. Para obtener más información, consulte Reglas del conjunto de reglas de reenvío de DNS.

Aunque en el diagrama anterior se muestra una única arquitectura de hub-and-spoke, es posible que los clientes necesiten expandir su presencia de Azure a varias regiones para enfrentar los requisitos de resiliencia, proximidad o residencia de datos. En varios escenarios, se debe tener acceso a la misma instancia de PaaS habilitada para Private Link a través de varios puntos de conexión privados.

En el diagrama siguiente se muestra una arquitectura típica de alto nivel para entornos empresariales que tienen una resolución DNS central implementada en el centro (una para cada región) donde la resolución de nombres para los recursos de Private Link se realiza a través de DNS privado de Azure.

Debe implementar varios puntos de conexión privados regionales asociados a la instancia de PaaS, uno en cada región donde existan los clientes. Habilite Private Link y zonas DNS privadas para cada región. Al trabajar con servicios PaaS que tienen funcionalidades de recuperación ante desastres integradas, como cuentas de almacenamiento con redundancia geográfica y grupos de conmutación por error de SQL Database, debe tener puntos de conexión privados en varias regiones.

Este escenario requiere mantenimiento manual y actualizaciones del conjunto de registros DNS de Private Link en cada región porque actualmente no hay ninguna administración automatizada del ciclo de vida para estos.

Para otros casos de uso, se puede implementar un único punto de conexión privado global, lo que hace que sea accesible para todos los clientes agregando enrutamiento desde las regiones pertinentes al punto de conexión privado único en una sola región.

Para habilitar la resolución y, por tanto, la conectividad, desde las redes locales a la zona DNS privada privatelink y a los puntos de conexión privados, configure la configuración de DNS adecuada, como reenviadores condicionales, en la infraestructura DNS.

Dos condiciones que deben cumplirse para que los equipos de aplicaciones creen los recursos de PaaS de Azure necesarios en su suscripción:

Las redes centrales o los equipos de plataforma central deben asegurarse de que los equipos de aplicaciones solo pueden implementar y acceder a los servicios PaaS de Azure a través de puntos de conexión privados.
Las redes centrales o los equipos de plataforma central deben asegurarse de que, al crear puntos de conexión privados, configuren cómo controlar los registros correspondientes. Configure los registros correspondientes para que se creen automáticamente en la zona DNS privada centralizada que coincida con el servicio que se va a crear.
Los registros DNS deben seguir el ciclo de vida del punto de conexión privado para que los registros se quiten automáticamente cuando se elimine el punto de conexión privado.

Nota

En función de la resolución DNS, si necesita FQDN en reglas de red para Azure Firewall y la Directiva de Azure Firewall, habilite el proxy DNS de Azure Firewall para usar FQDN en sus reglas de red. A continuación, las redes virtuales ramificadas deben cambiar su configuración DNS del servidor DNS personalizado al proxy DNS de Azure Firewall. Los FQDN de las reglas de red permiten filtrar el tráfico saliente con cualquier protocolo TCP o UDP, incluidos NTP, SSH y RDP. Cuando cambie la configuración DNS de una red virtual de rama, debe reiniciar todas las VMs dentro de dicha red virtual.

En las secciones siguientes se describe cómo los equipos de aplicaciones habilitan estas condiciones mediante Azure Policy. En el ejemplo se usa Azure Storage como servicio de Azure que los equipos de aplicaciones necesitan implementar. Pero el mismo principio se aplica a la mayoría de los servicios de Azure que admiten Private Link.

Requisitos de configuración del equipo de plataforma

Los requisitos de configuración del equipo de la plataforma incluyen la creación de zonas DNS privadas, la configuración de definiciones de directivas, la implementación de directivas y la configuración de las asignaciones de directivas.

Creación de zonas DNS privadas

Cree zonas DNS privadas en la suscripción de conectividad central para los servicios de Private Link compatibles. Para más información, consulte Configuración de DNS para puntos de conexión privados de Azure.

En este caso, la cuenta de almacenamiento con blob es un ejemplo. Se traduce en la creación de una zona DNS privada privatelink.blob.core.windows.net en la suscripción de conectividad.

Captura de pantalla que muestra la zona DNS privada en la suscripción de conectividad.

Creación de definiciones de directiva

Además de las zonas DNS privadas, también debe crear un conjunto de definiciones de Azure Policy personalizadas. Estas definiciones aplican el uso de puntos de conexión privados y automatizan la creación del registro DNS en la zona DNS que cree:

El punto de conexión público Deny para la política de servicios PaaS.

Esta directiva impide que los usuarios creen servicios PaaS de Azure con puntos de conexión públicos.

Los usuarios reciben un mensaje de error si no seleccionan el punto de conexión privado cuando crean el recurso.

La regla de directiva exacta puede diferir entre los servicios paaS. En el caso de las cuentas de Azure Storage, la propiedad networkAcls.defaultAction define si se permiten o no las solicitudes de redes públicas. En este caso, establezca una condición para denegar la creación del tipo de recurso Microsoft.Storage/storageAccounts si la propiedad networkAcls.defaultAction no es Deny. La siguiente definición de directiva muestra el comportamiento:
```
{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Storage/storageAccounts"
        },
        {
          "field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction",
          "notEquals": "Deny"
        }
      ]
    },
    "then": {
      "effect": "Deny"
    }
  }
}
```
Deny la capacidad de crear una zona DNS privada con la directiva de prefijo privatelink.

Use una arquitectura DNS centralizada con un reenviador condicional y zonas DNS privadas hospedadas en las suscripciones administradas por el equipo de la plataforma. Es necesario evitar que los propietarios de los equipos de aplicación creen sus propias zonas DNS privadas de Private Link y vinculen los servicios a sus suscripciones.

Asegúrese de que cuando el equipo de la aplicación cree un punto de conexión privado, la opción para Integrate with private DNS zone esté establecida en No en Azure Portal.

Si selecciona Yes, Azure Policy le impide crear el punto de conexión privado. En la definición de directiva, se deniega la posibilidad de crear el tipo de recurso Microsoft.Network/privateDnsZones si el prefijo de la zona es privatelink. La siguiente definición de directiva muestra el prefijo 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 directiva para crear automáticamente el registro DNS necesario en la zona DNS privada central.

En los siguientes ejemplos de directiva se muestran dos enfoques para identificar el privateDNSZoneGroup que se crea en un punto de conexión privado.

El primera directiva se basa en el groupId, mientras que la segunda directiva usa tanto el privateLinkServiceId como el groupID. Use la segunda directiva cuando groupId entre en conflicto o colisione con otro recurso.

Por ejemplo, el groupIdSQL se usa tanto para Azure Cosmos DB como para Azure Synapse Analytics. Si se implementan ambos tipos de recursos y se ha asignado la primera directiva para crear el privateDNSZoneGroup en la entrada del punto de conexión privado, se crea y se asigna a la zona DNS privada incorrecta, ya sea de Azure Cosmos DB o de Azure Synapse Analytics. A continuación, podría alternar entre cada una de las zonas debido a la coincidencia groupId que la primera directiva busca en su regla de directiva.

Para obtener una lista de los groupIdrecursos de Private Link, consulte la columna de subrecursos en ¿Qué es un punto de conexión privado?.

Sugerencia

Las definiciones integradas de Azure Policy se agregan, eliminan y actualizan constantemente. Debe usar directivas integradas en lugar de administrar sus propias directivas, cuando estén disponibles. Utilice el AzPolicyAdvertizer para buscar directivas integradas existentes que tengan el siguiente nombre: "xxx ... para usar zonas DNS privadas". Además, Azure Landing Zones (ALZ) tiene una iniciativa de directiva, Configurar servicios PaaS de Azure para usar zonas DNS privadas, que contiene directivas integradas que se actualizan periódicamente. Si una directiva integrada no está disponible para su situación, considere la posibilidad de crear una idea en el azure-policysitio de comentarios Azure Governance Community siguiendo el proceso de propuestas de directivas integradas en el repositorio GitHub de directivas de Azure.

Directiva DeployIfNotExists solo para groupId

Esta directiva se activa si se crea un recurso de punto de conexión privado que tiene un servicio específico groupId. El groupId es el identificador del grupo obtenido del recurso remoto (servicio) al que debe conectarse este punto de conexión privado. A continuación, desencadena una implementación de un privateDNSZoneGroup dentro del punto de conexión privado, que asocia el punto de conexión privado a la zona DNS privada. En el ejemplo, el groupId para blobs de Azure Storage es blob. Para obtener más información sobre el groupId para otros servicios de Azure, consulte la columna Subrecurso en Configuración de DNS de punto de conexión privado de Azure. Cuando la directiva encuentra el groupId en el punto de conexión privado, implementa un privateDNSZoneGroup dentro del punto de conexión privado y lo vincula al identificador de recurso de zona DNS privada que se especifica como parámetro. En el ejemplo, el identificador de recurso de zona DNS privada es:

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

En el ejemplo de código siguiente se muestra la definición de directiva:

{
  "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"
      }
    }
  }
}

Directiva DeployIfNotExists para groupId y privateLinkServiceId

Esta directiva se desencadena si crea un recurso de punto de conexión privado con un servicio específico groupId y privateLinkServiceId. El groupId es el identificador del grupo obtenido del recurso remoto (servicio) al que debe conectarse este punto de conexión privado. El privateLinkServiceId es el identificador de recurso del recurso remoto (servicio) al que debe conectarse este punto de conexión privado. A continuación, desencadene una implementación de un privateDNSZoneGroup dentro del punto de conexión privado, que asocia el punto de conexión privado a la zona DNS privada.

En el ejemplo, el groupId para Azure Cosmos DB (SQL) es SQL y el privateLinkServiceId debe contener Microsoft.DocumentDb/databaseAccounts. Para obtener más información sobre el groupId y el privateLinkServiceId para otros servicios de Azure, consulte la columna Subrecurso en Configuración de DNS de punto de conexión privado de Azure. Cuando la directiva encuentra groupId y privateLinkServiceId en el punto de conexión privado, implementa un privateDNSZoneGroup en el punto de conexión privado. Y está vinculado al identificador de recurso de zona DNS privada que se especifica como parámetro. La siguiente definición de directiva muestra el identificador de recurso de zona DNS privada:

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

En el ejemplo de código siguiente se muestra la definición de directiva:

{
  "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"
     }
  }
}

Asignaciones de directivas

Una vez implementadas las definiciones de directiva, asigne las directivas en el ámbito de la jerarquía del grupo de administración que quiera. Asegúrese de que las asignaciones de directivas tienen como destino las suscripciones de Azure que usan los equipos de aplicaciones para implementar servicios PaaS con acceso de punto de conexión privado exclusivamente.

Importante

Además de asignar la roleDefinition definida en la directiva, asigne el rol Contribuidor de zona DNS privada a la identidad administrada creada por la DeployIfNotExistsasignación de directiva. Este rol debe asignarse en la suscripción y el grupo de recursos donde se hospedan las zonas DNS privadas. La identidad administrada crea y administra el registro DNS del punto de conexión privado en la zona DNS privada. Esta configuración es necesaria porque el punto de conexión privado se encuentra en la suscripción de Azure del propietario de la aplicación, mientras que la zona DNS privada se encuentra en otra suscripción, como una suscripción de conectividad central.

Una vez que el equipo de la plataforma finalice la configuración:

Las suscripciones de Azure de los equipos de aplicaciones están listas para que el equipo cree servicios PaaS de Azure que tengan acceso exclusivo al punto de conexión privado.
El equipo debe asegurarse de que los registros DNS de los puntos de conexión privados se registran automáticamente en las zonas DNS privadas correspondientes y que los registros DNS se quitan después de eliminar un punto de conexión privado.

El propietario de la aplicación implementa un servicio PaaS de Azure

Después de que el equipo de la plataforma implemente los componentes de infraestructura de la plataforma (zonas y directivas DNS privadas), el propietario de la aplicación realiza los pasos siguientes al intentar implementar un servicio PaaS de Azure en la suscripción de Azure. Estos pasos son los mismos si realizan sus actividades a través de Azure Portal u otros clientes, como PowerShell o la CLI, ya que las directivas de Azure rigen sus suscripciones.

Cree una cuenta de almacenamiento a través de Azure Portal. En la pestaña Aspectos básicos, seleccione la configuración que quiera, proporcione un nombre para la cuenta de almacenamiento y seleccione Siguiente.
En la pestaña Redes, seleccione punto de conexión privado. Si selecciona una opción que no sea Punto de conexión privado, Azure Portal no permite crear la cuenta de almacenamiento en la sección Revisar y creardel asistente para la implementación. La directiva impide que cree este servicio si el punto de conexión público está habilitado.
Es posible crear el punto de conexión privado ahora o después de crear la cuenta de almacenamiento. En este ejemplo se muestra cómo crear el punto de conexión privado después de crear la cuenta de almacenamiento. Seleccione Revisar y crear para completar el paso.
Después de crear la cuenta de almacenamiento, realice un punto de conexión privado a través de Azure Portal.
En la sección Recurso, localice la cuenta de almacenamiento que creó en el paso anterior. En Subrecurso de destino, seleccione Blob y, a continuación, Siguiente.
En la sección Configuración, después de seleccionar la red virtual y la subred, asegúrese de que la opción Integrar con la zona DNS privada esté establecida en No. De lo contrario, Azure Portal impide que cree el punto de conexión privado. Azure Policy no le permitirá crear una zona DNS privada con el prefijo privatelink.
Seleccione Revisar y creary, a continuación, seleccione Crear para implementar el punto de conexión privado.
Después de unos minutos, la directiva DeployIfNotExists se desencadena. La implementación de dnsZoneGroup posterior agrega los registros DNS necesarios para el punto de conexión privado en la zona DNS administrada centralmente.
Después de crear el punto de conexión privado, selecciónelo y revise su FQDN y su dirección IP privada:
Compruebe el registro de actividad del grupo de recursos donde se creó el punto de conexión privado. También puede comprobar el registro de actividad del propio punto de conexión privado. Después de unos minutos, se ejecuta una acción de directiva DeployIfNotExist, que configura el grupo de zonas DNS en el punto de conexión privado:
Si el equipo de red central va a la privatelink.blob.core.windows.net zona DNS privada, confirma que el registro DNS está ahí para el punto de conexión privado que ha creado y el nombre y la dirección IP coinciden con los valores dentro del punto de conexión privado.

En este punto, los equipos de aplicaciones pueden usar la cuenta de almacenamiento a través de un punto de conexión privado desde cualquier red virtual en el entorno de red de spoke-and-hub y desde el entorno local. El registro DNS se ha registrado automáticamente en la zona DNS privada.

Si un propietario de la aplicación elimina el punto de conexión privado, los registros correspondientes de la zona DNS privada se quitan automáticamente.