Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe

Azure Application Gateway

Poster un commentaire

Azure Application Gateway (Passerelle d’Application) est un service Azure qui se place en amont d’un trafic pour assurer diverses fonctions:

  • Déchargement SSL
  • SSL de bout en bout
  • Affinité de session
  • Equilibrage de charge
  • Redirection, en particulier HTTP => HTTPS
  • Routage
  • Pare-feu, application de règles de sécurité (OWASP)

La liste n’est pas exhaustive. L’objet de cet article est de donner les bases et monter un exemple. Pour toute la suite j’utiliserai l’acronyme AAG.

Architecture

Présentation

AAG doit être déployé dans un réseau, plus précisément dans un sous réseau créé sur un VNET. Ce sous-réseau ne peut contenir que des AAG.

Examinez ce schéma qui décrit un scénario typique de fonctionnement d’une AAG.

 

Des flux sont interceptés par AAG (3 représentés) et routés vers des serveurs en analysant l’url. On retrouve dans ce document les briques essentielles de l’architecture d’une AAG.

Tout d’abord une AAG doit être déployée dans un sous-réseau d’une VNET. Ce sous-réseau ne peut contenir que des AAG, pas de VM par exemple.

 

Le flux entrant est analysé par des écouteurs. On en a déclaré 3 dans notre exemple.

