Partekatu honen bidez:

Escenario de aplicación virtual

  • Artikulua

Un escenario común entre los clientes de Azure más grandes es la necesidad de proporcionar una aplicación de dos niveles que se expone a Internet, mientras que también permite el acceso al nivel posterior desde un centro de datos local. En este artículo se explica un escenario que usa tablas de rutas, una puerta de enlace de VPN y aplicaciones virtuales de red para implementar un entorno de dos niveles que cumpla los siguientes requisitos:

  • Solo se debe acceder a una aplicación web desde la red pública de Internet.
  • Un servidor web que hospeda la aplicación debe poder acceder a un servidor de aplicaciones back-end.
  • Todo el tráfico desde Internet a la aplicación web debe pasar por una aplicación virtual de firewall. Esta aplicación virtual se usará solo para el tráfico de Internet.
  • Todo el tráfico que va al servidor de aplicaciones debe pasar por una aplicación virtual de firewall. Esta aplicación virtual se usa para el acceso al servidor back-end y para el acceso procedente de la red local a través de una puerta de enlace de VPN.
  • Los administradores deben poder administrar las aplicaciones virtuales de firewall desde sus equipos locales mediante un tercer dispositivo virtual de firewall que se usa exclusivamente para fines de administración.

Este ejemplo es un escenario de red perimetral estándar (también conocida como DMZ) con una DMZ y una red protegida. Puede construir este escenario en Azure mediante grupos de seguridad de red (NSG), aplicaciones virtuales de firewall o una combinación de ambos.

En la tabla siguiente se muestran algunas de las ventajas y desventajas de los grupos de seguridad de red y las aplicaciones virtuales de firewall.

Elemento Ventajas Desventajas
NSG No tienen costo.
Integrado en el acceso basado en roles de Azure.
Capacidad de crear reglas en plantillas de Azure Resource Manager.		 La complejidad podría variar en entornos de mayor tamaño.
Firewall Control total sobre el plano de datos.
Administración central a través de la consola de firewall.		 El costo de la aplicación de firewall.
No integrado en el acceso basado en roles de Azure.

La siguiente solución usa aplicaciones virtuales de firewall para implementar un escenario de red protegida o red perimetral (DMZ).

Consideraciones

Puede implementar el entorno anterior en Azure mediante características que están disponibles actualmente:

  • Red virtual: una red virtual de Azure actúa de forma similar a una red local. Puede segmentarla en una o varias subredes para proporcionar aislamiento del tráfico y separación de problemas.
  • Aplicación virtual: varios asociados proporcionan aplicaciones virtuales en Azure Marketplace para usarlas para los tres firewalls descritos anteriormente.
  • Tablas de rutas: las redes de Azure usan las tablas de rutas para controlar el flujo de paquetes dentro de una red virtual. Puede aplicar estas tablas de rutas a subredes. Puede aplicar una tabla de rutas a GatewaySubnet, que reenvía todo el tráfico que entra en la red virtual de Azure desde una conexión híbrida a una aplicación virtual.
  • Reenvío de IP: de manera predeterminada, el motor de redes de Azure reenvía paquetes a las tarjetas de interfaz de red (NIC) virtuales solo si la dirección IP de destino del paquete coincide con la dirección IP de la NIC. Si una tabla de rutas define que se debe enviar un paquete a una aplicación virtual específica, el motor de red de Azure quita ese paquete. Para asegurarse de que el paquete se entregue a una máquina virtual (en este caso, una aplicación virtual) que no es el destino real del paquete, habilite el reenvío IP para la aplicación virtual.
  • Grupos de seguridad de red: el ejemplo siguiente no usa grupos de seguridad de red, pero puede usar grupos de seguridad de red aplicados a las subredes o NIC de esta solución. Los NSG filtran aún más el tráfico dentro y fuera de esas subredes y NIC.

Diagrama que muestra la conectividad IPv6.

