Integración de Private Link y DNS a gran escala

Artículo
10/25/2023

En este artículo se describe cómo integrar Azure Private Link para los servicios de PaaS con zonas de DNS privado de Azure en las arquitecturas de red en estrella tipo hub-and-spoke.

Introducción

Muchos clientes crean su infraestructura de red en Azure con la arquitectura de red en estrella tipo hub-and-spoke, donde:

Los servicios compartidos de redes (como las aplicaciones virtuales de red, las puertas de enlace de ExpressRoute o de VPN, o los servidores DNS) se implementan en la red virtual (VNet) del centro de conectividad.
Spoke Las redes virtuales consumen los servicios compartidos mediante el emparejamiento de VNet.

En las arquitecturas de red en estrella tipo hub-and-spoke, se suele proporcionar a los propietarios de la aplicación una suscripción a Azure, que incluye una red virtual (radio) conectada a la red virtual de concentrador. En esta arquitectura, pueden implementar sus máquinas virtuales y tener conectividad privada con otras redes virtuales o con redes locales mediante ExpressRoute o VPN.

Una aplicación virtual de red central (NVA), como Azure Firewall, proporciona conectividad saliente a Internet.

Muchos equipos de aplicaciones crean sus soluciones mediante una combinación de recursos de IaaS y PaaS de Azure. Algunos servicios de PaaS de Azure (como SQL Managed Instance) se pueden implementar en redes virtuales de cliente. Como resultado, el tráfico sigue siendo privado en la red de Azure y se puede enrutar completamente desde el entorno local.

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

Azure Private Link admite el acceso a una lista de servicios de Azure mediante puntos de conexión privados, pero requiere que esos registros de puntos de conexión privados estén registrados 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, a las que solo se puede acceder mediante 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 las zonas DNS privadas. Realizan la automatización a través de DNS privado de Azure, de manera que se elimina la necesidad de crear o eliminar manualmente registros en DNS.

Integración de Private Link y DNS en las arquitecturas de red en estrella tipo hub-and-spoke

Las zonas de DNS privadas se suelen hospedar de manera centralizada en la misma suscripción a Azure en que se implementa la red virtual del centro de conectividad. Esta práctica de hospedaje central se rige por la resolución de nombres DNS entre entornos locales y otras necesidades de resolución de DNS central, como Active Directory. En la mayoría de los casos, solo los administradores de redes o 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, que incluye la administración de registros DNS en las zonas DNS privadas. Esta limitación de acceso significa que no tienen la capadidad de crear los registros DNS necesarios para implementar los servicios PaaS de Azure con puntos de conexión privados.

En el diagrama siguiente se muestra una arquitectura de alto nivel típica para entornos empresariales con resolución de DNS central y donde la resolución de nombres para los recursos de Private Link se realiza mediante el DNS privado de Azure:

A diagram of a high-level architecture with central DNS resolution and name resolution for Private Link resources.

En relación con el diagrama anterior, es importante destacar que:

Los servidores DNS locales tienen reenviadores condicionales configurados para cada zona DNS pública de punto de conexión privado que apuntan al solucionador DNS privado hospedado en la red virtual del concentrador.
El solucionador DNS privado hospedado en la red virtual del concentrador usa un DNS proporcionado por Azure (168.63.129.16) como reenviador.
La red virtual del centro de conectividad debe estar vinculada a los nombres de zonas DNS privadas para los servicios de Azure (por ejemplo, privatelink.blob.core.windows.net, tal y como se muestra en el diagrama).
Todas las redes virtuales de Azure usan el solucionador DNS privado hospedado en la red virtual del concentrador
Dado que el solucionador DNS privado no es autoritativo para los dominios corporativos del cliente, ya que es solo un reenviador (por ejemplo, nombres de dominio de Active Directory), debe tener reenviadores de punto de conexión de salida a los dominios corporativos del cliente, que apunten 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.

Mientras que el diagrama anterior muestra una única arquitectura de grupo radial, los clientes pueden necesitar ampliar su superficie de Azure a través de múltiples regiones para abordar los requisitos de resistencia, proximidad o residencia de datos, han surgido varios escenarios en los que se debe acceder a la misma instancia de PaaS habilitada para Private-Link a través de múltiples puntos de conexión privados (PE).

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

Se recomienda implementar varios puntos de conexión privados regionales asociados a la instancia de PaaS, uno en cada región en la que existen clientes, habilitar Private Link por región y zonas DNS privadas. Al trabajar con servicios PaaS con funcionalidades de recuperación ante desastres integradas (cuentas de almacenamiento con redundancia geográfica, grupos de conmutación por error de SQL DB, etc.), son obligatorios varios puntos de conexión privados de región.

Este escenario requiere el mantenimiento/actualización manual del conjunto de registros DNS de Private Link en cada región, ya que actualmente no existe una administración automatizada del ciclo de vida de los mismos.

