Integración de red

Artículo
07/12/2023

En este artículo se describe la integración de red de Azure Stack para el centro de datos modular de Azure.

Conectividad de borde (vínculo superior)

El planeamiento de la integración de red es un requisito previo importante para la correcta implementación, operación y administración de sistemas integrados de Azure Stack. El planeamiento de la conectividad de borde comienza con la elección de si se debe usar el enrutamiento dinámico con el Protocolo de puerta de enlace de borde (BGP) o el enrutamiento estático. El enrutamiento dinámico requiere que se asigne un número de sistema autónomo BGP de 16 bits (público o privado). El enrutamiento estático utiliza una ruta predeterminada estática que se asigna a los dispositivos de borde.

Los conmutadores perimetrales requieren vínculos superiores de capa 3 con direcciones IP punto a punto (redes /30) configuradas en las interfaces físicas. No se admite el uso de vínculos superiores de capa 2 con conmutadores perimetrales que admiten operaciones de Azure Stack.

Enrutamiento BGP

El uso de un protocolo de enrutamiento dinámico, como BGP, garantiza que el sistema siempre sea consciente de los cambios de red y facilita su administración. A fin de mejorar la seguridad, se puede establecer una contraseña en el emparejamiento BGP entre los dispositivos perimetral y de borde.

Como se muestra en el siguiente diagrama, la publicidad del espacio IP privado en el conmutador de la parte superior del bastidor (TOR) se bloquea mediante una lista de prefijos. La lista de prefijos deniega la publicidad de la red privada y se aplica como un mapa de ruta en la conexión entre los dispositivos perimetral y de borde.

El equilibrador de carga de software (SLB) que se ejecuta dentro de los niveles de la solución de Azure Stack se empareja con los dispositivos TOR para que pueda anunciar dinámicamente las direcciones VIP.

Para asegurarse de que el tráfico de usuario se recupera del error de forma transparente e inmediata, la nube privada virtual o la agregación de vínculos de chasis múltiples (MLAG) configuradas entre los dispositivos de TOR permiten el uso de MLAG a los hosts y HSRP o VRRP, que proporciona redundancia de red para las redes IP.

Enrutamiento estático

El enrutamiento estático requiere una configuración adicional para los dispositivos de borde. Requiere más intervención y administración manual, así como un análisis exhaustivo antes de realizar cualquier cambio. Los problemas causados por un error de configuración pueden tardar más tiempo en revertirse según los cambios realizados. No se recomienda este método de enrutamiento, pero sí se admite.

Para integrar Azure Stack en su entorno de red con enrutamiento estático, los cuatro vínculos físicos entre los dispositivos perimetral y de borde deben estar conectados. No se puede garantizar la alta disponibilidad debido a cómo funciona el enrutamiento estático.

El dispositivo de borde debe configurarse con rutas estáticas que apunten a cada una de las cuatro direcciones IP punto a punto establecidas entre los dispositivos perimetral y de borde para el tráfico destinado a cualquier red en Azure Stack. Sin embargo, solo se requiere la red VIP externa o pública para su funcionamiento. Para la implementación inicial, se necesitan rutas estáticas a las redes BMC y externa. Los operadores pueden optar por dejar las rutas estáticas en el borde para acceder a los recursos de administración que residen en la red BMC y de infraestructura. Es opcional agregar rutas estáticas a la red de infraestructura de conmutadores y de administración de conmutadores.

Los dispositivos de Tor están configurados con una ruta estática predeterminada que envía todo el tráfico a los dispositivos de borde. La única excepción de tráfico a la regla predeterminada se da en el espacio privado, que se bloquea con una lista de control de acceso aplicada en la conexión de TOR a borde.

El enrutamiento estático solo se aplica a los vínculos superiores entre los conmutadores perimetral y de borde. El enrutamiento dinámico BGP se usa en el bastidor porque es una herramienta esencial para SLB y otros componentes, y no se puede deshabilitar ni quitar.

* La red BMC es opcional después de la implementación.