En este ejemplo, una suscripción contiene los siguientes elementos:

  • Dos grupos de recursos (que no aparecen en el diagrama):

    • ONPREMRG: contiene todos los recursos que se necesitan para simular una red local.
    • AZURERG: contiene todos los recursos que se necesitan para el entorno de red virtual de Azure.

  • Una red virtual denominada onpremvnet se segmenta y se usa para imitar un centro de datos local:

    • onpremsn1: una subred que contiene una máquina virtual (VM) que ejecuta una distribución de Linux para imitar un servidor local.
    • onpremsn2: una subred que contiene una máquina virtual que ejecuta una distribución de Linux para imitar un equipo local usado por un administrador.

  • Una aplicación virtual de firewall se denomina OPFW en onpremvnet. Se usa para mantener un túnel para azurevnet.

  • Una red virtual denominada azurevnet se segmenta de la siguiente manera:

    • azsn1: una subred de firewall externa que se usa exclusivamente para el firewall externo. Todo el tráfico de Internet entrará a través de esta subred. Esta subred contiene solo una NIC vinculada al firewall externo.
    • azsn2: una subred front-end que hospeda una máquina virtual que se ejecuta como un servidor web al que se accede desde Internet.
    • azsn3: una subred de back-end que hospeda una máquina virtual que ejecuta un servidor de aplicaciones back-end al que accede el servidor web front-end.
    • azsn4: una subred de administración que se usa exclusivamente para proporcionar acceso de administración a todas las aplicaciones virtuales de firewall. Esta subred contiene solo una NIC para cada aplicación virtual de firewall que se usa en la solución.
    • GatewaySubnet: una subred de conexión híbrida de Azure necesaria para Azure ExpressRoute y Azure VPN Gateway para proporcionar conectividad entre redes virtuales de Azure y otras redes.

  • Hay tres aplicaciones virtuales de firewall en la red azurevnet:

    • AZF1: un firewall externo expuesto a la red pública de Internet mediante un recurso de dirección IP pública en Azure. Debe asegurarse de que tiene una plantilla de Azure Marketplace o directamente del proveedor del dispositivo que implementa una aplicación virtual de tres NIC.
    • AZF2: un firewall interno que se usa para controlar el tráfico entre azsn2 y azsn3. Este firewall también es una aplicación virtual de tres NIC.
    • AZF3: un firewall de administración accesible para los administradores desde el centro de datos local y conectado a una subred de administración que se usa para administrar todos los dispositivos de firewall. Puede encontrar plantillas de aplicación virtual de dos NIC en Azure Marketplace. También puede solicitar uno directamente desde el proveedor del dispositivo.

Tablas de ruta

Vincule cada subred de Azure a una tabla de rutas para definir cómo se enruta el tráfico iniciado en esa subred. Si no se definen rutas definidas por el usuario (UDR), Azure usa rutas predeterminadas para permitir que el tráfico fluya de una subred a otra. Para comprender mejor las tablas de enrutamiento y el enrutamiento del tráfico, consulte Enrutamiento del tráfico de red virtual de Azure.

Para asegurarse de que la comunicación se realiza a través del dispositivo de firewall adecuado, en función del último requisito enumerado anteriormente, debe crear la siguiente tabla de rutas en azurevnet.

azgwudr

En este escenario, el único tráfico que fluye desde el entorno local a Azure se usa para administrar los firewalls mediante la conexión a AZF3 y ese tráfico debe pasar por el firewall interno, AZF2. Solo se necesita una ruta en GatewaySubnet, como se muestra aquí:

Destino Próximo salto Explicación
10.0.4.0/24 10.0.3.11 Permite que el tráfico local llegue al firewall de administración AZF3.

azsn2udr

Destination Próximo salto Explicación
10.0.3.0/24 10.0.2.11 Permite el tráfico a la subred back-end que hospeda el servidor de aplicaciones a través de AZF2.
0.0.0.0/0 10.0.2.10 Permite que el resto del tráfico se enrute a través de AZF1.

azsn3udr

Destination Próximo salto Explicación
10.0.2.0/24 10.0.3.10 Permite que el tráfico azsn2 fluya desde un servidor de aplicaciones al servidor web a través de AZF2.

También debe crear tablas de rutas para las subredes de onpremvnet para imitar el centro de datos local.

onpremsn1udr

Destination Próximo salto Explicación
192.168.2.0/24 192.168.1.4 Permite que el tráfico onpremsn2 a través de OPFW.

onpremsn2udr

Destination Próximo salto Explicación
10.0.3.0/24 192.168.2.4 Permite el tráfico a la subred back-end de Azure a través de OPFW.
192.168.1.0/24 192.168.2.4 Permite que el tráfico onpremsn1 a través de OPFW.

Reenvío IP

Las tablas de enrutamiento y el reenvío de IP son características que puede usar en combinación para permitir que las aplicaciones virtuales controlen el flujo de tráfico en una red virtual de Azure. Una aplicación virtual no es más que una máquina virtual que ejecuta una aplicación que se usa para controlar el tráfico de red de alguna manera, como un firewall o un dispositivo de traducción de direcciones de red.

