Despliegue de un Wildcard Azure Application Gateway usando Powershell
Azure Application Gateway existe desde hace bastantes años. En los últimos años, hemos visto cómo ha cambiado desde el estándar original (V1) sin ninguna funcionalidad de Web Application Firewall hasta el estándar más reciente (V2) con o sin funcionalidad WAF. La versión v2 se ha lanzado el 30 de abril de 2019, por lo que probablemente ya haya sustituido a la mayoría de sus V1 (o si quiere empezar de cero, la V2 es probablemente el camino a seguir)
¿Cómo funciona un Application Gateway?
Sólo como recordatorio, cómo funciona exactamente un Azure Application Gateway:
Como se ilustra en la imagen anterior, puede colocar un Azure Application Gateway entre los clientes (web) -por ejemplo, los usuarios que quieren conectarse a su sitio web- y su(s) servidor(es) backend. Los equilibradores de carga tradicionales operan en la capa de transporte (capa OSI 4 – TCP y UDP) y enrutan el tráfico basándose en la dirección IP de origen y el puerto, hacia una dirección IP de destino y un puerto.
Application Gateway puede tomar decisiones de enrutamiento basadas en atributos adicionales de una solicitud HTTP, por ejemplo la ruta URI o las cabeceras de host. Por ejemplo, puede enrutar el tráfico basándose en la URL entrante. Así, si /images está en la URL entrante, puede enrutar el tráfico a un conjunto específico de servidores (conocido como pool) configurado para imágenes. Si /video está en la URL, ese tráfico se dirige a otro grupo optimizado para vídeos.
Este tipo de enrutamiento se conoce como equilibrio de carga de la capa de aplicación (capa 7 de OSI). Azure Application Gateway puede hacer un enrutamiento basado en URL y más. Si quieres saber más sobre todas las características que tiene una aplicación, consulta este sitio
Ahora presentando: Wildcard Application Gateway
Así que, para aquellos de ustedes que han estado desplegando Application Gateways en el pasado, ya sea a través del uso de plantillas ARM, Azure CLI o Powershell, probablemente sabrán que el proceso de despliegue de un AGW es bastante engorroso, especialmente cuando se desea definir múltiples oyentes y / o configuraciones HTTP backend. Personalmente, en el pasado he desplegado Application Gateways que constaban de 15 listeners y subsecuentes configuraciones de backend, todas terminando en el mismo domainname.
Por ejemplo:
www.contoso.com;
Contoso.com;
Mi.contoso.com;
Etc.
El problema de una configuración así es que era bastante trabajo crear los listeners, asociarlos a una regla que a su vez está asociada a un backend y a una configuración HTTP. Y tenías que hacerlo para cada nombre de host que quisieras configurar, a pesar de que todos compartieran el mismo dominio.
Pero desde el 20 de julio de 2020, Microsoft ha anunciado que ahora también soportarán la opción de definir nombres de host con comodines en un listener multisitio. Y se podrán utilizar hasta 5 nombres de host únicos por listener. ¿No es genial?
Así que cómo funciona exactamente se muestra a continuación:
Como puede ver en la imagen de arriba, hay múltiples oyentes ‘multisitio’ configurados en esta puerta de enlace de aplicaciones:
– *.contoso.com, *.fabrikam.*
– *.contos-*, frabrikam-??.com
Estos listeners pueden ser enrutados al mismo o a diferentes pools de backend.
Así, usando un carácter comodín en el nombre del host, puedes hacer coincidir múltiples nombres de host en un solo listener. Por ejemplo, *.contoso.com puede coincidir con ecom.contoso.com, b2b.contoso.com así como customer1.b2b.contoso.com y así sucesivamente. Utilizando una matriz de nombres de host, puede configurar más de un nombre de host para un oyente, para enrutar las solicitudes a un grupo de backend. Por ejemplo, un oyente puede contener contoso.com, fabrikam.com que aceptará solicitudes para ambos nombres de host.
Las advertencias de los oyentes comodín
Dado que los oyentes comodín están actualmente en vista previa, hay algunas consideraciones y limitaciones a tener en cuenta:
1. Esta característica está en vista previa y está disponible sólo para Standard_v2 y WAF_v2 SKU de Application Gateway.
2. Esta característica está actualmente disponible sólo a través de Azure PowerShell y Azure CLI. La compatibilidad con el portal está por llegar. Tenga en cuenta que, dado que la compatibilidad con el portal no está totalmente disponible, si utiliza únicamente el parámetro HostNames, el receptor aparecerá como un receptor básico en el portal y la columna Host name de la vista de la lista de receptores no mostrará los nombres de host configurados. Para cualquier cambio en un listener comodín, asegúrate de usar Azure PowerShell o CLI hasta que esté soportado en el portal. Compartiré algunas capturas de pantalla con respecto a esto más adelante en este blog.
3. No se puede crear una regla de redirección con un oyente de destino que utiliza comodines o múltiples nombres de host. Por lo tanto, no puede crear una redirección de HTTP a HTTPS como puede hacerlo en una configuración de oyente sin comodines.
4. Para la comprobación de la salud del backend, no puede asociar varias sondas personalizadas por configuración de HTTP. En su lugar, puede sondear uno de los sitios web en el backend o utilizar «127.0.0.1» para sondear el localhost del servidor backend. Sin embargo, cuando se utilizan comodines o varios nombres de host en una escucha, las solicitudes de todos los patrones de dominio especificados se dirigirán al conjunto de backend en función del tipo de regla (básica o basada en la ruta).
5. No se puede utilizar una expresión regular para mencionar el nombre del host. Sólo puede utilizar caracteres comodín como asterisco (*) y signo de interrogación (?) para formar el patrón del nombre de host.
6. Si se mencionan varios nombres de host en la misma escucha, debe cargar un certificado SAN (Subject Alternative Names) con los CN que coincidan con los nombres de host mencionados.
7. Si se trata de un nombre de host comodín como *.contoso.com, debe cargar un certificado comodín con CN como *.contoso.com
¡Basta de teoría! ¿Cómo puedo desplegar?
Como se ha mencionado antes, en el momento de escribir este blog, puedes utilizar Powershell o Azure CLI.
He construido un ejemplo de powershell que hará lo siguiente:
1. Encontrar el VNET apropiado y subred para desplegar el AGW en.
2. Crear una dirección IP pública para ser utilizado por el AGW
3. Crear IPconfigurations para Gateway y el frontend
4. Crear backend-pools
5. Crear listeners y reglas de enrutamiento
6. Crear la política del Web Application Firewall
7. Configurar los ajustes de la política TLS
8. Crear la pasarela de aplicación (en este punto será una AGW sólo HTTP)
Después de que la AGW haya sido desplegada con éxito, el script añadirá HTTPS a la pasarela de aplicación:
9. Encontrar la AGW y almacenarla en una variable
10. Añade el certificado SSL (PFX + contraseña obligatoria) y guárdalo en una variable
11. Añadir el puerto de escucha del frontend HTTPS y almacenarlo en una variable
12. Obtener la configuración de la IP del frontend y almacenarla en una variable
13. Añadir un receptor de frontend (HTTPS) y almacenarlo en una variable
14. Obtener el backendpool y almacenarlo en una variable
15. Añadir la configuración HTTP del backend y almacenarla en una variable
16. Unir todo lo anterior en una regla de enrutamiento
17. Actualizar el Application Gateway con todo lo creado en los pasos 8-15.
El script de powershell
Antes de poder ejecutar el script de powershell, hay que hacer algunas cosas:
1. Inicie sesión en Azure, utilizando powershell (login-azAccount)
2. Encuentre la suscripción que desea desplegar en (get-azSubscription)
3. Seleccione esa suscripción (select-azsubscription -subscription «SUBSCRIPTIONNAME»)
4. Asegúrese de que tiene lo siguiente creado un VNET y Subnet en su suscripción, que es capaz de desplegar el AGW en. Para el tamaño de la subred, se recomienda utilizar una subred /26 como mínimo.
5. Si tiene una VNET en funcionamiento y subredes desplegadas en un grupo de recursos de su elección, rellene los siguientes parámetros con la información apropiada:
– Nombre del grupo de recursos de la red virtual ($VnetRGName)
– Nombre de la red virtual ($VnetName)
– Nombre de la subred ($SubnetName)
6. El resto de las variables depende realmente de usted. Porque puede haber cosas involucradas como la convención de nombres, la configuración del tiempo de espera, etc. No voy a recomendar nada aquí. Mi script se basa en un único oyente comodín con un único backend y algunas configuraciones http por defecto, pero siéntase libre de editarlas a su gusto.
7. Se presta especial atención a la configuración WAF & SSL/TLS. Este script habilitará WAF para usted y creará una política WAF en el mismo grupo de recursos en el que se desplegará el Application Gateway. Esta política WAF está vinculada a la AGW. Para la configuración de SSL/TLS estoy habilitando la última configuración de políticas preconfiguradas (mejores prácticas).
¿Cuál será el resultado?
Una vez que haya ejecutado el script de powershell, terminará con un grupo de recursos que tiene los siguientes recursos:
1. La propia Application Gateway
2. Una dirección IP pública que está vinculada a la Application Gateway
3. Una Política de Firewall de Aplicaciones Web personalizada que está vinculada a la Application Gateway
¡Espero que este post te ayude a desplegar y configurar la Wildcard Application Gateway que deseas!
Enlaces útiles:
El script Powershell en github
Documentación de Microsoft
Leave a Reply