Emparejamiento de VNets y puntos de conexión de servicio

Los recursos de distintas VNets de Azure no pueden comunicarse entre sí de forma predeterminada, incluso si se encuentran en la misma región de Azure. Sin embargo, las grandes organizaciones suelen tener varias VNets: VNets independientes para desarrollo, preparación y producción, o VNets distintas para diferentes departamentos. VNet Peering conecta directamente dos VNets a través de la red troncal privada de Microsoft, lo que permite que los recursos de ambas VNets se comuniquen como si estuvieran en la misma red, sin que el tráfico atraviese la Internet pública ni sea necesaria una puerta de enlace VPN.

VNet Peering es una conexión no transitiva: si la VNet A está emparejada con la VNet B, y la VNet B está emparejada con la VNet C, la VNet A no puede comunicarse con la VNet C a menos que cree un emparejamiento independiente entre A y C. Los vínculos de emparejamiento son bidireccionales, pero deben configurarse en ambos lados: crear un emparejamiento de A a B no crea automáticamente otro de B a A. Una vez configurados ambos lados, el tráfico entre las VNets emparejadas utiliza la red troncal de Azure, con baja latencia y gran ancho de banda, comparables a los de la comunicación entre subredes dentro de una sola VNet.

VNet Peering tiene dos opciones de ámbito: Local VNet Peering conecta dos VNets en la misma región de Azure. El tráfico permanece dentro de la región y genera una pequeña tarifa de transferencia por GB. Global VNet Peering conecta dos VNets en distintas regiones de Azure mediante la red troncal global de Microsoft. Esto permite que los recursos de East US se comuniquen de forma privada con recursos de West Europe sin atravesar la internet pública. El peering global tiene un coste de transferencia ligeramente superior al del peering local, pero sigue siendo considerablemente más barato y fiable que enrutar el tráfico mediante una VPN.

Un patrón empresarial habitual utiliza VNet Peering para implementar una topología de hub y spokes. Una VNet de hub central aloja servicios compartidos: Azure Firewall, VPN Gateway, servidores DNS y monitorización. Varias VNets de tipo spoke (una por entorno o carga de trabajo) establecen peering con el hub. Al enrutar todo el tráfico de los spokes a través del firewall del hub, la organización obtiene una inspección de seguridad centralizada sin necesidad de administrar reglas NSG complejas en cada spoke. Como el peering no es transitivo, el firewall del hub enruta el tráfico entre spokes mediante User-Defined Routes (UDRs).

VNet Peering tiene un requisito fundamental: los espacios de direcciones de las VNets con peering no deben solaparse. Si la VNet A usa 10.0.0.0/16 y la VNet B también usa 10.0.0.0/16, el peering falla porque Azure no puede enrutar el tráfico entre rangos de direcciones idénticos. Por eso es tan importante planificar rangos CIDR que no se solapen para todas las VNets —y para las redes locales— antes de comenzar. Cambiar el espacio de direcciones de una VNet después de implementar los recursos requiere volver a crear la VNet o utilizar la funcionalidad (limitada) de adición o eliminación de espacios de direcciones.

Service Endpoints extienden la identidad de la VNet a servicios PaaS de Azure, como Azure Storage, Azure SQL Database, Azure Key Vault y Cosmos DB. Al habilitar un punto de conexión de servicio en una subred, el tráfico de los recursos de esa subred al servicio de Azure especificado se enruta a través de la red troncal de Azure en lugar de la internet pública, aunque se utilice la dirección IP pública del servicio. De este modo, el servicio puede restringir el acceso únicamente a los recursos de las VNets que tengan habilitado el punto de conexión de servicio, lo que proporciona una mejora de seguridad significativa frente a los puntos de conexión accesibles desde internet.

