Evitar el agotamiento de IPv4 en Azure

Las redes corporativas suelen usar espacios de direcciones de los intervalos de direcciones IPv4 privados definidos por Request for Comments (RFC) 1918, como 10.0.0.0/8, 172.16.0.0/12y 192.168.0.0/16. En entornos locales, estos intervalos proporcionan suficientes direcciones IP para satisfacer los requisitos de incluso las redes más grandes. Como resultado, muchas organizaciones desarrollan prácticas de administración de direcciones que priorizan las configuraciones de enrutamiento simples y los procesos ágiles para la asignación de direcciones IP. A menudo no priorizan el uso eficaz del espacio de direcciones IPv4.

En la nube, las redes grandes son fáciles de construir. Algunos patrones de arquitectura comunes, como microservicios o contenedorización, pueden dar lugar a un mayor consumo de direcciones IPv4. Por lo tanto, es importante adoptar prácticas de administración de direcciones más conservadoras y tratar las direcciones IPv4 como un recurso limitado.

Nota:

Se recomienda usar los bloques de direcciones definidos por RFC 1918 en las redes virtuales de Azure. Para obtener más información, consulte Intervalos de direcciones para redes virtuales.

En este artículo se describen dos métodos para minimizar el consumo de espacio de direcciones IPv4 al crear redes grandes en Azure. Los métodos se basan en topologías de red que reutilizan los mismos bloques de direcciones IPv4 en varias redes virtuales o zonas de aterrizaje.

• Método 1: Utilice el emparejamiento de subred IPv4 para excluir una o varias subredes del emparejamiento entre la red virtual de la zona de aterrizaje y la red virtual del concentrador. Puede asignar los mismos intervalos de direcciones IP no enrutables a las subredes excluidas del emparejamiento en todas las zonas de aterrizaje. Estos intervalos de direcciones IP no se pueden superponer con otros intervalos de direcciones IP enrutables.

• Método 2: Implemente aplicaciones en redes virtuales aisladas que no están conectadas a las redes virtuales de las zonas de aterrizaje. Asocie sus puntos de conexión a los servicios de Azure Private Link. En las redes virtuales radiales de las zonas de aterrizaje, cree puntos de conexión privados asociados a los servicios de vínculo privado. Las redes virtuales aisladas pueden usar cualquier espacio de direcciones IPv4, incluso si se superpone con el espacio de direcciones enrutable de la red corporativa.

El método 1 funciona mejor en entornos empresariales tradicionales en los que varios sistemas y aplicaciones dependen entre sí. El método 2 funciona mejor en entornos acoplados flexiblemente en los que las aplicaciones funcionan de forma independiente.

Alineación de la zona de aterrizaje de Azure

Las recomendaciones de este artículo se aplican a las topologías de red basadas en la arquitectura de la zona de aterrizaje de Azure:

• Cada región que hospeda recursos de Azure tiene una red de topología hub-and-spoke.

• Las redes en estrella tipo hub-and-spoke de diferentes regiones se conectan a través del emparejamiento de red virtual global.

• Las redes hub-and-spoke se conectan a sitios locales a través de circuitos de Azure ExpressRoute o VPN de sitio a sitio.

En la arquitectura de la zona de aterrizaje Azure, cada aplicación se ejecuta en su propia red virtual. Cada red virtual usa un espacio único de direcciones IPv4 en toda la red corporativa.

Todos los recursos de una zona de aterrizaje pueden conectarse de las maneras siguientes:

• Use su dirección IP para iniciar conexiones a cualquier otro recurso de la red corporativa.

• Recepción de conexiones directas desde toda la red corporativa a través de su dirección IP

Sin embargo, los recursos no siempre necesitan accesibilidad desde toda la red corporativa. Por ejemplo, en una zona de aterrizaje que contiene una aplicación web de tres niveles, como un front-end HTTP, una lógica de negocios y una capa de datos, solo se debe acceder al front-end HTTP desde fuera de la zona de aterrizaje. Las demás capas deben conectarse entre sí y con el front-end, pero no necesitan aceptar conexiones de clientes. En este ejemplo se sugiere que puede minimizar el consumo de direcciones IPv4 asignando los siguientes componentes a cada zona de aterrizaje:

• Un espacio de direcciones que es único en toda la red corporativa. Solo los recursos que deben ser accesibles desde fuera de su zona de aterrizaje usan este espacio de direcciones. Este artículo se refiere a este espacio de direcciones como el espacio de direcciones enrutables de la zona de aterrizaje.

• Un espacio de direcciones interno para los recursos que solo necesitan comunicarse con otros recursos dentro de su propia zona de aterrizaje. Este espacio de direcciones no requiere accesibilidad directa desde la red corporativa. En este artículo se hace referencia a este espacio de direcciones como el espacio de direcciones no enrutable de la zona de aterrizaje.

En las secciones siguientes, el componente front-end hace referencia a un componente de aplicación que debe ser accesible desde toda la red corporativa. El componente back-end hace referencia a un componente de aplicación que no expone puntos de conexión en la red corporativa y solo debe ser accesible dentro de su propia zona de aterrizaje.

Método 1: Subredes no enrutables en redes virtuales de nube

Puede usar el emparejamiento de subred IPv4 para restringir el emparejamiento entre dos redes virtuales a subredes específicas. Solo las subredes incluidas en la configuración de emparejamiento pueden enrutar el tráfico entre sí. Las subredes excluidas de la configuración de emparejamiento permanecen invisibles e inaccesibles de la red virtual del mismo nivel.

En una topología hub-and-spoke, si excluye una o varias subredes de cada ramal de la configuración de emparejamiento, esas subredes permanecen invisibles e inaccesibles desde el hub ni desde ninguna red remota conectada al hub a través de otros emparejamientos, conexiones ExpressRoute o conexiones VPN. Por lo tanto, se puede asignar el mismo intervalo de direcciones a todas las subredes excluidas de la configuración de emparejamiento en todas las redes virtuales. Ese intervalo debe definirse como noroutale y no se puede usar en ningún otro lugar de la red corporativa.

En el diagrama siguiente se incluyen estos componentes:

• El intervalo 10.57.0.0/16 actúa como espacio de direcciones no enrutado.

• La red virtual del concentrador y cada red virtual del subproyecto de zona de aterrizaje usan intervalos de direcciones IP enrutables únicos (10.0.0.0/24, 10.1.0.0/24, y 10.2.0.0/24).

• Cada red virtual de zona de aterrizaje también contiene una o varias subredes no enrutables dentro del rango no enrutable 10.57.0.0/16. El espacio de direcciones de una red virtual de Azure puede incluir varios intervalos de direcciones IP.

• Estas subredes quedan excluidas de la relación de emparejamiento con el concentrador. Por lo tanto, las subredes no enrutables en diferentes ramales de la zona de aterrizaje pueden tener bien los mismos rangos de direcciones, o bien rangos de direcciones superpuestos dentro de 10.57.0.0/16.

Este diagrama presenta un concentrador y dos ramales de zona de aterrizaje en zonas de aterrizaje independientes. El centro contiene tres subredes enrutables. Cada ramal de zona de aterrizaje contiene dos subredes enrutables y dos subredes no enrutables. El concentrador está conectado a cada zona de aterrizaje a través de la interconexión de subredes. Solo quedan incluidas en el emparejamiento las subredes enrutables del concentrador y los ramales.

Descargue un archivo de PowerPoint de esta arquitectura.

Este enfoque garantiza la total conectividad dentro de la red virtual de una zona de aterrizaje. Todos los recursos de la misma red virtual radial pueden conectarse entre sí, independientemente de si residen en subredes enrutables o no enrutables. Sin embargo, solo los recursos de subredes enrutables pueden conectarse a recursos fuera de su propia zona de aterrizaje.

Implementación de aplicaciones en zonas de aterrizaje

Al usar el emparejamiento de subred para crear zonas de aterrizaje con subredes no enrutables, puede aplicar diferentes patrones para distribuir los componentes front-end y back-end de una aplicación entre subredes enrutables y no enrutables. Las siguientes consideraciones se aplican tanto a las aplicaciones recién compiladas como a las aplicaciones migradas desde zonas de aterrizaje tradicionales que usan un único espacio de direcciones enrutable.

• Aplicaciones expuestas a través de controladores de entrega de aplicaciones de capa 7: Estos controladores de entrega de aplicaciones incluyen Azure Application Gateway o aplicaciones virtuales de red (NVA) que no son de Microsoft. Solo el punto de conexión del controlador de entrega de aplicaciones debe ser accesible desde clientes fuera de la zona de aterrizaje. Por lo tanto, el controlador de entrega de aplicaciones es el único componente front-end que debe residir en una subred enrutable.