Para otros casos de uso, se puede implementar un único punto de conexión privado global, lo que permite que todos los clientes puedan acceder mediante la adición de enrutamiento desde las regiones pertinentes al único punto de conexión privado 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, es necesario establecer la configuración DNS adecuada (reenviadores condicionales, etc.) en la infraestructura DNS.

Existen dos condiciones que deben cumplirse para permitir que los equipos de aplicaciones creen los recursos PaaS de Azure necesarios en la suscripción:

El equipo de la plataforma central o redes centrales debe garantizar que los equipos de aplicaciones solo puedan implementar los servicios PaaS de Azure y acceder a ellos mediante puntos de conexión privados.
Las redes centrales o los equipos de la plataforma central deben asegurarse de que, cuando crean puntos de conexión privados, configuran cómo se controlan los registros correspondientes. Configure los registros correspondientes de manera 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, en ese caso, se quita automáticamente cuando se elimina el punto de conexión privado.

Nota:

si es necesario usar los nombres de dominio completo en las reglas de red basadas en la resolución DNS en Azure Firewall y directiva de firewall (esta funcionalidad permite filtrar el tráfico saliente con cualquier protocolo TCP/UDP, incluidos NTP, SSH, RDP y mucho más). Debe habilitar el proxy de DNS de Azure Firewall para usar los nombres de dominio completo en las reglas de red. Al hacerlo, esas redes virtuales de radio se ven obligadas a cambiar su configuración de DNS del servidor DNS personalizado al proxy de DNS de Azure Firewall. El cambio de la configuración DNS de una red virtual de radio requiere el reinicio de todas las máquinas virtuales dentro de esa 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 el servicio de Azure que los equipos de aplicaciones necesitan implementar. Pero se aplica el mismo principio a la mayoría de los servicios de Azure que admiten Private Link.

Configuración que necesita el equipo de la plataforma

Entre los requisitos de configuración del equipo de la plataforma se incluyen la creación de las 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 que se admiten. Para obtener más información, vea Configuración de DNS para puntos de conexión privados de Azure.

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

A screenshot that shows the private DNS zone in the connectivity subscription.

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:

Deny el punto de conexión público para la directiva de servicios de PaaS.

Esta directiva impide que los usuarios creen servicios PaaS de Azure con puntos de conexión públicos y hace que les aparezca un mensaje de error si no seleccionan el punto de conexión privado al crear el recurso.

Es posible que la regla de directiva exacta difiera entre servicios PaaS. En el caso de las cuentas de Azure Storage, consulte la propiedad networkAcls.defaultAction, que define si se permiten o no las solicitudes de la red pública. 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.

Puede usar una arquitectura DNS centralizada con un reenviador condicional y zonas DNS privadas que se hospedan en las suscripciones que administra el equipo de la plataforma. Es necesario impedir que los propietarios de los equipos de aplicaciones creen sus propias zonas DNS privadas de Private Link y vinculen 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 se establezca en No en Azure Portal.

Si selecciona Yes, Azure Policy impide crear el punto de conexión privado. En la definición de directiva, deniega la capacidad de crear el tipo de recurso Microsoft.Network/privateDnsZones si la zona tiene el prefijo 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"
    }
  }
}
```
Directiva DeployIfNotExists 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.

La primera directiva se basa en groupId, mientras que la segunda directiva usa privateLinkServiceId y groupID. Puede usar la segunda directiva cuando groupId entre en conflicto (colisione) con otro recurso.

Por ejemplo, groupIdSQL se usa para Cosmos DB y Synapse Analytics. Si se implementan ambos tipos de recursos y se ha asignado la primera directiva para crear privateDNSZoneGroup en la entrada Punto de conexión privado, se crea y se asigna a la zona DNS privada incorrecta, ya sea de Cosmos DB o Synapse Analytics. A continuación, puede alternar entre cada una de las zonas debido al conflicto groupId, que la primera directiva busca en la regla de directiva.

Para obtener una lista de recursos groupId 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. Se recomienda encarecidamente usar directivas integradas en lugar de administrar sus propias directivas (siempre que estén disponibles). Puede usar AzPolicyAdvertizer para buscar las directivas integradas existentes que tengan el siguiente nombre de "xxx ... para usar zonas DNS privadas". Además, las zonas de aterrizaje de Azure (ALZ) tienen una iniciativa de directiva, Configuración de servicios PaaS de Azure para usar zonas DNS privadas, que contiene directivas integradas y actualizadas periódicamente. Si una directiva integrada no está disponible para su situación, considere la posibilidad de crear un problema en el sitio de comentarios azure-policyAzure Governance · Community siguiendo el proceso Nuevas propuestas de directivas integradas en el repositorio de GitHub de Azure Policy.

Primera directiva `DeployIfNotExists`: coincidencia solo en `groupId`

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

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

En el siguiente ejemplo de código 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"
      }
    }
  }
}

Segunda directiva `DeployIfNotExists`: coincidencia en `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. groupId es el identificador del grupo obtenido del recurso remoto (servicio) al que se debe conectar este punto de conexión privado. privateLinkServiceId es el id. de grupo del recurso remoto (servicio) al que se debe conectar este punto de conexión privado. A continuación, se desencadena una implementación de privateDNSZoneGroup en el punto de conexión privado, que asocia el punto de conexión privado con la zona DNS privada.