La máquina virtual de este dispositivo virtual deberá ser capaz de recibir el tráfico entrante que no se dirija a sí mismo. Para permitir que una máquina virtual reciba el tráfico dirigido a otros destinos, debe habilitar el reenvío IP de la máquina virtual. Esta es una opción de configuración de Azure, no de la configuración del sistema operativo invitado. De todos modos, la aplicación virtual debe ejecutar algún tipo de aplicación para controlar el tráfico entrante y enrutarlo como corresponda.

Para más información sobre el reenvío de IP, consulte Enrutamiento del tráfico de red virtual de Azure.

Por ejemplo, imagine que tiene la siguiente configuración en una red virtual de Azure:

  • La onpremsn1 de subred contiene una máquina virtual denominada onpremvm1.
  • La onpremsn2 de subred contiene una máquina virtual denominada onpremvm2.
  • Una aplicación virtual denominada OPFW está conectada a onpremsn1 y onpremsn2.
  • Una UDR vinculada a onpremsn1 especifica que todo el tráfico a onpremsn2 debe enviarse a OPFW.

En este momento, si onpremvm1 intenta establecer una conexión con onpremvm2, se usa la UDR y el tráfico se envía a OPFW como próximo salto. El destino del paquete real no se está cambiando. Sigue diciendo que onpremvm2 es el destino.

Sin el reenvío de IP habilitado para OPFW, la lógica de red virtual de Azure quita los paquetes porque solo permite enviar paquetes a una máquina virtual si la dirección IP de la máquina virtual es el destino del paquete.

Con el reenvío de IP, la lógica de red virtual de Azure reenvía los paquetes a OPFW, sin cambiar su dirección de destino original. OPFW debe controlar los paquetes y determinar qué hacer con ellos.

Para que el escenario anterior funcione, debe habilitar el reenvío de IP en las NIC para OPFW, AZF1, AZF2 y AZF3 que se usan para el enrutamiento (todas las NIC excepto las vinculadas a la subred de administración).

Reglas de firewall

Como se ha descrito anteriormente, el reenvío de IP solo garantiza que los paquetes se envíen a las aplicaciones virtuales. De todos modos, la aplicación debe decidir qué hacer con esos paquetes. En el escenario anterior, deberá crear las siguientes reglas en las aplicaciones.

OPFW

OPFW representa un dispositivo local que contiene las siguientes reglas:

  • Ruta: todo el tráfico a 10.0.0.0/16 (azurevnet) debe enviarse a través del túnel ONPREMAZURE.
  • Directiva: permite todo el tráfico bidireccional entre port2 y ONPREMAZURE.

AZF1

AZF1 representa una aplicación virtual de Azure que contiene la siguiente regla:

Directiva: permite todo el tráfico bidireccional entre port1 y port2.

AZF2

AZF2 representa una aplicación virtual de Azure que contiene la siguiente regla:

Directiva: permite todo el tráfico bidireccional entre port1 y port2.

AZF3

AZF3 representa una aplicación virtual de Azure que contiene la siguiente regla:

Ruta: todo el tráfico a 192.168.0.0/16 (onpremvnet) debe enviarse a la dirección IP de la puerta de enlace de Azure (es decir, 10.0.0.1) a través de port1.

Grupos de seguridad de red

En este escenario, no se usan los NSG. Sin embargo, puede aplicar los NSG a cada subred para restringir el tráfico entrante y saliente. Por ejemplo, puede aplicar las siguientes reglas de NSG a la subred del firewall externo.

Entrante

  • Permita todo el tráfico TCP desde Internet al puerto 80 en cualquier máquina virtual de la subred.
  • Deniegue el resto del tráfico que provenga de Internet.

Saliente

Deniegue todo el tráfico hacia Internet.

Pasos generales

Siga estos pasos para implementar este escenario:

  1. Inicie sesión en la suscripción de Azure.

  2. Si desea implementar una red virtual que simule la red local, implemente los recursos que sean parte de ONPREMRG.

  3. Implemente los recursos que sean parte de AZURERG.

  4. Implemente el túnel desde onpremvnet en azurevnet.

  5. Una vez aprovisionados todos los recursos, inicie sesión en onpremvm2 y haga ping 10.0.3.101 para probar la conectividad entre onpremsn2 y azsn3.