• Aplicaciones expuestas a través de un equilibrador de carga de Azure: Si la aplicación usa un equilibrador de carga interno de Azure, las máquinas virtuales del grupo de back-end del equilibrador de carga deben residir en una subred enrutable. Puede implementar todos los demás componentes en subredes no enrutables.

En el diagrama siguiente se muestran estos patrones:

• Zona de aterrizaje A hospeda una aplicación web de tres niveles expuesta a través de un controlador de entrega de aplicaciones, que es el único componente de la subred enrutable.

• La zona de aterrizaje B hospeda una aplicación de tres niveles expuesta a través de un equilibrador de carga interno de Azure.

Este diagrama presenta un concentrador y dos ramales de zona de aterrizaje en zonas de aterrizaje independientes. El centro contiene tres subredes enrutables. El ramal de la zona de aterrizaje A contiene un controlador de entrega de aplicaciones dentro de una subred enrutable, y un frontend HTTP, la lógica empresarial y la capa de datos dentro de subredes no enrutables independientes. El ramal de la zona de aterrizaje B contiene un front-end TCP/IP dentro de una subred enrutable y la lógica de negocios y una capa de datos dentro de subredes no enrutables independientes. El concentrador está conectado a las subredes enrutables de cada ramal a través del emparejamiento de subredes.

Descargue un archivo de PowerPoint de esta arquitectura.

Dependencias de salida

Los componentes de back-end de una aplicación no necesitan recibir conexiones entrantes de la red corporativa. Pero es posible que necesiten iniciar conexiones a puntos de conexión fuera de su zona de aterrizaje. Entre los ejemplos típicos se incluyen la resolución del sistema de nombres de dominio (DNS), la interacción con controladores de dominio de Active Directory Domain Services (AD DS) y el acceso a aplicaciones de otras zonas de aterrizaje o servicios compartidos, como la administración de registros o los sistemas de copia de seguridad.

Cuando los recursos de subredes no enrutadas necesitan iniciar conexiones a puntos de conexión fuera de su zona de aterrizaje, esas conexiones deben usar NAT de origen (SNAT) detrás de una dirección IP enrutable. Por lo tanto, debe implementar una NVA compatible con NAT en una subred enrutable en cada zona de aterrizaje. El diagrama siguiente muestra esta configuración.

Este diagrama presenta un concentrador y dos ramales de zona de aterrizaje en zonas de aterrizaje independientes. El centro contiene tres subredes enrutables. El ramal de la zona de aterrizaje A contiene un controlador de distribución de aplicaciones y la NAT en subredes enrutables independientes. También contiene un front-end HTTP, una lógica de negocios y un nivel de datos en subredes no enrutables independientes. El controlador de distribución de aplicaciones apunta a tres componentes de la subred del front-end HTTP. La conexión de un componente pasa por el firewall del centro a través de SNAT. El ramal de la zona de aterrizaje B contiene un front end TCP/IP y NAT en subredes enrutables independientes. También contiene lógica de negocios y un nivel de datos en subredes no enrutables independientes. La conexión de un componente de la subred de lógica empresarial pasa por el firewall del hub a través de SNAT. El concentrador está conectado a cada ramal de zona de aterrizaje.

Descargue un archivo de PowerPoint de esta arquitectura.

Las subredes no enrutables deben usar una tabla de rutas personalizada que reenvía todo el tráfico destinado fuera de la zona de aterrizaje a la NVA compatible con NAT. En el diagrama anterior, el 10.57.0.0/16 intervalo no es enrutable, mientras que otros intervalos dentro de 10.0.0.0/8 son enrutables. La tabla de rutas personalizada para cada subred no enrutada debe contener la siguiente ruta definida por el usuario (UDR).

Destino	Tipo del próximo salto	Dirección IP de siguiente salto
10.0.0.0/8	VirtualNetworkAppliance	<Dirección IP NVA de ramal compatible con NAT>

La tabla de rutas del sistema de la red virtual ya incluye una ruta del sistema para destinos en el rango no enrutable 10.57.0.0/16. No es necesario definir UDR para el tráfico dentro de ese intervalo.