** La red de la infraestructura de conmutadores es opcional, ya que se puede incluir toda la red en la red de administración de conmutadores.

*** La red de administración de conmutadores es necesaria y se puede agregar por separado desde la red de la infraestructura de conmutadores.

Proxy transparente

Si el centro de datos requiere que todo el tráfico utilice un proxy, debe configurar un proxy transparente para procesar todo el tráfico del bastidor y tratarlo de acuerdo con la directiva. Debe separar el tráfico entre las zonas de la red.

La solución Azure Stack no es compatible con servidores proxy web normales.

Un proxy transparente (también conocido como proxy interceptor, alineado o forzado) intercepta la comunicación normal en la capa de red sin requerir ninguna configuración especial del cliente. Los clientes no necesitan estar enterados de la existencia del proxy.

No se admite la interceptación de tráfico SSL y ello puede provocar errores de servicio cuando se accede a los puntos de conexión. El tiempo de expiración máximo admitido para comunicarse con los puntos de conexión necesarios para la identidad es de 60 segundos con tres reintentos.

DNS

En esta sección se trata la configuración del Sistema de nombres de dominio (DNS).

Configure el reenvío condicional de DNS

Esta guía solo se aplica a una implementación de Servicios de federación de Active Directory (AD FS).

Para habilitar la resolución de nombres con la infraestructura DNS existente, configure el reenvío condicional.

Para agregar un reenviador condicional, debe utilizar el punto de conexión con privilegios.

Para este procedimiento, use un equipo de la red del centro de datos que pueda comunicarse con el punto de conexión con privilegios de Azure Stack.

Abra una sesión de Windows PowerShell con privilegios elevados (ejecución como administrador). Conéctese a la dirección IP del punto de conexión con privilegios. Use las credenciales para la autenticación de CloudAdmin.
```
\$cred=Get-Credential Enter-PSSession -ComputerName \<IP Address of ERCS\> -ConfigurationName PrivilegedEndpoint -Credential \$cred 
```
Después de conectarse al punto de conexión con privilegios, ejecute el siguiente comando de PowerShell. Sustituya los valores de ejemplo proporcionados por su nombre de dominio y direcciones IP de los servidores DNS que quiere usar.
```
Register-CustomDnsServer -CustomDomainName "contoso.com" -CustomDnsIPAddresses "192.168.1.1","192.168.1.2" 
```

Resolución de nombres DNS de Azure Stack desde fuera de Azure Stack

Los servidores autoritativos son los que contienen la información de zona DNS externa y las zonas creadas por el usuario. Realice la integración con estos servidores para habilitar la delegación de zona o el reenvío condicional para resolver nombres DNS de Azure Stack desde fuera de Azure Stack.

Obtener información del punto de conexión externo del servidor DNS

Para integrar la implementación de Azure Stack con la infraestructura DNS, necesitará la información siguiente:

Nombres de dominio completos del servidor DNS (FQDN)
Direcciones IP del servidor DNS

Los FQDN de los servidores DNS de Azure Stack tienen el formato siguiente:

<NAMINGPREFIX>-ns01.<REGION>.<EXTERNALDOMAINNAME>
<NAMINGPREFIX>-ns02.<REGION>.<EXTERNALDOMAINNAME>

Con los valores de ejemplo, los FQDN de los servidores DNS son los siguientes:

azs-ns01.east.cloud.fabrikam.com
azs-ns02.east.cloud.fabrikam.com

Esta información está disponible en el portal de administración, pero también se crea al finalizar todas las implementaciones de Azure Stack en un archivo denominado AzureStackStampInformation.json. Este archivo se encuentra en la carpeta C:\CloudDeployment\logs de la máquina virtual de implementación. Si no está seguro de qué valores se han usado para la implementación de Azure Stack, puede obtener los valores desde aquí.

Si la máquina virtual de implementación ya no está disponible o no es accesible, puede obtener los valores si se conecta al punto de conexión con privilegios y ejecuta el cmdlet Get-AzureStackStampInformation de PowerShell. Para más información, consulte Punto de conexión con privilegios.

