Escenario de aplicación virtual

Un escenario común entre los clientes de Azure de mayor tamaño es la necesidad de ofrecer una aplicación de dos niveles expuesta a internet a la vez que permita el acceso al nivel posterior desde un centro de datos local. Este documento le guiará a través de un escenario utilizando tablas de enrutamiento, una puerta de enlace de VPN y dispositivos virtuales de red para implementar un entorno de dos niveles que cumpla con los siguientes requisitos:

• Solo se debe poder tener acceso a la aplicación web desde una red pública de Internet.

• El servidor web que hospeda la aplicación debe poder tener acceso 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 vaya al servidor de aplicaciones debe pasar por una aplicación virtual de firewall. Esta aplicación virtual se usará para tener acceso al servidor back-end, y el acceso entrante provendrá de la red local a través de VPN Gateway.

• Los administradores deberán poder administrar las aplicaciones virtuales de firewall desde los equipos locales con una tercera aplicación virtual de firewall que se usará exclusivamente para la administración.

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

La siguiente tabla muestra algunas de las ventajas y desventajas entre los NSG y las aplicaciones virtuales de firewall.

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 que se explicó anteriormente en Azure con distintas características que actualmente están disponibles, como se indica a continuación.

• Red virtual. Una red virtual de Azure actúa de manera similar a una red local y se puede segmentar en una o más subredes para ofrecer el aislamiento del tráfico y la separación de proceso.

• Aplicación virtual. Varios socios proporcionan aplicaciones virtuales en Azure Marketplace que se pueden usar para los tres firewalls anteriormente descritos.

• Tablas de ruta. Las tablas de ruta se usan por la conexión en red de Azure para controlar el flujo de paquetes dentro de una red virtual. Estas tablas de ruta se pueden aplicar a las subredes. Es posible aplicar una tabla de enrutamiento a GatewaySubnet, que reenviará todo el tráfico que entre en la red virtual de Azure desde una conexión híbrida a una aplicación virtual.

• Reenvío 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. Por lo tanto, si una tabla de enrutamiento define que un paquete se debe enviar a una aplicación virtual determinada, el motor de redes de Azure descartaría 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 (NSG) . El siguiente ejemplo no usa NSG, pero podría usar NSG aplicados a las subredes o NIC en esta solución. Los NSG filtrarían aún más el tráfico dentro y fuera de esas subredes y NIC.

En este ejemplo, hay una suscripción que 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 segmentada como se usa a continuación para imitar un centro de datos local.

  • onpremsn1. Subred que contiene una máquina virtual (VM) que ejecuta una distribución de Linux para simular un servidor local.

  • onpremsn2. Subred que contiene una máquina virtual que ejecuta una distribución de Linux para simular un equipo local que usa un administrador.

• Hay una aplicación virtual de firewall llamada OPFW en onpremvnet que se usa para mantener un túnel a azurevnet.

• Una red virtual denominada azurevnet segmentada de la siguiente manera.

  • azsn1. Subred de firewall externo que se usa exclusivamente para el firewall externo. Todo el tráfico de Internet entrará a través de esta subred. Esta subred contiene sólo una NIC vinculada para el firewall externo.

  • azsn2. Subred de front-end que hospeda una máquina virtual que se ejecuta como servidor web al que se tiene acceso desde internet.

  • azsn3. Subred de back-end que hospeda una máquina virtual que ejecuta un servidor de aplicaciones back-end al que tendrá acceso el servidor web de front-end.

  • azsn4. Subred de administración que se usa exclusivamente para brindar acceso de administración a todas las aplicaciones virtuales de firewall. Esta subred solo contiene una tarjeta NIC para cada aplicación virtual de firewall que se usa en la solución.

  • GatewaySubnet. Subred de conexión híbrida de Azure que se requiere para que ExpressRoute y VPN Gateway proporcionen conectividad entre redes virtuales de Azure y otras redes.