Las subredes enrutables, incluida la subred que hospeda la NVA compatible con NAT, deben usar una tabla de rutas personalizada que reenvía el tráfico fuera de la zona de aterrizaje, normalmente a NVA en la red virtual del concentrador. Estos NVA enrutan el tráfico entre los ramales. Estos NVAs de concentrador no realizan operaciones NAT. En el diagrama anterior, la tabla de rutas personalizada para cada subred enrutable debe contener las siguientes UDR.

Destino	Tipo del próximo salto	Dirección IP de siguiente salto
10.0.0.0/8	VirtualNetworkAppliance	<Dirección IP del enrutador o firewall del concentrador>
10.0.0.0/24	VirtualNetworkAppliance	<Dirección IP del enrutador o firewall del concentrador>

La segunda UDR con como destino 10.0.0.0/24 garantiza que las conexiones a los recursos de la red virtual del centro se enruten a través del firewall del centro. Algunas aplicaciones pueden requerir más UDR. Si las máquinas virtuales de la zona de aterrizaje necesitan acceso a Internet a través de NVAs que normalmente se encuentran albergadas en el concentrador, se debe definir también una ruta predeterminada de 0.0.0.0/0.

Nota:

Cliente - Se admite la comunicación del controlador de dominio DSto-AD a través de NAT. No se ha probado la comunicación de controlador a controlador de dominio a través de NAT y no se admite. Para obtener más información, consulte Límites de soporte para Windows Server Active Directory a través de NAT. Se recomienda implementar controladores de dominio de Windows Server Active Directory en subredes enrutables.

Puede usar Azure Firewall o NVA que no son de Microsoft como dispositivos compatibles con NAT. En las secciones siguientes se tratan ambas opciones. No puede usar Azure NAT Gateway porque solo admite SNAT para el tráfico enlazado a Internet.

Implementación de SNAT a través de Azure Firewall

Cuando necesite priorizar la baja complejidad y la administración mínima, Azure Firewall proporciona la mejor solución para implementar SNAT para las conexiones que se originan en subredes no enrutadas. Azure Firewall proporciona las siguientes ventajas:

• Ciclo de vida totalmente administrado
• Alta disponibilidad integrada
• Escalado automático basado en el volumen de tráfico

Al usar Azure Firewall, tenga en cuenta los siguientes factores:

• Implemente Azure Firewall en su propia subred reservada denominada AzureFirewallSubnet, que debe usar un espacio de direcciones enrutable.

• Algunas SKU o configuraciones de Azure Firewall pueden requerir una segunda subred reservada para la administración del firewall. La subred de administración no requiere un espacio de direcciones enrutable.

• Azure Firewall tiene tres SKU diferentes. SNAT no consume muchos recursos, por lo que empieza con la SKU básica. En el caso de las zonas de aterrizaje que generan grandes volúmenes de tráfico saliente desde subredes no enrutables, considere la SKU estándar.

• Configure Azure Firewall con la opción Realizar SNAT establecida en Siempre. Cada instancia usa sus puertos sin privilegios para SNAT. Para configurar Azure Firewall para implementar SNAT en todas las conexiones recibidas, siga los pasos de configuración de SNAT.

• Asocie todas las subredes no enrutadas a una tabla de rutas personalizada que reenvía todo el tráfico destinado fuera de la zona de aterrizaje a la dirección IP privada del firewall.

En el siguiente diagrama se muestra una red hub-and-spoke en la que cada ramal hace uso de Azure Firewall para proporcionar SNAT para las conexiones provenientes de subredes no enrutables.

Este diagrama presenta un concentrador y dos ramales de zona de aterrizaje en zonas de aterrizaje independientes. El centro contiene tres subredes enrutables. El ramal de la zona de aterrizaje A contiene un controlador de distribución de aplicaciones y un firewall en subredes enrutables independientes. También contiene un front-end HTTP, una lógica de negocios y un nivel de datos en subredes no enrutables independientes. El controlador de distribución de aplicaciones apunta a tres componentes de la subred del front-end HTTP. La conexión de un componente pasa por el firewall del centro a través de SNAT. El ramal de la zona de aterrizaje B contiene un front end TCP/IP y un firewall en subredes enrutables independientes. También contiene lógica de negocios y un nivel de datos en subredes no enrutables independientes. La conexión de un componente de la subred de lógica empresarial pasa por el firewall del hub a través de SNAT. El concentrador está conectado a cada ramal de zona de aterrizaje.