Configuración del reenvío condicional a Azure Stack

La manera más sencilla y segura de integrar Azure Stack con la infraestructura de DNS es hacer un reenvío condicional de la zona desde el servidor que hospeda la zona principal. Recomendamos este enfoque si tiene el control directo de los servidores DNS que hospedan la zona principal del espacio de nombres DNS externo de Azure Stack.

Si no está familiarizado con el proceso de reenvío condicional con DNS, vea el artículo de TechNet titulado "Asignación de un reenviador condicional para un nombre de dominio" o la documentación específica de la solución DNS.

Si ha especificado que la zona DNS externa de Azure Stack debe parecer un dominio secundario de su nombre de dominio corporativo, no se puede usar el reenvío condicional. Se debe configurar la delegación DNS.

Ejemplo:

Nombre de dominio DNS corporativo: contoso.com
Nombre de dominio DNS externo de Azure Stack: azurestack.contoso.com

Edición de direcciones IP del reenviador DNS

Las direcciones IP del reenviador DNS se establecen durante la implementación de Azure Stack. Si las direcciones IP del reenviador deben actualizarse por algún motivo, puede conectarse al punto de conexión con privilegios y ejecutar los cmdlets de PowerShell Get-AzSDnsForwarder y Set-AzSDnsForwarder [[-IPAddress] <IPAddress[]>] para modificar los valores. Para más información, consulte Punto de conexión con privilegios.

Delegación de la zona DNS externa en Azure Stack

Para que los nombres DNS puedan resolverse desde fuera de una implementación de Azure Stack, debe configurar la delegación de DNS.

Cada registrador dispone de sus propias herramientas de administración de DNS para cambiar los registros de servidores de nombres de un dominio. En la página de administración de DNS del registrador, edite los registros NS y reemplace los registros NS de la zona por los de Azure Stack.

La mayoría de los registradores DNS requieren que se proporcione un mínimo de dos servidores DNS para completar la delegación.

Firewall

Azure Stack configura direcciones IP virtuales (VIP) para sus roles de infraestructura. Estas VIP se asignan desde el grupo de direcciones IP públicas. Cada VIP está protegida con una lista de control de acceso (ACL) en el nivel de red definido por software. Las ACL también se usan en los conmutadores físicos (Tor y BMC) para proteger aún más la solución. Se crea una entrada DNS para cada punto de conexión de la zona DNS externa que se haya especificado durante la implementación. Por ejemplo, el portal de usuarios se asigna a la entrada de host de DNS de portal.<región>.<fqdn>.

En el siguiente diagrama de arquitectura se muestran las diferentes capas de red y ACL.

En el diagrama de arquitectura se muestran las diferentes capas de red y ACL.

Puertos y direcciones URL

Para que los servicios de Azure Stack (como los portales, Azure Resource Manager y DNS) estén disponibles para las redes externas, debe permitir tráfico entrante en estos puntos de conexión para las direcciones URL, los puertos y los protocolos específicos.

En una implementación en la que un proxy transparente establece un vínculo superior a un servidor proxy tradicional o un firewall protege la solución, debe permitir puertos y direcciones URL concretos para la comunicación entrante y saliente. Entre los ejemplos se incluyen puertos y direcciones URL de identidad, Marketplace de Azure Stack Hub, revisiones y actualizaciones y datos de uso.

Comunicación saliente

Azure Stack solo admite servidores proxy transparentes. En una implementación en la que un proxy transparente establece un vínculo superior a un servidor proxy tradicional, debe permitir los puertos y las direcciones URL de la tabla siguiente para la comunicación saliente al realizar la implementación en el modo conectado.

Nota:

Azure Stack no admite el uso de Azure ExpressRoute para acceder a los servicios de Azure que se enumeran en la tabla siguiente porque es posible que ExpressRoute no pueda enrutar el tráfico a todos los puntos de conexión.