Il y a des écouteurs spécifiques relatifs aux url en /image/* et /video/* et un écouteur par défaut qui gère le reste du trafic.

Un écouteur peut aussi être relatif à un port ou un schéma d’url.

A l’autre bout de la chaîne on trouve des pool principaux (backend pools). Le pool est la cible du trafic re-routé. Il existe de deux sortes:

  1. Groupe de VM identiques.
  2. Adresse IP ou nom FQDN

La deuxième option nous permet de router le trafic vers un Azure Scale Set par exemple.

Il y a des restrictions:

  • On ne peut pas mélanger les deux dans un même pool.
  • Les VM doivent appartenir au même réseau que l’AAG.

 

Dans notre exemple il y a 3 pools. L’un d’entre eux est du type IP. Chaque pool peut contenir plusieurs adresses ou plusieurs VM.

La liaison entre écouteur et pool est assurée par des règles de routage.

En résumé les éléments essentiels d’une AAG sont:

  • Pare feu (facultatif)
  • IP front end (IP pour accéder à l’AAG)
  • Ecouteurs
  • Règles
  • Http Settings
  • Pools
  • Sonde

L’équilibrage de charges

L’exemple précédent propose un routage basé sur le schéma de l’url. AAG est en effet un routeur dit de niveau 7, c’est à dire au niveau applicatif.

Azure propose 3 autres outils de ce genre.

  • AAG
  • Trafic Manager
  • Load Balancer

 

Quelles sont les différences?

Trafic Manager propose un routage de niveau DNS. Il sera utile par exemple pour déplacer du trafic vers des AAG déployées dans différentes régions.

AAG est un équilibreur de niveau 7. Il s’active donc au niveau application.

Load Balancer est un routage de niveau 4, il intervient donc au niveau HTTP.

Parmi les autres différences notez que si Load Balancer est gratuit, AAG est payant (à l’heure).  Les liens suivants donneront plus d’infos sur ces questions.

 

 

Création depuis le portail

La configuration complète d’une AAG est très longue. On peut y passer plusieurs heures essentiellement à attendre. C’est pourquoi dans la vraie vie il est préférable de scripter, la meilleure option est ARM qui garantit la consistance du déploiement.

On peut en théorie déployer AAG en mode classic, mais uniquement en PowerShell. Ce n’est pas la recommandation de Microsoft. Si vous avez des déploiements classic, il est possible de monter une AAG en ARM et via un peering la rendre accessible sur un VNET classic.

 

Nous allons créer une AAG depuis le portail Azure. Le portail permet de faire les créations de base, mais certaines fonctionnalités ne sont accessibles que via PowerShell.

On choisit Application Gateway dans New Resources. On fait CREATE:

Pour avoir de la haute dispo il faut choisir au moins 2 instances. On peut en avoir jusqu’à 10 par passerelle. Azure se charge de créer et gérer un load balancer.

 

Un abonnement standard permet de créer 50 AAG:

https://docs.microsoft.com/fr-fr/azure/azure-subscription-service-limits?toc=%2fazure%2fapplication-gateway%2ftoc.json#application-gateway-limits

 

SKU Size nous permet de choisir des dimensionnement adaptée au trafic à gérer.

On va laisser le niveau (tiers) à Standard. WAF (Web Application Firewall) permet d’activer le pare feu. Le pare feu implémente les règles OWASP. Laissons le de côté pour la démo. Si vous voulez savoir, l’écran ressemble à ceci:

 

 

On fait OK et on passe à l’étape suivante:

On commence par créer ou choisir un réseau virtuel existant.

Note: dans le dernier cas il faudra au préalable créer un sous réseau vide pour que AAG puisse s’y installer, sinon le réseau ne sera pas actif.

 

Disons que l’on en créé un nouveau:

On laisse les valeurs par défaut pour les autres options de cette étape, mais jetez y un œil tout de même:

  • On choisit une IP pour accéder à AAG. Elle est publique par défaut, mais elle peut être privée.
  • On configure l’écouteur par défaut.
  • On a une autre possibilité d’activer la fonction de pare-feu.

 

On fait OK, une page de résumé s’affiche, OK à nouveau, on attend quelques minutes.

C’est un peu long, mais à la fin on a ceci dans le groupe de ressources:

Jetons un œil sur les propriétés de l’AAG:

 

Overview donne accès à l’IP de la passerelle vers laquelle les clients devront se diriger. On remarque la possibilité de faire du monitoring et de créer une sonde de surveillance personnalisée (Health Probes) à la place de la sonde par défaut. Je ne vais pas aborder ces fonctionnalités dans cet article.

Note: La sonde par défaut pointe vers la page par défaut du site et attend un code HTTP 200. Si celui-ci n’est accessible qu’après s’être authentifié un 401 sera levé et la sonde marquera le pool comme défaillant avant de le désactiver. Dans ce cas il est nécessaire de créer une sonde personnalisée et de la faire pointer vers une page en accès anonyme ne servant qu’à cela.

 

Un écouteur (appGatewayHttpListener) et une règle (rule1) par défaut très généralistes ont aussi été créés:

Dans cette configuration l’AAG ne fait évidemment rien de passionnant, d’autant plus que le pool où tout est redirigé est vide!

On va donc essayer de rendre les choses plus intéressantes.

Une configuration plus intéressante

On va monter cette configuration et la tester:

Ils s’agit d’une passerelle avec redirection basée sur le chemin d’accès url.

 

Note: vous trouverez dans la bibliographie une version entièrement PowerShell de cet article.

Création d’une charge

On va créer deux VM pour alimenter nos pools. On n’oublie pas de les associer au réseau virtuel où se trouve l’AAG.

Note: dans la vie réelle on créée plutôt un Azure Scale Set que l’on associe à un pool de type IP.

 

Une fois les VM créées il faudra y installer IIS. Lancez pour cela le script suivant:

$publicSettings = @{ « fileUris » = (, »https://raw.githubusercontent.com/davidmu1/samplescripts/master/appgatewayurl.ps1″); « commandToExecute » = « powershell -ExecutionPolicy Unrestricted -File appgatewayurl.ps1 » }

Set-AzureRmVMExtension `
-ResourceGroupName AmethysteRG `
-Location westeurope `
-ExtensionName IIS `
-VMName pool1VM `
-Publisher Microsoft.Compute `
-ExtensionType CustomScriptExtension `
-TypeHandlerVersion 1.4 `
-Settings $publicSettings

En adaptant les parties en gras. Le résultat de sortie est le suivant:

La sortie d’écran montre l’exécution d’un script personnalisé. Ce script va configurer le site par défaut dans IIS:

 

 

La page Default.htm affiche le nom du serveur. On voit qu’il y a aussi deux répertoires images et video. Ces répertoires contiennent un fichier test.htm comme page par défaut. On pourra donc tester directement des urls comme:

 

Note: comme je l’ai déjà expliqué, on ne peut pas installer les VM dans le sous réseau de AAG, ceci est contrôlé par le portail:

 

Création des pool principaux (backend pool)

On se rend dans le menu dédié:

On fait ADD:

On créée deux pools:

On voit qu’il n’y a qu’une seule cible (VM ou IP) dans chaque pool (dernière colonne). On est libre d’en ajouter d’autres. Le pool par défaut est vide. Il ne servira pas dans la démo.

Les écouteurs

On a déjà un écouteur qui attend le trafic url à la racine. On va créer 2 écouteurs spécifiques aux urls suivantes:

Avec <ip> l’IP de l’AAG.

 

On clique sur le menu Listeners:

On peut construire deux types d’écouteurs:

  • Basic
  • Multi-site

Les écouteurs Multi-site, comme l’indique le nom, peuvent configurer plusieurs applications Web sur la même passerelle. On peut ainsi ajouter jusqu’à 20 sites. Chaque site est redirigé vers son propre pool principal selon le schéma:

Le routage se fait donc au niveau du domaine.

Les règles associées sont traitées dans l’ordre d’affichage des écouteurs par le portail. Il est donc recommandé de placer les écouteurs multi-site en premier.

 

Notez quelque chose d’important: Pour l’instant, une AAG ne supporte qu’une seule adresse IP publique. Donc les sites hébergés doivent répondre à cette IP unique.

J’ai fais jadis un tutoriel sur la façon dont on peut gérer cela dans IIS:

https://amethyste16.wordpress.com/2014/09/25/host-header-et-resolution-dadresse-web/

Il y a même un quizz pour les lecteurs joueurs!

 

On va choisir Basic.

Un écouteur est composé de deux éléments:

  • Une adresse IP
  • Un port

L’écouteur ne détient toutefois pas l’IP. On doit la configurer à part avant de créer l’écouteur:

 

 

On créée également les écouteurs videoListener et imageListener de la façon suivante:

Pour l’instant on n’a pas de règles, c’est le sujet de l’étape suivante.

Création des règles

Les règles assurent la liaison entre les flux et les pools principaux.

Comme d’habitude on se rend dans le menu associé:

On a deux options:

  1. Basic
  2. Path-Based

Path-Based créée une règle basée sur le chemin, c’est l’option qui va nous intéresser ici. On créée deux règles avec une configuration spécifique:

La liste déroulante Listener liste les écouteurs associés à aucune règle. Un écouteur ne peut être associé qu’à une seule règle. Cette liste peut donc très bien être vide.

 

Remarque: d’autres scénarios seraient possible comme un seul écouteur et une règle unique, mais avec plusieurs configurations au lieu d’une seule pour donner un schéma de route de ce genre:

 

Au final:

Premier test

On récupère l’IP de la passerelle. Dans mon cas il s’agit de: 51.144.50.190

On va tester l’url suivante:

http://51.144.50.190:8080/images/test.htm

 

J’obtiens ce message:

 

Lorsque AAG reçoit une erreur supérieure à 399 du serveur, il considère qu’il y a un problème le retire du pool. Au bout d’un certain temps il le reteste à nouveau et éventuellement le réintègre. Pour que cela fonctionne il faut évidemment une sonde.

Une sonde par défaut est créée, mais il est possible de créer une sonde personnalisée.

 

En cas de défaillance, une erreur 502 est levée donc. Oui, mais laquelle?

 

En fait il y a une erreur de typo dans la configuration de rules3, regardez:

 

Si vous vous souvenez de la description faite en début de chapitre, on attend pas un répertoire image, mais images (pluriel). Il faut juste rectifier.

Et tout rentre dans l’ordre:

Note: si vous cherchez plus d’infos sur le débogage de l’erreur 502:

https://docs.microsoft.com/en-in/azure/application-gateway/application-gateway-troubleshooting-502

 

 

Je vous laisse le soin de constater que les urls suivantes sont bien dispatchées sur les serveurs attendus et renvoient le comportement attendu:

Avant de se quitter

Je voudrai revenir sur la discussion au sujet des écouteurs multi-sites. J’avais évoqué la possibilité de créer des schémas de ce genre:

Autre détails, je ne me suis pas vraiment attardé sur le HTTP Settings. On s’est contenté d’utiliser la version créée par défaut et de l’associer à toutes les règles.

 

Dans la démo qui précède, en entrée, on a des flux sur des ports tels 8080 et 8081. Pourtant aucun binding IIS n’est programmé sur ces ports dans les VM du pool qui écoutent uniquement le port 80. C’est HTTP Settings qui fait cette liaison. Le réglage par défaut est le suivant:

On retrouve bien le comportement que nous venons de décrire.

 

 

Lorsque l’on créé une nouvelle règle:

 

 

Notez la case à cocher Configure redirection qui configure une redirection:

On peut faire par exemple une redirection 301 vers un autre écouteur ou vers un site externe.

Bibliographie

 

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s