Azure Pour les Nuls -- Focus Networking

De nos jours, de nombreuses entreprises utilisent les infrastructures Cloud publiques pour leurs besoins. ​Sur ces plateformes, la configuration réseau peut différer de ce que l'on connait des réseaux traditionnels. Cet article présente brièvement les principaux concepts de la configuration réseau dans Azure.​

Region & Availability Zone​

Les infrastructures Cloud sont composées de centres de données (Data center). C'est dans ces centres de données que sont hébergées les ressources (machines virtuelles par exemple) des clients. Dans la terminologie Azure, un ensemble de centres de données rapprochés correspond à une Zone de disponibilité (Availability Zone). Une Région est un ensemble de Zones de Disponibilité (ou de centre de données ne faisaient pas partie d'une Zone de Disponibilité) :

Les définitions disponibles sur le site de Microsoft :

Régions :

''Une région est constituée d'un ensemble de centres de données déployés dans un périmètre avec une latence définie et connectés via un réseau régional dédié à faible latence. En proposant plus de régions à l'échelle mondiale que les autres fournisseurs de cloud, Azure offre aux clients la possibilité de déployer des applications là où ils en ont besoin. Azure est mis en disponibilité générale dans 52 régions du monde et 4 autres régions seront bientôt annoncées.''​

Zones de disponibilité (Availability Zone) :

''Les zones de disponibilité sont des emplacements physiquement séparés au sein d'une région Azure. Chaque zone de disponibilité est composée d'un ou de plusieurs centres de données équipés d'une alimentation, d'un refroidissement et d'un réseau indépendants. Les zones de disponibilité permettent aux clients d'exécuter des applications stratégiques en bénéficiant d'une haute disponibilité et d'une réplication à faible latence.''

Une ressource est donc déployée dans une région. En général, on choisit la région par rapport à la localisation : plus une région est proche, plus il y a de chance que la latence soit faible. On peut aussi choisir une région pour le nombre de services disponibles dans celle-ci. Car toutes les régions ne proposent pas tous les services Azure. C'est le cas par exemple avec les régions ouvertes récemment.

Virtual Network

​

Azure Virtual Network, VNet, est l'équivalent du LAN que l'on connait dans les réseaux traditionnels. C'est dans le VNet que sont placées les principales ressources privées comme les machines virtuelles.

Comme pour les réseaux traditionnels, on définit un VNet en lui assignant une ou plusieurs plages d'adresses – Supernet, par exemple 10.0.0.0/16 – ainsi que d'autres attributs propres à Azure. Parmi ceux-ci, on retrouve l'attribut location. Cet attribut nous permet de choisir la région où se trouvera le VNet, par exemple west europe.

Un VNet contient un ou plusieurs Subnet, que l'on pourrait assimiler à des VLANs.

Il est donc nécessaire de créer un VNet avec ses Subnets pour pouvoir déployer des ressources privées telles que les machines virtuelles.

Infra fil rouge :

Pour une meilleure compréhension, nous allons illustrer une infrastructure dans Azure par un schéma que nous alimenterons au fil de l'article.

​Commençons donc par ajouter à notre schéma un VNet avec deux subnets :

Le VNet a pour nom VNet. Un seul plan d'adressage lui a été assigné – 10.0.0.0/16 – dans lequel on retrouve deux subnets qui sont dans les plans d'adressage suivants : Sub1 – 10.0.1.0/24 – et Sub2 – 10.0.2.0/24.​

Machine Virtuelle​

La machine virtuelle est la principale ressource utilisée pour exécuter le code d'une application. On parle de computing resource (d'autres moyens permettent d'exécuter une application : https://docs.microsoft.com/en-us/azure/architecture/guide/technology-choices/compute-comparison  -- par exemple Azure Function qui est une solution Serverless d'Azure).