Descargue un archivo de PowerPoint de esta arquitectura.

Implementación de SNAT a través de NVA que no son de Microsoft

Puede encontrar NVA que no son de Microsoft que tienen funcionalidades NAT en Azure Marketplace. Considere la posibilidad de usar una NVA que no sea de Microsoft si los requisitos superan lo que Azure Firewall puede admitir. Por ejemplo, es posible que necesite las siguientes funcionalidades:

• Control granular sobre el grupo NAT.

• Directivas NAT personalizadas, por ejemplo, es posible que tenga que usar diferentes direcciones NAT para diferentes conexiones.

• Control granular sobre el escalado horizontal

Al usar NVA que no son de Microsoft, tenga en cuenta los siguientes factores:

• Implemente un clúster que tenga al menos dos NVA para garantizar la alta disponibilidad.

• Use un balanceador de carga Azure Standard SKU para distribuir las conexiones desde la red virtual no enrutable hacia las NVAs. Todas las conexiones deben usar SNAT independientemente del puerto de destino, por lo que debe usar reglas de equilibrio de carga de alta disponibilidad, también conocidas como reglas de equilibrio de carga de cualquier puerto.

• Elija entre configuraciones de un solo brazo y de doble brazo para NVA compatibles con NAT. Las configuraciones de un solo brazo son más sencillas y, por lo general, se recomiendan.

El siguiente diagrama muestra cómo implementar SNAT en una topología de red de tipo hub-and-spoke mediante NVAs de terceros.

Este diagrama presenta un concentrador y dos ramales de zona de aterrizaje en zonas de aterrizaje independientes. El centro contiene tres subredes enrutables. La zona de aterrizaje A spoke contiene un controlador de entrega de aplicaciones y dos instancias NAT en una subred enrutable. También contiene un front-end HTTP, una lógica de negocios y un nivel de datos en subredes no enrutables independientes. El controlador de distribución de aplicaciones apunta a tres componentes de la subred del front-end HTTP. La conexión desde un componente pasa por una instancia NAT y, a continuación, a través del firewall del concentrador via SNAT. El ramal de la zona de aterrizaje B contiene un front-end TCP/IP dentro de una subred enrutable y dos instancias NAT en otra subred enrutable. También contiene lógica de negocios y un nivel de datos en subredes no enrutables independientes. La conexión desde un componente de la subred de lógica de negocios pasa a través de una instancia NAT y, a continuación, a través del concentrador vía SNAT. El concentrador está conectado a cada ramal de zona de aterrizaje.

Descargue un archivo de PowerPoint de esta arquitectura.

Uso del método 1 con Azure Virtual WAN

Azure Virtual WAN no admite el emparejamiento de subredes. Por lo tanto, no se pueden crear redes virtuales de zona de aterrizaje que tengan subredes no enrutables en redes de tipo hub-and-spoke basadas en Virtual WAN. Sin embargo, todavía puede aplicar el principio fundamental del Método 1 mediante dos redes virtuales emparejadas para cada zona de aterrizaje.

• Asigne un espacio de direcciones enrutable a la primera red virtual y conéctelo al centro de Virtual WAN.

• Asigne un espacio de direcciones no enrutable a la segunda red virtual y émparéjela con la red virtual enrutable.

En el diagrama siguiente se muestra la topología resultante.

Este diagrama contiene un centro de Virtual WAN y dos zonas de aterrizaje. La zona de aterrizaje A contiene un ramal enrutable de zona de aterrizaje y un ramal no enrutable de zona de aterrizaje, que están conectados a través de emparejamiento de red virtual. El ramal enrutable contiene un controlador de distribución de aplicaciones en una subred enrutable. El ramal no enrutable contiene un front-end HTTP, una lógica de negocios y una capa de datos en subredes no enrutables independientes. El controlador de entrega de aplicaciones se conecta a tres componentes de la subred de front-end HTTP. La zona de aterrizaje B contiene un ramal enrutable de zona de aterrizaje y un ramal no enrutable de zona de aterrizaje, que están conectados mediante emparejamiento de red virtual. El ramal enrutable contiene un front end TCP/IP en una subred enrutable. El segmento no enrutable contiene la lógica de negocio y una capa de datos en subredes no enrutables independientes. El concentrador Virtual WAN está conectado a cada ramal enrutable de la zona de aterrizaje.