• Hay 3 aplicaciones virtuales de firewall en la red azurevnet .

  • AZF1. Firewall externo expuesto a la red pública de Internet mediante un recurso de dirección IP pública en Azure. Deberá asegurarse de tener una plantilla proveniente de Marketplace, o bien directamente desde el proveedor de aplicaciones, que implemente una aplicación virtual de 3 NIC.

  • AZF2. Firewall interno que se usa para controlar el tráfico entre azsn2 y azsn3. Este firewall también es una aplicación virtual de 3 NIC.

  • AZF3. Firewall de administración al que los administradores tienen acceso desde el centro de datos local y que está conectado a una subred de administración que se usa para administrar todas las aplicaciones de firewall. Puede encontrar plantillas de aplicaciones virtuales de 2 NIC en Marketplace, o bien solicitar una directamente al proveedor de aplicaciones.

Tablas de ruta

Cada subred de Azure se puede vincular a una tabla de enrutamiento que se usa para definir cómo se enruta el tráfico que se inicia en esa subred. Si no hay definida ninguna UDR, Azure usa las 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 realice a través del dispositivo de firewall correcto, según el último requisito mencionado anteriormente, deberá crear la siguiente tabla de rutas en azurevnet.

azgwudr

En este escenario, el único tráfico que fluye desde el sitio local a Azure se usa para administrar los firewalls a través de la conexión con AZF3, y ese tráfico deberá pasar por el firewall interno AZF2. Por lo tanto, solo se necesitará una ruta en GatewaySubnet, tal como se muestra a continuación.

azsn2udr

azsn3udr

También deberá crear tablas de ruta para que las subredes de onpremvnet simulen el centro de datos local.

onpremsn1udr

onpremsn2udr

reenvío de IP

Las tablas de enrutamiento y el reenvío de IP son características que se pueden usar en conjunto para permitir que las aplicaciones virtuales se usen para controlar el flujo de tráfico en una red virtual de Azure. Un dispositivo virtual no es más que una máquina virtual que ejecuta una aplicación utilizada para controlar el tráfico de red de alguna manera, como un firewall o un dispositivo NAT.

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.

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

• La subred onpremsn1 contiene una máquina virtual llamada onpremvm1.

• La subred onpremsn2 contiene una máquina virtual llamada onpremvm2.

• Una aplicación virtual llamada OPFW está conectada a onpremsn1 y onpremsn2.

• Una ruta definida por el usuario vinculada a onpremsn1 especifica que todo el tráfico a onpremsn2 se debe enviar a OPFW.

En este punto, si onpremvm1 intenta establecer una conexión con onpremvm2, se usará la UDR y el tráfico se enviará a OPFW como el próximo salto. Tenga en cuenta que el destino real del paquete no cambia, ya que seguirá siendo onpremvm2.

Si el reenvío de IP no está habilitado para OPFW, la lógica de la red virtual de Azure descartará los paquetes debido a que solo permite que los paquetes se envíen a una máquina virtual si la dirección IP de la máquina virtual es el destino del paquete.

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

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

Reglas de firewall

Como se describió anteriormente, el reenvío de IP solo asegurará 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) se debe enviar a través del túnel ONPREMAZURE.

• Directiva: permita todo el tráfico bidireccional entre port2 y ONPREMAZURE.

AZF1

AZF1 representa una aplicación virtual de Azure que incluye las siguientes reglas:

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

AZF2

AZF2 representa una aplicación de Azure que contiene las siguientes reglas:

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

AZF3

AZF3 representa una aplicación virtual de Azure que incluye las reglas siguientes:

• Ruta: todo el tráfico a 192.168.0.0/16 (onpremvnet) se debe enviar 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 (NSG)

En este escenario, no se usan los NSG. Sin embargo, podría aplicar los NSG a cada subred para restringir el tráfico entrante y saliente. Por ejemplo, podría aplicar las siguientes reglas de NSG a la subred de 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 de alto nivel

Para implementar este escenario, siga estos pasos de alto nivel.

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 de onpremvnet a azurevnet.

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