Fin	Dirección URL de destino	Protocolo	Puertos	Red de origen
Identidad	Azure login.windows.net login.microsoftonline.com graph.windows.net https://secure.aadcdn.microsoftonline-p.com www.office.com ManagementServiceUri = https://management.core.windows.net ARMUri = https://management.azure.com https://.msftauth.net https://.msauth.net https://.msocdn.com Azure Government* https://login.microsoftonline.us/ https://graph.windows.net/ Azure China 21Vianet https://login.chinacloudapi.cn/ https://graph.chinacloudapi.cn/ Azure Alemania https://login.microsoftonline.de/ https://graph.cloudapi.de/	HTTP HTTPS	80 443	VIP pública - /27 Red de la infraestructura pública
Redifusión de Marketplace de Azure Stack Hub	Azure https://management.azure.com https://.blob.core.windows.net https://.azureedge.net Azure Government https://management.usgovcloudapi.net/ https://.blob.core.usgovcloudapi.net/ Azure China 21Vianet* https://management.chinacloudapi.cn/ http://*.blob.core.chinacloudapi.cn	HTTPS	443	VIP pública - /27
Revisiones y actualizaciones	https://*.azureedge.net https://aka.ms/azurestackautomaticupdate	HTTPS	443	VIP pública - /27
Registro	Azure https://management.azure.com Azure Government https://management.usgovcloudapi.net/ Azure China 21Vianet https://management.chinacloudapi.cn	HTTPS	443	VIP pública - /27
Uso	Azure https://.trafficmanager.net Azure Government* https://.usgovtrafficmanager.net Azure China 21Vianet* https://*.trafficmanager.cn	HTTPS	443	VIP pública - /27
Windows Defender	.wdcp.microsoft.com .wdcpalt.microsoft.com .wd.microsoft.com .update.microsoft.com download.Microsoft.com https://www.microsoft.com/pkiops/crl https://www.microsoft.com/pkiops/certs https://crl.microsoft.com/pki/crl/products https://www.microsoft.com/pki/certs https://secure.aadcdn.microsoftonline-p.com	HTTPS	80 443	VIP pública - /27 Red de la infraestructura pública
NTP	Se proporciona la dirección IP del servidor NTP para la implementación.	UDP	123	VIP pública - /27
DNS	Se proporciona la dirección IP del servidor DNS para la implementación.	TCP UDP	53	VIP pública - /27
CRL	Dirección URL de los puntos de distribución de CRL del certificado	HTTP	80	VIP pública - /27
LDAP	Bosque de Active Directory proporcionado para la integración con Azure Graph	TCP UDP	389	VIP pública - /27
SSL de LDAP	Bosque de Active Directory proporcionado para la integración con Graph	TCP	636	VIP pública - /27
GC DE LDAP	Bosque de Active Directory proporcionado para la integración con Graph	TCP	3268	VIP pública - /27
SSL de GC de LDAP	Bosque de Active Directory proporcionado para la integración con Graph	TCP	3269	VIP pública - /27
AD FS	Punto de conexión de metadatos de AD FS proporcionado para la integración con AD FS	TCP	443	VIP pública - /27
Servicio de recopilación de registros de diagnóstico	URL de firma de acceso compartido que proporciona Azure Blob Storage	HTTPS	443	VIP pública - /27

Comunicación entrante

Se requiere un conjunto de direcciones IP virtuales de infraestructura para publicar los puntos de conexión de Azure Stack en redes externas. La tabla Punto de conexión (VIP) se muestra cada punto de conexión, el puerto requerido y el protocolo. En el caso de los puntos de conexión que requieren proveedores de recursos adicionales, como el proveedor de recursos de SQL, consulte la documentación de implementación del proveedor de recursos específica.

Las VIP de infraestructura interna no se indican porque no son necesarias para la publicación de Azure Stack. Las VIP de usuario son dinámicas y están definidas por los propios usuarios, sin ningún control por parte del operador de Azure Stack.