Descargue un archivo de PowerPoint de esta arquitectura.

Este enfoque no limita la conectividad dentro de una zona de aterrizaje. Las dos redes virtuales de la zona de aterrizaje están emparejadas directamente, por lo que todos los recursos pueden conectarse entre sí, independientemente de si residen en una red virtual enrutable o no enrutable. Sin embargo, solo los recursos de la red virtual enrutable pueden conectarse a recursos fuera de la zona de aterrizaje.

Desde una perspectiva de enrutamiento, no hay ninguna diferencia entre las siguientes configuraciones:

• Subredes enrutables y no enrutables en la misma red virtual (descritas en la sección anterior para redes tradicionales hub-and-spoke)

• Redes virtuales emparejadas directamente (descritas en esta sección para redes hub-and-spoke basadas en Virtual WAN)

Como resultado, en redes basadas en Virtual WAN, se aplican las siguientes instrucciones:

• Puede distribuir componentes de aplicación entre subredes enrutables y no enrutadas mediante las mismas consideraciones descritas en las secciones anteriores.

• Puede gestionar las dependencias salientes con NVAs que admiten NAT en subredes enrutables.

Método 2: Servicios de Private Link

Private Link permite a los clientes de una red virtual consumir aplicaciones en otra red virtual sin configurar la conectividad de nivel 3, como el emparejamiento de red virtual o la VPN de red virtual a red virtual. Las dos redes virtuales pueden usar intervalos de direcciones IP superpuestos. Azure controla de forma transparente la lógica NAT necesaria. Este método se aplica tanto a las redes tradicionales en estrella tipo hub-and-spoke como a las redes basadas en Red de Área Amplia Virtual (Virtual WAN).

Para exponer una aplicación mediante Private Link, siga estos pasos:

1. Añadir los puntos de conexión de la aplicación al grupo de backend de un balanceador de carga interno Azure con el SKU Estándar.

2. Asocie la dirección IP de front-end del equilibrador de carga con un recurso de servicio Private Link.

3. En el lado cliente, cree un recurso de punto de conexión privado y asócielo al servicio Private Link del lado servidor.

Para consumir la aplicación, los clientes se conectan al punto de conexión privado. Azure enruta de forma transparente la conexión a la dirección IP de front-end del equilibrador de carga asociada al servicio Private Link correspondiente.

Puede usar Private Link para ayudar a mitigar el agotamiento de IPv4 asignando dos redes virtuales a cada zona de aterrizaje:

• Una red virtual que tiene un espacio de direcciones enrutable, conectado a la red corporativa

• Una red virtual aislada, que tiene un espacio de direcciones elegido arbitrariamente, que puede incluso superponerse con el espacio de direcciones de la red corporativa.

Implemente aplicaciones y servicios de Private Link que expongan sus puntos de conexión en las redes virtuales aisladas. Implemente los puntos de conexión privados, que se conectan a esos servicios, en las redes virtuales enrutables.

En el diagrama siguiente se muestran dos zonas de aterrizaje que usan un espacio 10.0.0.0/16de direcciones grande, que se superpone con el espacio de direcciones de la red corporativa. Cada zona de aterrizaje asigna este espacio a una red virtual aislada. Las aplicaciones se implementan en las redes virtuales de "spoke" aisladas y están asociadas a los servicios de Private Link.

Este diagrama contiene un centro de conectividad y dos zonas de aterrizaje. El centro contiene tres subredes enrutables. Cada zona de aterrizaje contiene un ramal enrutable y un ramal de zona de aterrizaje aislado. El ramal enrutable contiene una subred de puntos de conexión privada y una subred enrutable. El ramal aislado contiene una subred de aplicación y una subred del servicio vínculo privado que se conecta al punto de conexión privado en el ramal enrutable. La subred de la aplicación se conecta a la subred del servicio Private Link. El concentrador se conecta a cada ramal enrutable de la zona de aterrizaje a través de emparejamiento de red virtual.

Descargue un archivo de PowerPoint de esta arquitectura.