Il est possible d'instancier des machines virtuelles de type Windows ou Linux. Les machines virtuelles sont créées à partir d'une image. Azure propose un large catalogue d'images publiques : des distributions Linux (Ubuntu, Suse Linux etc…), des machines de type Windows (Windows Server 2019, Windows 10 entreprise etc…) mais aussi des serveurs constructeurs comme par un exemple un routeur Cisco CSR1000V ou une base de donnée Oracle Database. Il est aussi possible d'importer sa propre image et d'instancier une machine virtuelle à partir de celle-ci. En plus de l'image, il est nécessaire de spécifier, entre autres et selon ses besoins, le dimensionnement de la machine virtuelle (nombre de cœurs, nombre de vCPU etc…), le type et le dimensionnement du stockage associé et les configurations réseau basiques. (https://docs.microsoft.com/en-us/azure/virtual-machines/ pour plus d'informations).

​Pour pouvoir communiquer, une machine virtuelle utilise une carte réseau : Network Interface ou NIC. Parmi les paramètres associés à une NIC, on retrouve :

• Name : nom de la carte réseau. Il faut savoir qu'une carte réseau est une ressource à part entière. On peut attacher une carte réseau à une machine virtuelle, mais elle reste transportable et indépendante de cette machine virtuelle : si on supprime la machine virtuelle, la carte réseau n'est pas supprimée est peut être réutilisée.
• Subnet : le subnet auquel la carte réseau est assignée.
• Private IP assignment : Le méthode d'attribution de l'adresse privée pour la carte réseau. Deux modes sont possibles : static ou dynamic. Dynamic pour une attribution automatique : l'adresse IP sera fournie automatiquement et prise dans le pool d'adresse disponible du subnet auquel la carte est associée. Static pour une attribution manuelle : ici c'est l'utilisateur qui choisit l'adresse IP.
  

​Comme cité plus haut, les machines virtuelles sont placées dans des subnets. En réalité, on ''connecte'' une carte réseau à une machine virtuelle et pour que celle-ci fasse partie du subnet auquel la NIC est assignée.​ Il est possible d'avoir plusieurs machines virtuelles dans un même subnet. Il est aussi possible qu'une machine virtuelle fasse partie de plusieurs subnets en lui attachant plusieurs NICs.

Infra fil rouge :

Sur notre schéma, nous ajoutons une machine virtuelle Ubuntu dans chaque subnet :

Note : Pour plus de clarté, les NICs ne sont pas représentées.​

System routes​

Afin d'acheminer le flux d'une machine virtuelle vers la bonne destination, les NICs vont se référer à des routes. Prenons l'exemple d'une machine virtuelle avec une seule NIC attachée. Lorsque cette machine envoie du trafic vers une destination, par exemple une machine dans un autre subnet, la NIC va analyser sa table de routage, sélectionner la meilleure route pour ce trafic, et ensuite envoyer le trafic vers la destination indiquée par la route.

Par défaut, Azure assigne aux subnets, et donc aux NICs associées à ceux-ci, des routes appelées system routes. Ces routes sont les suivantes :

Comme nous pouvons le voir, une route est définie par trois paramètres :

• Source : indique d'où provient la route. Default indique ici que c'est une system route. Nous verrons plus bas qu'il est possible pour un administrateur de rajouter des routes, dans quel cas la source sera User.
• Address prefixes : le plan d'adressage auquel la route fait référence.
• Next hop type : Différents types de next hop sont disponibles dans Azure :
• Virtual Network lorsque l'on veut utiliser le VNet pour acheminer le trafic. Ceci est possible si la destination entre dans l'un des plans d'adressage du VNet.
• None si l'on veut que le trafic ne soit pas acheminé et donc droppé.
• Internet lorsque l'on veut utiliser une sortie internet d'Azure. Dans ce cas, Azure assigne dynamiquement une IP publique pour le trafic sortant en appliquant du Source NAT. Pour le trafic vers internet, ce mode n'est pas recommandé car il n'offre pas de visibilité. On retiendra tout de même qu'il est possible à une machine d'accéder à internet dès sa création et sans aucune configuration particulière.
• Virtual Appliance lorsque l'on veut que le trafic passe par une machine ou un Load Balancer. Nous verrons par exemple qu'il est possible de forcer le trafic à passer par une machine virtuelle faisant office de Firewall.
• Virtual Network peering : nous verrons plus bas qu'il est possible d'interconnecter des VNets via le VNet peering. Ces deux pourront alors communiquer sans passer par internet. Les routes apprises par le VNet peering ont pour next hop type Virtual Network peering.
• Virtual network service endpoint : nous verrons plus bas qu'il est possible d'accéder à des services Azure publics, comme par exemple Azure SQL, sans passer par internet. Ceci est possible grâce au service endpoint. Les routes apprises par le service endpoint ont pour next hop type Virtual network service endpoint.
  

​Si l'on considère qu'aucune restriction (présence de firewall au niveau du système etc…) n'est appliquée, alors les system routes par défaut permettent les communications suivantes :

• Toutes les machines virtuelles au sein d'un VNet peuvent se joindre.
• Toutes les machines peuvent aller sur internet (trafic initié par la machine).
• Le trafic vers les ranges 10.0.0.0/8, 192.168.0.0/16 et 100.64.0.0/10 ne sera pas acheminé et donc droppé.
  

Note : ces routes seront automatiquement annulées dès lors que ces plans d'adressage ont été choisis pour le VNet. Par exemple, un VNet avec le plan d'adresse 10.0.0.0/8 n'aura pas la route empêchant communication avec le range 10.0.0.0/8.

Infra fil rouge :

Appliquées à notre infra fil rouge, les system routes permettraient aux deux VMs de communiquer entre elles et d'aller sur internet :​​

User-defined routes

Il est possible de définir des routes en plus des routes systèmes. Ces routes définies par l'utilisateur sont renseignées dans une ressource route table et sont appelées User Defined routes ou UDR. Par exemple, on peut utiliser une UDR pour forcer le trafic allant vers internet à passer par une machine faisant office de firewall.

Les User Defined Routes sont les routes qui ont la plus grande priorité. S'il existe un conflit entre une route définie par l'utilisateur et une route système, alors sera valide seulement la route définie par l'utilisateur.

​L'ordre de sélection pour une route est le suivant :

1. User defined Route
2. BGP Route : Nous verrons plus bas qu'il est possible d'apprendre des routes par BGP notamment via une Virtual Network Gateway. Les routes apprises par BGP sont préférées aux routes système sauf dans certains cas, à savoir : les routes système apprises via Virtual Network services endpoint et Virtual Network peering ainsi que la route système Virtual Network.
3. System routes​

Une route table est une ressource à part entière. Une fois créé, on peut l'assigner à un ou plusieurs subnet.

Infra fil rouge :

Sur notre schéma mis à jour, nous avons une nouvelle machine virtuelle qui est en réalité un Firewall (plusieurs solutions de NextGen Firewall sont disponibles dans le catalogue Azure). Cette machine est nommée VM-FW et est placée dans un nouveau subnet nommé SubFW.

​Nous ajoutons aussi une table de routage (route table) dans laquelle nous configurons une route qui spécifie que tout trafic allant vers le plan d'adressage 10.0.0.0/16 doit passer par la Virtual Appliance VM-FW qui a pour adresse IP 10.0.3.4. Cette route table est assignée aux subnets Sub1 et Sub2.

Le trafic entre VM1-1 et VM1-2 passera donc par le Firewall VM-FW pour filtrage.

Public IP

Public IP, comme son nom l'indique, est une ressource correspondant à une adresse IP publique.

On utilise une public IP pour la communication avec l'extérieur et à travers internet. Une public IP peut être assignée à différentes ressources : les machines virtuelles, les Internet-facing load balancer, les VPN Gateways et les Application gateways.

Il existe deux types de public IP : Basic et Standard. Parmi les caractéristiques qui différencient une public IP de type Standard à une public IP de type Basic, on retrouve :

• Zone redundancy : les public IP Standard sont redondantes au niveau Availabilty zone.
• Allocation Method : une public IP Standard est toujours statique.
• Les public IP Standard sont, par défaut, protégées des flux inbound (flux entrant provenant d'internet). Pour pouvoir passer, le flux doit être explicitement autorisé via une Network Security Group.​

Network Security Group

Network Security Group ou NSG permet d'appliquer du filtrage sur le trafic provenant/allant des/vers les ressources.

Les NSGs sont associées à des subnets ou des NICs et contiennent des rules. Ces rules définissent les règles à appliquer sur le trafic. Elles se configurent de la sorte :

• Name : le nom de la rule,
• Priority : la priorité donnée à la rule. Cette priorité s'exprime par un nombre entre 100 et 4096. Les rules ayant le nombre le plus petit ont la plus grande priorité.
• Source or destination : pour renseigner la source/destination, il est possible de renseigner un subnet dans le format standard CIDR (exemple : 10.0.0.0/8 ou 10.1.2.3/32) mais aussi un service tag ou une application security group. Un service tag correspond à un service Azure public, par exemple Azure SQL. Une application security group est un objet qui regroupe un ensemble de machines virtuelles.
• Protocol : le protocole peut être TCP, UDP, ICMP ou Any.
• Direction : inbound pour le trafic entrant, outbound pour le trafic sortant.
• Port Range : le numéro du port (par exemple 80). Il est possible de renseigner une plage (par exemple 14000-14999 pour désigner tous les ports entre 14000 et 14999)
• Action : Allow pour autoriser, Drop pour bloquer.​
  

Les rules sont évaluées par priorité. Si une règle A de priorité 100 autorise ce qu'une règle B de priorité 150 bloque, alors c'est la règle A qui sera appliquée.

Les NSG ont aussi des rules par défaut qui sont automatiquement ajoutées à la création. Parmi celle-ci, on retrouve la règle DenyAllInbound :

Cette règle bloque tout trafic entrant et a une priorité de 65500. Une autre règle par défaut, AllowVNetInBound, vient au-dessus avec une meilleure priorité : 65000. Cette règle autorise le trafic entrant provenant d'une ressource qui est à l'intérieure du VNET :

Il est possible ensuite d'ajouter des règles pour autoriser ou bloquer un trafic spécifique. Par exemple, autoriser le trafic entrant et provenant du VNET, sur le port TCP 1433 (SQL) et à destination du subnet contenant les machines virtuelles qui hébergent les bases de données.

Un autre point important est l'ordre dans lequel les NSGs sont évaluées dans le cas où le trafic traverse plus d'une NSG. Ceci est possible car comme nous l'avons vu plus haut, une NSG peut être associée à un subnet et à une NIC. Dans l'exemple ci-dessous, la machine VM1 est attachée à une NIC elle-même associée à une NSG, nommée NSG2. La machine VM1 est aussi dans le Subnet1 qui est associé à une autre NSG, NSG1 :

Dans ce cas, le trafic VM1 sera évalué de la manière suivante :

• Le trafic Inbound – trafic provenant de l'extérieur du subnet et allant vers VM1 – sera évalué dans un premier temps par NSG1 et ensuite par NSG2.
• Le trafic Outbound – trafic provenant de VM1 et allant vers l'extérieur du subnet – sera évalué dans un premier temps par NSG2 et ensuite par NSG1.
  

Infra fil rouge :

Apportons les modifications suivantes à notre infra :

• Les machines virtuelles VM1-1 et VM2-2 constituent un site web basique, la première étant le serveur frontend et la seconde le serveur backend.
• Le serveur frontend doit être accessible depuis internet. Une adresse IP publique est donc attachée à la NIC de VM1-1.
• L'accès aux serveurs est protégé par des NSG configurés au niveau du subnet. Par exemple, la NSG de Sub1 contient une rule autorisant le trafic venant d'Internet et à destination de VM1-1 sur le port 80 (http)

Azure Load Balancer

Un Load Balancer, comme son nom l'indique, permet de distribuer une charge partagée entre plusieurs serveurs. Par charge, on pense au traitement du trafic. Un exemple simple est un site web installé sur plusieurs machines se trouvant en aval d'un load balancer. Les requêtes clients arrivent sur le load balancer qui se charge de les distribuer à ces machines :

La ressource Azure Load Balancer opère au niveau de la couche 4. Pour un load balancer applicatif, il existe la ressource Application Gateway.

Azure Load Balancer peut être public (public) ou privé (internal). Public Azure Load Balancer est utilisé lorsque que l'on souhaite pouvoir assigner à celui-ci des adresses IP publiques qui pourront donc être joignables depuis internet. Le load balancer se charge ensuite de faire la translation pour acheminer le trafic venant d'internet vers les machines virtuelles sur leur adresses privées. L'Internal Azure Load Balancer n'accepte pas d'adresse IP publique.

Au niveau de la configuration, les principaux paramètres sont les suivants :

• Frontend IP : une adresse IP qui est portée par le load balancer.
• Backend pools : un objet pool représente un ensemble de machines. En général, ces machines fournissent le même service. Le load balancer distribue une charge donnée entre les membres d'un backend pool. Un load balancer peut avoir plusieurs backend pools.
• Health probes : Le load balancer vérifie constamment si les membres des backend pools sont joignables, et ceci afin de ne pas envoyer de la charge à une machine qui n'est pas opérationnelle. Pour faire cette vérification, le load balancer utilise des health probes. En pratique, une probe va envoyer une requête sur un chemin et à des intervalles donnés. Par exemple, on peut configurer une probe pour qu'elle envoie une requête HTTP GET sur le chemin /index.html. Les machines visées par la probe seront considérées comme fonctionnelles si elles répondent à la requête comme attendu.
• Load Balancing rules : Une rule définit comment le trafic est distribué aux machines. On crée une rule en indiquant, entre autres :
• Le backend pool vers lequel le trafic sera acheminé.
• La frontend IP qui correspond à l'adresse IP partagée et portée par le service offert par les machines du pool. En d'autres termes, les clients devront communiquer avec cette adresse pour atteindre les machines du pool concernée.
• Port qui est le port sur lequel le load balancer écoutera. Backend port qui est le port sur lequel les machines du pool écoutent et donc sur lequel le load balancer acheminera le trafic.
• La health probe qui permettra de définir si les machines du pool sont fonctionnelles.
• Inbound NAT rules : pour configurer des règles de NAT.
  

Il est important de noter qu'il existe en réalité deux types de load balancer : le Basic Load Balancer et le Standard Load Balancer. Le Basic n'offre pas toutes les possibilités du Standard et n'est pas conseillé pour un déploiement en production. Parmi les avantages que le type Standard apporte sur le type Basic, il y a la possibilité d'utiliser la fonctionnalité HA Ports afin de ne pas avoir à créer une rule pour chaque port (pour plus d'informations : https://www.petri.com/comparing-basic-standard-azure-load-balancers).

En termes de sécurité, le Basic Load Balancer se repose sur les NSG en place pour savoir si le trafic est autorisé. Si le trafic à destination d'une machine ne rencontre aucune NSG, alors ce trafic sera bien acheminé. A l'inverse, le Standard Load Balancer est zero trust. Il est donc nécessaire d'autoriser explicitement le trafic via une NSG.

Azure Application Gateway

Azure Application Gateway est un load balancer applicatif qui opère au niveau 7, à la différence de Azure load balancer qui opère au niveau 4. Une Application Gateway va donc pouvoir se baser sur des attributs HTTP afin de déterminer la destination vers laquelle le trafic sera acheminé.

Sur l'exemple ci-dessous, une Application Gateway est placée en amont de deux backend pools, chacun contenant deux serveurs. L'Application Gateway est aussi le premier point d'entrée pour l'accès au site contoso.com, ce qui signifie que lorsqu'un client envoie une requête à destination de ce site, alors elle sera acheminée vers cette Application Gateway. Cette requête sera envoyée vers l'une des machines faisant partie d'un des deux backend pools. Pour cela, l'Application Gateway analysera l'URL de destination renseignée dans la requête : si l'URL répond au format www.contoso.com/images/* alors la requête sera envoyée vers une machine du pool ImageServerPool, et si l'URL répond au format www.contoso.com/video/* alors ce sera vers une machine du pool VideoServerPool que la requête sera envoyée.​

La création de telles règles est possible grâce à la fonctionnalité URL-based routing. D'autres fonctionnalités sont supportées par Application Gateway, comme par exemple Secure Sockets Layer (SSL/TLS) termination qui permet de reporter la tâche de chiffrement/déchiffrement du trafic sur   l'Application Gateway. Pour plus d'informations sur les fonctionnalités supportées : https://docs.microsoft.com/fr-fr/azure/application-gateway/features

Infra fil rouge :

Un second site web est venu s'ajouter dans notre infra. Les deux sont accessibles depuis la même adresse IP publique. Les deux sites ont des serveurs frontend distincts. Afin de rediriger les requêtes des clients vers le bon serveur frontend, nous utilisons une Application Gateway. Application Gateway qui assurera aussi la terminaison SSL.

Le service Backend, utilisé par un des deux sites a été redimensionné pour raison de performance et de résilience. Ce sont maintenant trois serveurs backend qui assurent le service. Afin d'assurer une disponibilité du service backend sur la même adresse IP et d'assurer un partage de charge sur les trois serveurs, nous utilisons un Internal Load Balancer.

VNET Peering

Jusqu'ici, nous avons vu que les ressources présentes dans un VNet peuvent communiquer entres elles et peuvent aussi communiquer avec des ressources dans internet. Nous allons voir qu'il est possible d'interconnecter un VNet avec un autre VNet, de telle sorte que les ressources présentes dans les deux VNETs pourront communiquer directement via leurs adresses privées en utilisant le réseau backbone Microsoft et donc sans passer par internet.

Pour cela, la manière la plus simple est d'utiliser le VNET Peering :​

Sur le schéma ci-dessus, le VNET Hub VNet est connecté aux VNet A et VNet B via des VNet peering. Les ressources du VNet A peuvent donc atteindre directement les ressources du Hub VNet : l'activation du VNet peering engendre une mise à jour des routes pour que les ressources sachent communiquer avec les ressources du VNet appairé. En pratique, cela se traduit par la présence de routes sur les NICs avec un next hop type : Virtual Network peering.

On retrouvera le même comportement entre VNet B et HUB VNet. En revanche, ceci n'est pas vrai entre VNet A et VNet B. En effet, ces deux VNets ne se ''voient'' pas car le VNet Peering n'est pas transitif. Pour que VNet A et VNet B puissent communiquer, deux solutions s'offrent à nous : activer un peering entre VNet A et VNet B ou bien utiliser des UDRs pour passer par une machine présente dans Hub VNet qui assurera le routage entre les deux VNets (Service chaining : https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-network-peering-overview#service-chaining) comme c'est le cas sur le schéma.

Sur le schéma, on remarque l'information ''Allow Gateway Transit''. Ceci indique que le VNET B utilise la Virtual Network Gateway (qui est de type VPN) du Hub VNet. Une Virtual Network Gateway, que nous verrons plus bas, permet entre autres d'établir la connexion avec des réseaux privées qui ne sont pas dans Azure. Le VNet B saura donc communiquer avec des réseaux externes en utilisant la Virtual Network Gateway de Hub VNet.

Virtual Network Gateway

Comme cité précédemment, il est possible d'interconnecter ses ressources privées Azure présentes dans un VNET avec des réseaux/ressources se trouvant en dehors du VNet en utilisant une Virtual Network Gateway. Il y a deux types de Virtual Network Gateway : VPN Gateway et Express Route Gateway.

VPN Gateway:​

Une VPN Gateway permet d'établir une connexion à travers internet et via un tunnel chiffré IPSec :

Sur le schéma ci-dessus, les sites on-premises (sites locaux) LocalSite1 et LocalSite2 peuvent communiquer avec les ressources présentes dans le VNet 1 à travers les tunnels IPSec construits entre la VPN Gateway et les équipements réseaux (routeur ou firewall par exemple) présents sur les sites on-premise.

​Il est aussi possible d'utiliser une VPN Gateway pour établir la connexion entre deux VNets. Dans ce cas, le tunnel sera monté entre deux VPN Gateways. Cette méthode est une alternative au VNet peering que l'on a vu plus haut :

Plusieurs modèles de VPN Gateway sont disponibles. D'un modèle à un autre varie ,entre autres, la bande passante maximum supportée, le nombre maximum de tunnels configurables, la compatibilité ou non avec protocole de routage BGP, ainsi que la redondance au niveau des Zones Azure (voir https://docs.microsoft.com/fr-fr/azure/vpn-gateway/vpn-gateway-about-vpngateways#benchmark)

Le tableau sous https://docs.microsoft.com/fr-fr/azure/vpn-gateway/vpn-gateway-about-vpn-devices#devicetable indique les modèles de routeurs/firewalls officiellement compatibles avec VPN Gateway. Pour chaque modèle, le tableau informe sur la version minimum supportée, mais aussi sur la compatibilité avec le mode PolicyBased ou RouteBased ( explication des deux modes ici : https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/vpn-gateway/vpn-gateway-connect-multiple-policybased-rm-ps.md#about-policy-based-and-route-based-vpn-gateways ).

Express Route Gateway :

Comme pour la VPN Gateway, l'Express Route Gateway permet de connecter ses ressources Azure à des ressources on-premise, à la différence que la connexion ne se fera pas via internet, mais via une connexion privée – par exemple une connexion de type MPLS. Cette connexion privée est fournie par un opérateur (liste des opérateurs compatibles https://docs.microsoft.com/fr-fr/azure/expressroute/expressroute-locations#partners). Les VNets seront donc vus comme des sites distants (dans le cas d'une connexion de niveau 3) ou comme une continuité du LAN on-premise (dans le cas d'une connexion niveau 2). Le service qui représente la connexion entre Azure et le site client est appelé Express Route.

L'Express Route permet aussi d'accéder aux services Azure publics (Azure SQL, Office 365 etc…) :

Une fois la connexion établie, il est possible d'activer le Private Peering (en bleu clair) qui permet d'accéder aux ressources privées dans Azure ainsi que le Microsoft Peering (en orange) qui permet d'accéder aux services Azure publics. En pratique, ceci se traduit par l'échange de routes entre les routeurs Microsoft (Microsoft Edge sur le schéma) et les routeurs de l'opérateur assurant la connexion. A travers le public Peering seront échangées les routes privées, et à travers le Microsoft Peering seront échangées les routes publiques. Concernant celles-ci, il est possible d'appliquer des filtres pour sélectionner les services publics que l'on souhaite atteindre via l'Express route.

L'Express route permet donc d'avoir une connexion privée et dédiée pour pouvoir accéder aux ressources Azure. Une connexion privée offre généralement de meilleures performances par rapport à une connexion via internet mais aussi plus de sécurité et une meilleure fiabilité.

Comme pour la VPN Gateway, il existe plusieurs modèles d'Express Route Gateway : Standard, High Performance et Ultra Performance (https://docs.microsoft.com/fr-fr/azure/expressroute/expressroute-about-virtual-network-gateways#aggthroughput). Il existe aussi pour le service Express Route deux qualités de service : Express Route et Express Route Premium. Le niveau premium donne plus de possibilités, comme par exemple la possibilité d'établir une connexion entre un VNet présent dans une région différente que celle du circuit Express Route (voir https://docs.microsoft.com/fr-fr/azure/expressroute/expressroute-faqs#expressroute-premium).

Au niveau du VNet, il est possible d'avoir une Virtual Network Gateway de chaque type : une Express Route Gateway et une VPN Gateway. Comme nous l'avons vu plus haut, il est possible, pour un VNet donné, d'utiliser la gateway d'un VNet appairé via VNet peering. Les Virtual Network Gateways sont installées dans un subnet spécifique appelé Gateway Subnet.

​​Virtual Network service endpoint

Un VNet service endpoint permet d'établir une connexion privée entre un VNet et un service public Azure. Le trafic restera donc dans le réseau interne Azure et ne passera pas par internet :

Sur le schéma au-dessus, le subnet 10.1.1.0/24 a une connexion directe avec le service public Azure Storage, ce qui signifie que la machine présente dans le subnet pourra accéder au compte Storage sans passer par internet. Comme pour l'Express Route, l'un des principaux avantages à utiliser un service endpoint est de bénéficier d'un chemin optimal pour atteindre un service public Azure.

Tous les services publics Azure ne sont pas disponibles avec le service endpoint. La liste (évolutive) est consultable à ce lien : https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-network-service-endpoints-overview.

Infra fil rouge :

​L'architecture du site ayant évolué, les serveurs de backend ont été remplacés par des instances PaaS Azure SQL. Ces instances de base de données sont consultées par les serveurs frontend. Pour une meilleure performance, nous utilisons le service endpoint afin que les requêtes vers les instances SQL traversent exclusivement le réseau Microsoft :

Azure Private Endpoint & Azure Private Link

En activant service endpoint pour un subnet, on rend donc possible, pour les ressources privées dans le subnet, l'accès à un service Azure public sans besoin de passer par internet. En pratique, ceci se traduit par l'apprentissage de route à destination du service par les NICs attachées au subnet. Ces routes auront pour next hop : VirtualNetworkServiceEndpoint et auront pour destination les subnet publics correspondant aux services.

Un autre moyen d'accéder à des ressources Azure publiques est l'utilisation de Private Endpoint et Azure Private Link.

Private Endpoint, via Azure Private Link, permet d'associer un service Azure public, a une adresse privée appartenant au VNET :

Prenons pour exemple une instance de base données Azure SQL, qui est un service Azure public PaaS. Il est possible d'établir un lien direct entre une adresse IP privée du VNET et cette instance SQL :

• Private Endpoint correspondra à une NIC. NIC à laquelle sera assignée une adresse IP privée du VNET, par exemple 10.0.1.10.
• Azure Private Link fait le lien entre la NIC Private Endpoint et l'instance SQL.

En d'autres termes, depuis le VNET en question, pour accéder à l'instance Azure SQL, il suffit de joindre l'adresse IP 10.0.1.10.

Par rapport à Azure Service Endpoint, Azure Private Endpoint apporte certains avantages en termes de sécurité. En effet, si l'on reste sur l'exemple d'Azure SQL, l'accès depuis le VNET via Azure Private Endpoint ne sera possible que vers des instances données comme le montre le schéma ci-dessous :

Avec Azure Service Endpoint, la réalité est autre car on apprend les routes publiques globales. Azure Private Endpoint offre donc une protection contre l'exfiltration de données.

Le fait que le service désiré soit représenté par une adresse IP privée connue et statique présente aussi un avantage dans le cas où le trafic doit passer par un firewall. En effet, il est plus aisé de gérer des règles donnant accès à une adresse IP connue, plutôt qu'une liste dynamique d'un ensemble de subnets larges.

Jusqu'ici, nos exemples parlaient d'utiliser d'Azure Private Link et Azure Private Endpoint pour accéder à des ressources Azure publiques. Il faut savoir qu'il est aussi possible ''d'attacher'' un Azure Private Link à une ressource privée pour pouvoir la rendre disponible à d'autres clients Azure. Pour cela, il faut que la ressource que l'on veut rendre disponible soit derrière un Azure Load Balancer de type standard :

Dans l'exemple ci-dessus, un client, identifié comme Provider, a déployé une application. Cette application est hébergée dans des ressources (Machines Virtuelles ou conteneurs par exemple) se trouvant derrière un Standard Azure Load Balancer. Après avoir créé un Private Link, et l'avoir attaché au Standard Load Balancer, le Provider partage une donnée qui permettra à un autre utilisateur Azure de pouvoir accéder à l'application via un Private Endpoint qui correspondra à une IP privée prise dans le VNET de ce dernier.