Azure: Balanceador de carga interno y Azure Firewall

Uno de los elementos “más comúnmente” implementado en Azure son los balanceadores de carga, similar al NLB que conocemos de toda la vida. Siguiendo con las topologías que había publicado hace unas semanas sobre redes en Azure, vamos a integrar un Azure Load Balancer el utilizaré para “publicar internamente” dos servidores web.

Como casi siempre, aquí os dejo una pequeña topología de redes virtuales en Azure (Hub-Spooke) integrando ahora un  balanceador en un vNet de Spooke. En la topología se ha integrado el balanceador con reglas de publicación en el Azure Firewall para proteger los servidores web internos, dejando únicamente expuestos a conexiones mediante la VPN y la IP Pública del Firewall al balanceador:

Para no extenderme mucho en el artículo, aquí os dejo un texto de MSFT sobre cuando utilizar un Balanceador de Carga:

• Equilibre la carga del tráfico entrante de Internet a las máquinas virtuales. Esta configuración se conoce como equilibrador de carga interno.
• Equilibrio de carga del tráfico entre máquinas virtuales dentro de una red virtual. También puede acceder a un servidor front-end de Load Balancer desde una red local en un escenario híbrido. Ambos escenarios utilizan una configuración que se conoce como equilibrador de carga interno.
• Reenviar el tráfico a un puerto específico de máquinas virtuales determinadas con reglas de traducción de direcciones de red (NAT) de entrada.
• Proporcionar conectividad de salida para máquinas virtuales dentro de la red virtual mediante un equilibrador de carga público

Es posible que si alguno de vosotros no se haya leído alguno de los artículos anteriores sobre las vNets, Firewall, etc.. os podáis perder con respecto a la topología, es por ello que os dejo aquí los artículo previos para meteros en el contexto:

• Redes Azure: Emparejamiento de redes virtuales globales
• Azure Firewall: Instalación y Configuración
• Azure Firewall: Internet Centralizado por Hub, Emparejamiento y Conexión vía VPN con On-Premises
• Azure Firewall: Centralizar la salida a Internet de las vNet
• Azure Firewall: Instalación y Configuración
• Redes Azure: Emparejamiento de redes virtuales globales
• Redes Azure: Emparejamiento de redes virtuales ubicadas en diferentes suscripciones