Service Endpoints y Private Endpoints proporcionan acceso seguro a los servicios PaaS de Azure, pero funcionan de forma distinta: Service Endpoint — enruta el tráfico a través de la red troncal de Azure, pero sigue utilizando la dirección IP pública del servicio; el punto de conexión de servicio existe en el nivel de subred. Private Endpoint — asigna al servicio una dirección IP privada de su VNet; el punto de conexión público se puede deshabilitar por completo, lo que hace que el servicio sea realmente privado. Los Private Endpoints proporcionan un aislamiento más sólido y también permiten el acceso desde redes locales mediante VPN/ExpressRoute. Para obtener el máximo nivel de seguridad, se prefieren los Private Endpoints; los Service Endpoints son una alternativa más sencilla y económica.

Después de habilitar un Service Endpoint en una subred, se configura el servicio de Azure para que acepte conexiones únicamente de esa subred. En el caso de una cuenta de almacenamiento, esto implica agregar una regla de VNet en la configuración del firewall de la cuenta de almacenamiento. Después de este cambio, solo las máquinas virtuales de la subred especificada podrán acceder a la cuenta de almacenamiento; se denegará todo el resto del tráfico de internet. Es una forma rápida y gratuita de mejorar considerablemente la seguridad de la cuenta de almacenamiento en comparación con dejarla abierta a todo el tráfico de internet, especialmente en el caso de cuentas que alojan datos confidenciales de aplicaciones.

VNet Integration (distinta de VNet Peering) permite que las aplicaciones de Azure App Service realicen llamadas salientes a recursos dentro de una VNet. Sin VNet Integration, el tráfico saliente de un App Service siempre sale a través de la internet pública, incluso al llamar a recursos como Azure SQL o Azure Cache for Redis en la misma VNet. Con VNet Integration habilitada, el tráfico saliente de la aplicación se enruta hacia la VNet y puede acceder a recursos privados. Esto requiere una subred delegada dedicada en la VNet con un espacio de direcciones de al menos /28.

Como VNet Peering no es transitivo, conectar más de dos VNets requiere establecer peering directo entre cada par (complejidad O(n²)) o utilizar un hub de enrutamiento central. En un modelo de hub y spokes, la VNet del hub contiene un Network Virtual Appliance (NVA) o Azure Firewall que actúa como enrutador de tránsito entre las VNets spoke. Cada spoke agrega una UDR que apunta todo el tráfico (0.0.0.0/0 o los CIDR específicos de los spokes) a la dirección IP de la NVA en el hub. A continuación, la NVA reenvía el tráfico al spoke de destino correcto, proporcionando conectividad transitiva a través del hub.

Principales limitaciones de VNet Peering: se requieren espacios de direcciones que no se solapen: planifique cuidadosamente los rangos CIDR antes de crear las VNets. No es transitivo: establecer peering entre A y B, y entre B y C, no conecta A con C. No se puede cambiar el tamaño del espacio de direcciones de una VNet si tiene peerings activos sin eliminarlos temporalmente. Gateway transit: las VNets spoke pueden utilizar la puerta de enlace VPN o ExpressRoute de la VNet hub si se habilita «Use Remote Gateways» en la configuración del peering, pero para ello primero se debe crear la puerta de enlace del hub. Comprender estas limitaciones es importante para diseñar arquitecturas de varias VNets escalables y fáciles de mantener.

Compruebe su comprensión de los conceptos de Microsoft Azure Fundamentals (AZ-900) tratados en esta lección.

En esta lección ha aprendido que VNet Peering conecta dos VNets a través de la red troncal de Microsoft para ofrecer comunicación privada y de baja latencia sin una VPN, pero el peering no es transitivo; que los puntos de conexión de servicio enrutan el tráfico de la subred a los servicios PaaS de Azure a través de la red troncal sin exponerlo a la internet pública; y que los puntos de conexión privados son una alternativa más segura que asigna una dirección IP privada a un servicio PaaS y permite deshabilitar por completo el punto de conexión público. A continuación, exploraremos los conceptos esenciales de Azure DNS y Load Balancer.