En el ejemplo, groupId para Azure Cosmos DB (SQL) es SQL y privateLinkServiceId debe contener Microsoft.DocumentDb/databaseAccounts. Para obtener más información sobre groupId y privateLinkServiceId para otros servicios de Azure, consulte Configuración de DNS del punto de conexión privado de Azure, en la columna Subrecurso. 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 id. de recurso de zona DNS privada que se especifica como el parámetro. La siguiente definición de directiva muestra el id. de recurso de zona DNS privada:

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

En el siguiente ejemplo de código 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. Garantice que las asignaciones de la directiva tengan como destino las suscripciones de Azure que usarán los equipos de aplicaciones para implementar servicios PaaS con acceso exclusivo de punto de conexión privado.

Importante

Además de asignar la definición de rol que aparece en la directiva, recuerde asignar el rol de colaborador de zona DNS privada en la suscripción y el grupo de recursos donde estén hospedadas las zonas DNS privadas a la identidad administrada creada por la asignación de directiva DeployIfNotExists que será responsable de crear y administrar el registro DNS del punto de conexión privado en la zona DNS privada. Esto se debe a que 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 una suscripción diferente (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 con acceso exclusivo de 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 (y se quitan una vez eliminado un punto de conexión privado) de las zonas DNS privadas correspondientes.

Experiencia del propietario de la aplicación

Después de que el equipo de la plataforma implemente los componentes de infraestructura de la plataforma (directivas y zonas DNS privadas), el propietario de la aplicación tiene la siguiente experiencia al intentar implementar un servicio PaaS de Azure en la suscripción de Azure. Esta experiencia es la misma ya sea que realicen las actividades a través de Azure Portal o de otros clientes, como PowerShell o la CLI, ya que las directivas de Azure rigen sus suscripciones.

Cree una cuenta de almacenamiento desde 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 Conexión en red, 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 crear 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 la creación del punto de conexión privado una vez se ha creado la cuenta de almacenamiento. Seleccione Revisar y crear para completar el paso.
Una vez creada la cuenta de almacenamiento, cree un punto de conexión privado a través Azure Portal.
En la sección Recurso, busque la cuenta de almacenamiento que ha creado 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 crear el punto de conexión privado. Azure Policy no permite crear una zona DNS privada con el prefijo privatelink.
Seleccione Revisar y crear y, después, seleccione Crear para implementar el punto de conexión privado.
Después de unos minutos, la directiva DeployIfNotExists se desencadena. A continuación, la implementación dnsZoneGroup posterior agrega los registros DNS necesarios para el punto de conexión privado en la zona DNS administrada centralmente.
Una vez creado el punto de conexión privado, selecciónelo y revise su FQDN y dirección IP privada:
Consulte el registro de actividad del grupo de recursos donde se creó el punto de conexión privado. O bien puede comprobar el registro de actividad del punto de conexión privado. Observará que, después de unos minutos, se ejecuta una acción de directiva DeployIfNotExist, que configura el grupo de zona DNS en el punto de conexión privado:
Si el equipo de redes central va a la zona DNS privada privatelink.blob.core.windows.net, confirmará que se ha creado el registro DNS para el punto de conexión privado y que el nombre y la dirección IP coinciden con los valores 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 el propietario de una aplicación elimina el punto de conexión privado, se quitarán automáticamente los registros correspondientes de la zona DNS privada.

Pasos siguientes

Consulte DNS para recursos locales y de Azure. Consulte Plan para el acceso remoto a máquinas virtuales.

Importante

En este artículo se describe la integración de DNS y Private Link a gran escala mediante directivas DINE (DeployIfNotExists) que se asignan al grupo de administración. Esto significa que no es necesario controlar la integración de DNS en el código cuando se crean puntos de conexión privados con este enfoque, ya que las directivas lo controlan. También es poco probable que los equipos de aplicaciones tengan acceso RBAC a las zonas de DNS privadas centralizadas.

A continuación se muestran vínculos que resulta útil consultar cuando se crea un punto de conexión privado con Bicep y HashiCorp Terraform.

En el caso de la creación de puntos de conexión privados con infraestructura como código:

Inicio rápido: Creación de un punto de conexión privado mediante Bicep.

Cree un punto de conexión privado con HashiCorp Terraform azurerm_private_endpoint en Terrafrom Registry.

No obstante, puede crear puntos de conexión privados en las herramientas de infraestructura como código. Sin embargo, si usa el enfoque de directiva DINE como se describe en este artículo, debe dejar fuera del código la integración de DNS y dejar que las directivas de DINE que tengan el RBAC necesario para las zonas DNS privadas lo controlen en su lugar.

Integración de Private Link y DNS a gran escala

Introducción

Integración de Private Link y DNS en las arquitecturas de red en estrella tipo hub-and-spoke