En Azure tenemos dos SKU en cuanto al balanceador de MSFT, básico y estándar (https://docs.microsoft.com/es-es/azure/load-balancer/load-balancer-overview). Tenemos diferentes entre ambos servicios, pero su configuración es muy similar, pero darle una lectura al enlaces que os he puesto para que tengáis claras cuales son las diferencias entre ambos balanceadores.

En este artículo voy a configurar ambos SKU de balanceador, pero básicamente para mostraros algunas diferencias.

Comentaros que la ubicación del balanceador debe ser la vNet donde se encuentran los servidores a balancear, pero pueden estar en subredes diferentes (como será en el caso de este artículo). Primero voy a comentaros los objetivos a conseguir en la configuración a comentar en este artículo:

• Balancear dos servidores Web (IIS)
• Permitir el acceso desde Internet y la red de On-Premises pasando (filtrando) por nuestro Azure Firewall

Una de la diferencias entre ambos SKU del balanceador de Azure son los puntos de conexión de cada grupo de back-end a publicar. Vamos, la disposición del grupo de servidores a publicar.  Si tenemos un balanceador con el SKU básico únicamente podemos balancear servidores que tengamos en un conjunto de disponibilidad o escalado. Como os había comentado que iba a comentar la publicación de ambos SKU de balaceador y, teniendo en cuenta que el requisito del básico es tener un conjunto de disponibilidad o escalado de máquina virtuales, vamos a crear un conjunto de disponibilidad.

Un servidor sólo puede estar configurado en un balanceador

La creación de un conjunto de disponibilidad es muy sencilla, en el momento de crear un nuevo servidor (después ya no lo podemos hacer) tenemos que seleccionar un conjunto de disponibilidad si ya tenemos uno o pulsamos en Crear nuevo

Elegimos el nombre del grupo disponibilidad y los dominios de error y actualización (https://docs.microsoft.com/es-es/azure/availability-zones/az-overview) y pulsamos en Aceptar

Ahora ya podemos seleccionar nuestro Conjunto de disponibilidad y continuar con la creación de nuestro servidor virtual como cualquier otro

Una vez se haya completado el proceso ya podemos ver nuestro conjunto de disponibilidad en el grupo de recursos donde lo hayamos creado y, podemos ver el servidor o servidores que tenemos en dicho conjunto de disponibilidad.

Para añadir un segundo o más servidores a dicho conjunto de disponibilidad simplemente tenemos que elegirlo en el momento de la creación de cada servidor.

Para este artículo utilizaré únicamente dos servidores, los que os muestro a continuación:

Ahora vía PowerShell desde el porta, de Azure podemos lanzar ciertos comandos, pues yo voy a utilizar un script que tiene MSFT en su web para realizar las pruebas de NLB:

Install-WindowsFeature -name Web-Server -IncludeManagementTools
remove-item C:\inetpub\wwwroot\iisstart.htm
Add-Content -Path “C:\inetpub\wwwroot\iisstart.htm” -Value $(“Test Balanceador ” + $env:computername)

Para ello nos vamos a la sección de Ejecutar comando, seleccionamos RunPowerShellScript y pegamos el contenido del script en la siguiente pantalla. Una vez hayamos pegado todo el texto, pulsamos en Ejecutar:

Será cuestión de segundos que se haya configurado, tenemos que esperemos entre 3 y 5 minutos, porque como vemos instalará el rol de Web Server:

Como os comentaba en cuestión de minutos veremos que el script se ha ejecutado, si ahora desde un navegador accedemos al servidor web veremos la página por defecto que hemos creado vía PowerShell 

Esto tenemos que hacerlo en todos los servidores que queramos balancear con nuestro balanceador, en mi caso eran dos servidores, puesto tengo que ejecutar dicho proceso en ambos servidores.

Una vez que ya tenemos configurado nuestro conjunto de disponibilidad, podríamos crear y configurar nuestro balanceador básico (no obligatorio para el balanceador con SKU estándar). Voy a comentar como crear dos balanceadores, cada uno con SKU diferente (básico y estándar), el proceso es similar, pero primero crearemos el básico.

Iremos a crear nuevo recurso, buscamos por Load Balancer

Pulsamos en Crear

Aquí vienen las primera diferencias, la cuales podréis apreciar cuando creemos el balanceador Estándar. Para este caso, básicamente cubrimos todos los datos, elegimos que será un balanceador interno (no tendrá IP Públicas) y su SKU es básico. A continuación tendremos que indicarle la vNet donde lo ubicaremos, la subred y dirección IP interna que tendrá nuestro balanceador. Una vez que tengamos todos los parámetros establecidos pulsamos en Revisar y crear:

Como siempre, antes de iniciarse el proceso de creación de cualquier recurso nos muestra un resumen de lo que hemos configurado, si estamos conformes pulsamos en Crear

A continuación os muestro cuales serían las opciones de creación de un balanceador estándar, básicamente es que definamos la zona de disponibilidad, una vez establecida pulsamos en Revisar y crear:

Si está todo correcto, pulsamos en Crear

En cuestión de unos segundos tenemos nuestro balanceador creado .. y podemos acceder al balanceador desde el botón Ir al recurso:

Continuando con la idea de comentar la publicación de ambos tipos de SKU del balanceador de Azure, vamos a empezar por la configuración del balanceador con el SKU básico. Una vez que hayamos pulsado en Ir al recurso accederemos directamente a la configuración del balanceador:

Podemos ver la(s) dirección IP Privada que tiene asignada

Si esto mismo lo hacemos en el balanceador estándar, veríamos la siguiente información:

Y de la misma forma que el balanceador básico podemos ver la(s) dirección(es) IPs Privadas:

Ahora vamos a lo importante, vamos a configurar nuestro NLB para los servidores Web que previamente habíamos creado. La siguiente configuración que os voy a mostrar es para la un balanceador básico, de ahí que hayamos creado el conjunto de disponibilidad previamente. Lo primero que debemos hacer es crear un Grupo de back-end, que nos es más que el conjunto de servidores que vamos a balancear. Para ello, nos vamos a la sección Grupos de back-end y pulsamos en Agregar. 

Debemos definir un nombre para este grupo de back-end, en Asociado a sólo podemos elegir Conjunto de disponibilidad, Máquina Virtual Única o Conjunto de escalas de máquina virtual:

En mi caso vamos a elegir Conjunto de disponibilidad y luego añadir el conjunto de disponibilidad previamente creado:

Ahora debemos seleccionar que servidores del grupo de disponibilidad queremos agregar el grupo de back-end:

Una vez hayamos añadido los servidores que queremos, pulsamos en Aceptar:

En cuestión de segundos tenemos nuestro grupo de back-end creado:

Lo siguiente es definir los sondeos para este grupo de back-end, los sondeos nos permite definir cuando el balanceador agregará o quitará de forma dinámica servidores virtuales del balanceo de carga. Para ello desde la sección de Sondeos de estado pulsamos en Agregar:

Ahora definimos un nombre, el protocolo de de sondeo a utilizar: TCP

O HTTP (HTTPS únicamente en el balanceador estándar)

Una vez que hayamos configurado el sondeo, debemos configurar las reglas del equilibrio carga, vamos, como vamos a definir el balanceo entre los servidores del grupo de back-end. Desde la sección de Reglas de equilibro de carga pulsamos en Agregar:

Aquí definimos un nombre, la dirección que vamos a utilizar del balanceador para recibir las peticiones, puerto del balanceador en el que recibiremos las conexiones y el puerto al que enviaremos a los servidores internos la conexión. Además, debemos elegir el grupo de back-end al que enviar las conexiones y el sondeo que hemos definido previamente.

Una vez que lo hayamos configurado, ya podemos probar a conectarnos a la IP Privada del balanceador para probar que ya tenemos acceso a los servidores Web que tenemos en el grupo de back-end. Lo que he hecho es conectarme a la IP del balanceador y ver que puedo acceder al sitio web (ahora nos viene perfecto la configuración del IIS con el fichero editado para saber a que servidor nos está enviando el balanceado):

Ahora detengo el IIS del servidor SRV-IIS11 y cuando me quiero conectar en el mismo momento que he detenido el servicio .. vemos que no nos muestra ninguna página web (aquí entra en juego la configuración del sondeo)

Una vez que se cumplen los tiempos configurados en el sondeo para esta publicación, intentamos volver a conectarnos y vemos que ahora nos muestra al web por defecto del SRV-IIS10 (el otro servidor del grupo de back-end)

Con esto ya tenemos nuestro balanceador básico configurado, fácil eh? Pues bien, que “problema” tenemos ahora, puesto que una de las limitaciones que tiene este balanceador es que no permite conexiones fuera de la zona en la que se encuentra. En el esquema que os he puesto el inicio del artículo, vemos que tenemos varias redes emparejadas entre diferentes zonas, pero si publicamos la web el acceso web desde el Firewall de la vNet de Hub no podemos llegar a ella ni desde la subred de On-Premises. Para esto tenemos que configurar un balanceador estándar, a continuación veamos como se configura un balanceador estándar.

Como habíamos comentado, el proceso de creación es muy similar, pero ahora vamos a ver su configuración. Primero, la creación del grupo de back-end, aquí vemos que podemos configurar servidores por su IP directamente y no tienen que estar en ningún grupo de disponibilidad previo, únicamente deben estar en la misma vNet:

El sonde de estado es igual que los balanceadores básico, a excepción que el protocolo pueder ser también HTTPS

En el equilibrio de carga tenemos también alguna diferencia, para ello vamos a crear nuestra regla de equilibrio de carga:

Vemos que tenemos una opción adicional, que es la de Puertos en HA: https://docs.microsoft.com/es-es/azure/load-balancer/load-balancer-ha-ports-overview

Una vez configurado nuestro balanceador, si volvemos a la sección de Información general vemos la configuración que tenemos desplegada en nuestro balanceador:

Ahora bien, toca probarlo, pero si es interno no tiene mayor ciencia que lo visto anteriormente. Este balanceador soporte el poder conectarse a él desde subredes fuera de su vNet, además, compatible con nuestro NVA (Azure Firewall) y sin creación ni adicción de rutas de usuario. Eso sí, tenemos que permitir el tráfico en nuestro Firewall para que permita las conexiones desde otras vNets que son las que pasan por el Firewall.

Aquí os muestro algunas reglas  de red, la primera es el permitir la conexión desde la subred de On-Premises (definida en la topología del inicio del artículo) para la IP del balanceador y puerto por el cual hemos configurado el servicio balanceado:

Además, para permitir que los usuarios se puedan conectar desde Internet a las web publicadas mediante el balanceador, tenemos que publicarlo mediante el Firewall que tenemos en la red de vNet, para ello tenemos que configurar una regla de NAT similar a esta. La IP Pública es la del Firewall y la interna es la del Balanceador (nunca la de los servidores internos, sino no tendríamos balanceo)

Si ahora pruebo a conectarme a la IP interna del balanceador (primera de las reglas del firewall que he creado) nos conectará sin problemas y, si ahora me quiero conectar via IP Pública lo hará igualmente, puesto que hemos configurado su regla de NAT correspondiente. La IP Privada que os muestro es para que veáis que me he conectado a la IP Privada del Balanceado desde una subred de On-Premises vía VPN (VPN Gateway)

Ahora si creamos un registro DNS para que desde dentro de la red apunte a la IP privada del balanceador, vemos que podemos conectarnos sin problema

Y si ahora queremos conectarnos a alguno de los servidores web que tenemos balanceados, el firewall nos muestra un mensaje indicando que no tenemos regla que lo permita y por defecto bloqueará la conexión. Esto es justamente también lo que queremos conseguir, proteger que nadie se conecte directamente a ninguno de los servidores web internos, sino que pasen por el balanceador.

Esta es la regla que había configurado para permitir únicamente las conexiones desde la subred de On-Premises:

Pero si tenemos configurado esta regla y, además hemos configurado una regla de NAT en el Firewall … los usuarios no se podrán conectar:

Porque si os habéis fijado en la regla que permite el tráfico hacia la IP del balanceador tengo como IP de origen la subred de On-Premises, por lo que si queremos publicarlo desde Internet tenemos que modificar dicha regla y ahí  definir todas las redes desde la que permitiremos conexiones. Si son conexiones sin orígenes determinados tenemos que definir * como origen, para que permita conexiones desde cualquier origen:

Pues ya veis, igual de sencillo un balanceado básico como estándar, pero claramente cada uno con sus limitaciones. Leer con detalle todos los enlaces que os voy poniendo, ahí vienen todas las características del balanceador, etc.. si las comento yo entonces si que el artículo se vuelve .. imposible de leer.

Espero que os resulte de utilidad, el próximo artículo veremos como implementar Azure Application Gateway!!!