Los clientes de la red corporativa, incluidos los clientes de otras zonas de aterrizaje, consumen las aplicaciones a través de puntos de conexión privados asociados a los servicios de Private Link. En el diagrama siguiente se muestra cómo se establecen estas conexiones.

Este diagrama contiene un centro de conectividad y dos zonas de aterrizaje. El centro contiene tres subredes enrutables. Cada zona de aterrizaje contiene un ramal enrutable y un ramal de zona de aterrizaje aislado. El ramal enrutable contiene una subred de puntos de conexión privada y una subred enrutable. El ramal aislado contiene una subred de aplicación y una subred del servicio vínculo privado que se conecta al punto de conexión privado en el ramal enrutable. La subred de la aplicación se conecta a la subred del servicio Private Link. El concentrador se conecta a cada ramal enrutable de la zona de aterrizaje a través de emparejamiento de red virtual. Hay dos flujos. Un flujo va de la subred enrutable en la zona de aterrizaje A, al firewall de una subred enrutable en el hub, a la subred del punto de conexión privado en la zona de aterrizaje B, a la subred del servicio Private Link en la zona de aterrizaje B y, por último, a la subred de la aplicación en la zona de aterrizaje B. El segundo flujo va de la subred enrutable H3 en el hub, a la subred del punto de conexión privado en la zona de aterrizaje A, a la subred del servicio Private Link en la zona de aterrizaje A y, por último, a la subred de la aplicación en la zona de aterrizaje A.

Descargue un archivo de PowerPoint de esta arquitectura.

Uso de un servicio de Private Link para las dependencias salientes

Las aplicaciones de redes virtuales aisladas no pueden iniciar conexiones a puntos de conexión de la red corporativa. Por lo tanto, el método 2 funciona mejor en escenarios en los que las aplicaciones de diferentes zonas de aterrizaje funcionan de forma independiente y no se basan en sistemas de la red corporativa. Sin embargo, puede seguir aplicando este método cuando las aplicaciones de redes virtuales aisladas necesitan acceder a puntos de conexión específicos fuera de su zona de aterrizaje.

En el diagrama siguiente se muestra cómo un servicio Private Link permite que la aplicación de la red virtual aislada de la zona de aterrizaje A consuma un servicio compartido en la red virtual del concentrador y un punto de conexión de aplicación en la zona de aterrizaje B.

Este diagrama contiene un centro de conectividad y dos zonas de aterrizaje. El centro contiene dos subredes enrutables, una subred de servicio compartido y una subred del servicio Private Link. La subred del servicio compartido se conecta a la subred del servicio Private Link. Cada zona de aterrizaje contiene un ramal enrutable y un ramal de zona de aterrizaje aislado. El ramal enrutable contiene una subred de puntos de conexión privada y una subred enrutable. El ramal aislado de la zona de aterrizaje A contiene una subred de aplicación, una subred del servicio vínculo privado que se conecta al punto de conexión privado en el ramal enrutable, y otra subred privada de puntos de conexión. La subred de la aplicación se conecta a todos los puntos de conexión privados en la subred de puntos de conexión privados. Un punto de conexión privado (etiquetado 1) se conecta a la subred del servicio Private Link en el centro. Otro punto de conexión privado (etiquetado 2) se conecta a la subred del servicio Private Link en la zona de aterrizaje B. El segmento aislado de la zona de aterrizaje B contiene la subred del servicio Private Link y una subred de aplicación. Cada subred de aplicación se conecta a la subred del servicio Private Link en la misma zona de aterrizaje. El concentrador se conecta a cada ramal enrutable de la zona de aterrizaje.

Descargue un archivo de PowerPoint de esta arquitectura.

Colaboradores

Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.

Autores principales:

• Federico Guerrini | Arquitecto de soluciones en la nube sénior, Responsable técnico de Networking de Azure en EMEA
• Khush Kaviraj | Arquitecto de soluciones en la nube
• Jack Tracey | Arquitecto sénior de soluciones en la nube

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

• Configurar emparejamiento de subred
• Implementación de Azure Firewall en una red virtual
• Configuración de SNAT en Azure Firewall
• Direcciones IP admitidas en Azure Virtual Network
• Private Link
• Equilibrador de carga de Azure
• Interconexión de redes virtuales
• Topología de red de concentrador y radio

Recursos relacionados

• Diseño de la arquitectura de redes
• Enfoques de arquitectura para redes en soluciones multiinquilino