Azure VPN Gateway est un service plébiscité pour sa sécurité, sa redondance et la simplicité de son intégration native dans Microsoft Azure. Cependant, pour des projets de plus petite envergure ou lorsque vous disposez déjà de compétences réseau et d’infrastructures maîtrisées, il peut être judicieux d’explorer des solutions open source ou des distributions spécialisées. C’est dans cette optique que nous verrons comment déployer un VPN OPNsense sur Azure.
Comment fonctionne un tunnel IPsec ?
Les tunnels IPsec se mettent en place en deux grandes étapes :
Phase 1 – IKE (Internet Key Exchange)
Les deux extrémités (pair A et pair B) négocient d’abord une association de sécurité IKE SA.
Elles s’authentifient mutuellement (certificat, clé pré-partagée, etc.) et conviennent des paramètres de chiffrement (algorithme, mode DH, durée de vie des clés).
À l’issue, un canal chiffré et authentifié est établi pour protéger les échanges de la phase 2.
Phase 2 – IPsec SA
Dans ce canal sécurisé, les pairs négocient plusieurs Security Associations secondaires (appelées Child SA), qui définiront le chiffrement et l’intégrité du trafic utilisateur.
Elles conviennent des sous-réseaux à protéger, des ports et protocoles autorisés, puis génèrent les clés de session IPsec.
Une fois la Child SA montée, le tunnel est opérationnel : tout paquet envoyé vers le sous-réseau distant est chiffré et encapsulé dans IPsec.
Qu’est-ce qu’une passerelle VPN Azure ?
Une passerelle VPN Azure (Azure VPN Gateway) agit comme un point de terminaison chiffré permettant d’établir des tunnels IPsec/IKE entre votre réseau on-premises (ou vos clients VPN individuels) et vos réseaux virtuels Azure.
Elle prend en charge plusieurs scénarios :
Site-à-Site (connexion permanente entre votre datacenter et Azure)
Point-à-Site (accès distant des utilisateurs)
VNet-à-VNet (liaison sécurisée entre réseaux virtuels)
Quels sont les SKUs disponibles pour les passerelles VPN Azure ?
Les passerelles VPN Azure se déclinent en versions classiques et zone-redondantes :
Génération
SKU
Tunnels S2S/VNet-to-VNet
Connexions P2S (IKEv2/OpenVPN)
Débit agrégé
BGP supporté
Zone-redondant
Gen 1
Basic
Max. 10
Non supporté
100 Mbps
Non
Non
VpnGw1
Max. 30
Max. 250
650 Mbps
Oui
Non
VpnGw2
Max. 30
Max. 500
1 Gbps
Oui
Non
VpnGw3
Max. 30
Max. 1000
1,25 Gbps
Oui
Non
VpnGw1AZ
Max. 30
Max. 250
650 Mbps
Oui
Oui
VpnGw2AZ
Max. 30
Max. 500
1 Gbps
Oui
Oui
VpnGw3AZ
Max. 30
Max. 1000
1,25 Gbps
Oui
Oui
Gen 2
VpnGw2
Max. 30
Max. 500
1,25 Gbps
Oui
Non
VpnGw3
Max. 30
Max. 1000
2,5 Gbps
Oui
Non
VpnGw4
Max. 100*
Max. 5000
5 Gbps
Oui
Non
VpnGw5
Max. 100*
Max. 10000
10 Gbps
Oui
Non
VpnGw2AZ
Max. 30
Max. 500
1,25 Gbps
Oui
Oui
VpnGw3AZ
Max. 30
Max. 1000
2,5 Gbps
Oui
Oui
VpnGw4AZ
Max. 100*
Max. 5000
5 Gbps
Oui
Oui
VpnGw5AZ
Max. 100*
Max. 10000
10 Gbps
Oui
Oui
Combien coûte les passerelles VPN Azure ?
Le prix de la passerelle VPN dépend du SKU choisi. Voici quelques tarifs :
SKU
Prix mensuel estimé (€)
Basic
22,95 €
VpnGw1
121,11 €
VpnGw2
312,33 €
VpnGw3
796,77 €
VpnGw4
1 338,57 €
VpnGw5
2 326,56 €
Attention : ces prix correspondent uniquement au coût de compute de la passerelle (744 heures d’utilisation par mois) et n’incluent pas les frais de transfert de données sortantes.
L’ancien VPN de type basique présentait un tarif particulièrement attractif :
Le service le moins cher est maintenant le SKU VpnGw1, mais le prix est plus élevé :
En comparaison, le service OPNsense déployé via une VM affiche un coût un plus faible :
Voici également le tarif appliqué pour le VPN OPNsense pour un engagement d’un an sur la machine virtuelle :
Qu’est-ce que la passerelle VPN OPNsense sur Azure ?
OPNsense VPN est la solution de création de tunnels sécurisés intégrée à OPNsense, un pare-feu/routeur open-source basé sur FreeBSD. Elle prend en charge plusieurs protocoles majeurs :
IPsec : idéal pour les liaisons site-à-site ou les connexions distantes, avec négociation IKEv1/IKEv2, clés pré-partagées ou certificats, et prise en charge de BGP pour le routage dynamique.
OpenVPN : pour les accès distants sur TCP ou UDP, avec authentification par utilisateur, certificats ou serveur RADIUS, et options de chiffrement AES-GCM.
WireGuard : un protocole moderne, léger et performant, offrant des temps de mise en place réduits et une empreinte cryptographique simplifiée.
Peut-on déployer la passerelle VPN OPNsense sur Azure ?
Oui, il est tout à fait possible de déployer OPNsense dans Azure en tant que machine virtuelle. Afin de voir si cela marche vraiment, voici les différentes étapes que nous allons suivre sur un environnement de test :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Pour réaliser cet exercice, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Pour tester mon environnement, j’ai également provisionné les deux machines virtuelles suivantes pour simuler des ressources opposées :
J’y ai également mis en place une passerelle Bastion :
Enfin, j’ai également déployé une passerelle VPN Azure pour tester le tunnel :
Commençons par créer une nouvelle machine virtuelle Azure contenant la passerelle VPN OPNsense.
Etape I – Préparation de la machine virtuelle OPNsense :
Pour cela, cliquez sur le lien GitHub suivant pour déployer le template ARM sur votre environnement Azure : https://github.com/dmauser/opnazure
Sélectionnez ensuite le scénario OPNsense souhaité et renseignez les informations de base, puis cliquez sur Suivant :
Conservez ou ajustez la taille de la VM, puis validez en cliquant Suivant :
Constatez la présence de deux sous-réseaux, Trusted et Untrusted, puis lancez la validation Azure :
Une fois la validation réussie, le déploiement des ressources démarre automatiquement :
Patientez quelques minutes, puis cliquez ici pour accéder aux ressources créées :
Copiez les adresses IP privées et publiques de la VM OPNsense :
Modifiez la règle de pare-feu pour autoriser l’accès HTTPS à la VM :
Vérifiez la présence du sous-réseau Trusted, puis copiez son plan d’adressage :
Connectons-nous maintenant à notre console d’administration OPNsense pour avancer sur la configuration de notre tunnel.
Etape II – Configuration d’OPNsense :
Ouvrez votre navigateur, collez-y l’IP publique de la VM OPNsense, renseignez les identifiants ci-dessous, puis cliquez sur Login :
Login : root
Mot de passe : opnsense
Changez immédiatement le mot de passe pour des raisons de sécurité :
Commencez par créer une clé partagée destinée au handshake IPsec :
Dans la section VPN IPsec, cliquez-ici pour créer une nouvelle connexion et choisissez vos propositions de chiffrement :
Renseignez les champs requis : l’IP locale de la VM OPNsense et l’adresse IP publique de la passerelle VPN Azure :
Ajoutez une authentification locale en réutilisant la clé partagée, puis enregistrez :
Répétez l’opération pour l’authentification distante, puis sauvegardez :
Éditez ensuite la section Child en renseignant les plans d’adressage respectifs, puis cliquez sur Enregistrer :
Cliquez sur Sauvegarder :
Enfin, cliquez sur Appliquer pour finaliser la configuration IPsec :
Dans la section pare-feu, constatez la règle sortante déjà préconfigurée :
Créez une nouvelle règle entrante pour autoriser l’accès depuis la passerelle VPN Azure :
Activez cette nouvelle règle pare-feu :
Sur le pare-feu OPNsense, ajoutez les règles nécessaires pour établir la liaison IPsec dans la section WAN :
La configuration OPNsense est maintenant terminée. La prochaine étape consiste à configurer la passerelle VPN Azure pour se connecter à la première.
Etape III – Configuration de la passerelle VPN Azure :
Copiez l’adresse IP publique de la passerelle VPN Azure :
Dans le Network Security Group de votre VM OPNsense, créez une règle pour autoriser l’IP de la passerelle VPN Azure :
Créez une Local Network Gateway en renseignant l’IP publique de votre passerelle VPN OPNsense et le plan d’adressage du sous-réseau Trusted :
Établissez ensuite la connexion VPN Azure pour finaliser l’interconnexion entre les deux passerelles :
Collez la clé d’authentification, puis enregistrez la configuration de la connexion :
Associez également une table de routage au sous-réseau Trusted, en y incluant le préfixe 0.0.0.0/0 afin de diriger tout le trafic via la VM OPNsense :
Tout est maintenant en place pour le test de connectivité entre nos deux machines virtuelles.
Etape IV – Test de la connexion VPN :
Retournez dans le menu des connexions IPsec OPNsense, puis cliquez ici pour démarrer la connexion IPsec côté OPNsense :
Attendez quelques secondes jusqu’à l’apparition de la Phase 2 de la connexion IPsec :
Une fois la Phase 2 affichée, cliquez ici pour visualiser le journal contenant les événements IPsec :
Constatez l’apparition des différents états de la connexion entre les deux passerelles VPN :
Vérifiez l’apparition de Security Associations dans la base de données IPsec :
Vérifiez l’apparition de Security Policies dans la base de données IPsec :
Retournez sur le portail Azure et observez le changement de statut de la connexion VPN Azure :
Démarrez les deux machines virtuelles de test pour valider la liaison :
Sur les deux VM de test, désactivez temporairement la règle de pare-feu ICMP suivante pour autoriser le ping :
Effectuez des tests de ping réciproques entre les deux machines virtuelles :
Interrompez la connexion depuis OPNsense :
Constatez la disparition de la Phase 2 dans la console OPNsense :
Vérifiez également l’échec du ping entre les deux VM :
Relancez la connexion IPsec depuis OPNsense et observez la réapparition de la Phase 2 :
Confirmez la reprise du ping sur les deux machines virtuelles de test :
Conclusion
Si Azure VPN Gateway reste la solution de référence pour une interconnexion cloud sécurisée et redondante, l’utilisation d’une VM OPNsense sur Azure offre une alternative open source particulièrement adaptée aux petits projets ou aux environnements où vous souhaitez tirer parti de vos compétences réseau existantes.
Vous gagnez en flexibilité de configuration, en contrôle détaillé des politiques VPN et en possibilité d’étendre facilement vers d’autres protocoles (OpenVPN, WireGuard).
Cette approche hybride combine la robustesse du cloud Azure et la puissance d’OPNsense pour bâtir un VPN sur mesure parfaitement aligné avec vos besoins.
Depuis déjà plusieurs années, l’augmentation croissante des menaces, qu’il s’agisse de rançongiciels, de pannes matérielles ou d’erreurs humaines, impose de repenser ses stratégies de sauvegarde dans le cloud. Plutôt que de gérer soi-même un compte de stockage Azure, Veeam Data Cloud Vault se présente comme un coffre 100 % managé, conçu pour simplifier et fiabiliser vos sauvegardes tout en respectant la règle 3-2-1-1-0.
Un premier article parlant de la sauvegarde des données 365 via la solution Veeam Data Cloud SaaS Backup est disponible juste ici.
Dans cet article, je vous guide pas à pas pour déployer votre coffre Veeam depuis Azure Marketplace, l’intégrer à Veeam Backup & Replication et tirer pleinement parti de ses fonctionnalités avancées.
Qu’est-ce que le concept 3-2-1 pour les sauvegardes ?
Le concept de la règle 3-2-1 a été formalisé par le photographe numérique Peter Krogh, et publié pour la première fois en 2005 dans son ouvrage The DAM Book: Digital Asset Management for Photographers
Il s’agit d’une règle simple et éprouvée pour garantir la sécurité et la résilience de vos sauvegardes :
3 copies des données
1 copie « live » : vos données actives sur le système de production
2 copies de sauvegarde : répliquées ailleurs, pour pouvoir restaurer en cas de défaillance ou de corruption
2 types de supports différents
Par exemple :
Un disque dur interne ou réseau (NAS)
Un autre support : bande LTO, SSD externe, ou stockage objet cloud
L’idée est de réduire le risque de défaillance matérielle simultanée : un même lot de disques peut tomber en panne, mais un disque dur + une bande ou un système cloud présentent des modes de panne différents.
1 copie hors site
Pour vous prémunir contre :
Vol, incendie ou inondation de votre site principal
Corruption logicielle ou rançongiciel (ransomware) qui toucherait tout votre réseau
Cette copie peut être :
Hébergée dans un cloud public (Azure Blob Storage, Amazon S3, etc.)
Stockée physiquement dans un autre bureau ou un coffre-fort externe
Répliquée chez un prestataire spécialisé
Et pourquoi parle-t-on maintenant de 3-2-1-1-0 ?
Le concept 3-2-1-1-0 est une évolution de la règle 3-2-1, pensée pour les menaces modernes (ransomware, erreurs de sauvegarde, etc.). Il rajoute ainsi :
1 copie hors ligne ou immuable (air-gapped/immutable). Cette copie n’est pas connectée au réseau (ou est protégée en écriture seule), de manière à rester intacte même en cas de ransomware ciblant vos systèmes connectés.
0 erreur de sauvegarde. Il faut vérifier régulièrement que chaque sauvegarde se termine sans erreur, et tester la restauration pour garantir l’intégrité et la disponibilité de vos données en cas de besoin.
Qu’est-ce que Veeam Data Cloud vault ?
Veeam Data Cloud Vault est un service de stockage cloud sécurisé, pré-configuré et entièrement géré par Veeam sur l’infrastructure Microsoft Azure. Voici une courte vidéo qui vous montre ce service :
Pourquoi passer par Veeam Data Cloud Vault à la place de créer directement un compte de stockage Azure ?
La configuration faite directement par Veeam est le premier avantage à passer par le service Veeam Data Cloud Vault : vous indiquez simplement votre volume de données à sauvegarder, et tout est provisionné sans aucun paramétrage Azure de votre part.
Voici ce que Veeam fait automatiquement pour vous :
Immutabilité et isolation « Zero Trust » intégrées Veeam Data Cloud Vault repose sur des mécanismes d’immutabilité natifs : chaque objet écrit devient en lecture seule pour la durée configurée, empêchant toute suppression ou modification accidentelle ou malveillante (ransomware). Cette couche d’isolation logique (air-gapped, c’est-à-dire isolée du réseau) est activée par défaut et n’existe pas automatiquement sur un compte de stockage classique sans configuration manuelle
Sécurité et chiffrement bout en bout Les transferts entre Veeam Backup & Replication et le Vault se font sur des canaux chiffrés via un certificat mutualisé, sans jamais exposer de clés ou de tokens. De plus, toutes les données sont stockées chiffrées au repos, sans configuration supplémentaire. Un compte de stockage classique exige la mise en place manuelle du chiffrement (Azure Storage Service Encryption) et la gestion des clés (Key Vault)
Conformité à la stratégie 3-2-1-1-0 Le Vault répond directement aux exigences :
1 copie hors site : vos backups sont sur l’infrastructure Veeam dans Azure.
1 copie immuable/air-gapped : garantie par la politique d’immutabilité native.
0 erreur : Veeam supervise automatiquement la réussite de chaque sauvegarde et vous alerte en cas de problème.
Un compte de stockage classique n’offre pas cette orchestration automatisée autour de la vérification d’intégrité et de l’immutabilité.
Combien coûte Veeam Data Cloud Vault ?
La partie des coûts proposée par Veeam s’avère intéressante. Contrairement au modèle « pay-as-you-go » (à l’usage) habituellement appliqué à un compte de stockage Azure, Veeam Data Cloud Vault propose un tarif forfaitaire par To incluant le stockage, les appels API, l’egress et les restaurations : plus de risque de « bill shock » lié aux opérations ou au trafic.
Deux SKUs sont proposés par Veeam : Foundation et Advanced :
Foundation débute à 14 USD / To / mois (facturé annuellement).
Advanced est à 24 USD / TB / mois, mais inclut un nombre illimité d’opérations de lecture/restauration.
On peut différencier ces deux offres de la façon suivante :
Granularité de l’emplacement
Foundation vous permet de choisir le pays où vos données seront stockées, Veeam/Microsoft sélectionnant ensuite la région exacte.
Advanced vous donne la main sur la région Azure précise (par exemple « West Europe » vs « North Europe ») pour optimiser latence, conformité ou réplication inter-zones.
Durabilité
Foundation s’appuie sur LRS (Locally Redundant Storage), garantissant « 11 nines » de durabilité (99,999999999 %).
Advanced utilise ZRS (Zone-Redundant Storage), offrant « 12 nines » (99,9999999999 %) en répartissant les données sur plusieurs zones de disponibilité.
Limites de lecture/restauration
Foundation applique une politique de fair use sur les appels de lecture et les restaurations.
Advanced propose des lectures et restaurations illimitées sans restrictions supplémentaires.
Qu’est-ce que contient le Fair Use de Veeam ?
La politique Fair Use de Veeam Data Cloud Vault définit une franchise gratuite d’opérations de lecture/restauration incluse dans votre abonnement, afin d’assurer une utilisation raisonnable et équitable des ressources :
Foundation Edition : Restauration ou récupération de données jusqu’à 20 % de la capacité totale souscrite sur une période d’un an, sans surcoût.
Advanced Edition : Restauration ou récupération de données jusqu’à 100 % de votre capacité activement consommée chaque année, sans surcoût.
Au-delà de ces seuils, les opérations de lecture, de récupération et l’egress sont facturés aux tarifs standards Microsoft applicables à la région concernée.
Quelles régions Azure supportentVeeam Data Cloud Vault ?
Voici les régions Azure prises en charge par Veeam Data Cloud Vault :
L’édition Advanced n’est pas disponible dans ces régions en raison de l’absence de support ZRS par Azure.
Comment tester Veeam Data Cloud Vault ?
De nombreuses vidéos sont déjà disponibles sur la chaîne YouTube de Veeam :
Voici les différentes étapes que nous allons suivre afin de tester la solution Veeam Data Cloud Vault sur un environnement de test :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Afin de réaliser nos tests sur Veeam Data Cloud Vault, nous allons avoir besoin de :
Un tenant Microsoft actif
Une souscription Azure valide
Commençons par déployer la solution depuis Azure Marketplace.
Etape I – Déploiement de Veeam Data Cloud Vault :
Depuis le portail Azure, recherchez Veeam Data Cloud Vault :
Déployez la solution SaaS dans la souscription, le groupe de ressources et la nom de votre ressource :
Ouvrez la liste des plans disponibles :
Changez votre plan si nécessaire :
Lancez la validation Azure :
Une fois la validation réussie, lancez la création de la solution :
Attendez quelques minutes le temps de la configuration de Veeam Data Cloud Vault :
Une fois la configuration terminée, cliquez sur le bouton de finalisation :
Vérifiez les informations affichées, puis cliquez-ici pour activer la souscription. Selon ma compréhension, l’activation de celle-ci déclenche la facturation sur votre souscription Azure. Vous disposez alors de 72 heures pour vous rétracter une fois celle-ci activée :
Une fois la souscription Veeam activée, cliquez-ici pour basculer sur la console de gestion Veeam Data Cloud Vault :
Choisissez une authentification via Entra ID :
Veeam vous propose de créer votre premier coffre, vérifiez les informations puis cliquez sur Suivant :
Etant parti sur le plan Foundation, choisissez le Pays et non la région Azure, puis cliquez sur Suivant :
Attendez quelques minutes le temps du provisionnement et de la configuration des ressources gérées par Veeam :
Quelques minutes plus tard, le coffre Veeam est créé, copiez les informations suivantes afin de configurer votre application Veeam Backup :
Cliquez sur Suivant afin de terminer la configuration :
La fin de la configuration vous transporte sur le tableau de bord de Veeam Data Cloud Vault :
Du côté d’Azure, vous pouvez constater la ressource SaaS dans le groupe de ressources ; cliquez dessus pour retrouver le détail de la solution :
Un clic sur le lien de cette solution vous permet d’ouvrir l’URL d’accueil de Veeam Data Cloud Vault :
Un autre clic sur le lien ci-dessous vous ouvre votre propre instance de Veeam Data Cloud Vault :
Consultez ou créez au besoin vos coffres sur cette page :
Visualisez les souscriptions Azure sur cet écran :
Le volume de stockage est visible depuis ce même portail après un rafraîchissement de l’information :
L’information est visible sur ce portail après une ou plusieurs heures :
Les informations du volume total de stockage sont alors actualisées sur le tableau de bord principal :
Notre solution Veeam Data Cloud Vault est maintenant configurée et prête à recevoir des données. La prochaine étape consiste à configurer cette dernière depuis un outil de sauvegarde, comme Veeam Backup & Replication.
Etape II – Ajout d’un coffre Veeam :
J’ai créé une machine virtuelle depuis le Marketplace Azure la solution Veeam Backup & Replication pour réaliser les tests.
Une fois la console de gestion de Veeam Backup & Replication ouverte, ouvrez la configuration de l’infrastructure de sauvegarde :
Cliquez sur le type Veeam Data Cloud Vault :
Nommez celui-ci, cochez la case, puis cliquez sur Suivant :
Cliquez sur Ajouter, puis choisissez la connexion avec la clef du coffre :
Collez les informations précédemment copiées du coffre Veeam, puis cliquez sur OK :
Cliquez sur Suivant :
Renseignez un nouveau dossier créé sur le coffre, puis cliquez sur Suivant :
Définissez les informations du stockage local pour les restaurations rapides, puis cliquez sur Suivant :
Cliquez sur Appliquer :
Attendez quelques secondes la mise en place de la configuration, puis cliquez sur Suivant :
Une fois la configuration réussie, cliquez sur Terminer :
Constatez l’apparition du coffre dans la liste des répertoires de Sauvegarde :
Notre coffre Veeam est maintenant un répertoire de sauvegarde. Nous allons maintenant modifier une première police consacrée à la sauvegarde d’un partage de fichiers.
Etape III – Sauvegarde d’un partage de fichier sur le coffre Veeam :
Pour cela, retournez dans les travaux de sauvegarde déjà en place, puis cliquez sur l’un d’entre eux afin de le modifier :
Cochez la case suivante afin de configurer le coffre Veeam comme seconde destination de sauvegarde :
Cliquez sur Avancé :
Cochez la case suivante, configurez un mot de passe, puis cliquez sur OK :
Ajoutez en seconde cible le coffre Veeam, puis cliquez termine la modification de la police de sauvegarde :
Constatez l’apparition d’un second travail de sauvegarde, dont le déclenchement dépendra du premier auquel il est rattaché :
Lancez le premier travail de sauvegarde afin de tester le bon fonctionnement :
Une fois le premier travail de sauvegarde terminé, constatez le démarrage automatique du second travail de sauvegarde dédié au coffre Veeam :
Constatez l’apparition de sauvegarde du partage de fichiers et du nombre de points de restauration disponibles :
Retournez sur les répertoires de sauvegarde afin de visualiser la consommation d’espace sur votre coffre Veeam :
Testons maintenant la même approche de réplication de sauvegarde pour un stockage objet.
Etape IV – Sauvegarde d’objets sur le coffre Veeam :
Retournez à nouveau dans les travaux de sauvegarde objet déjà en place, puis cliquez sur l’un d’entre eux afin d’ajouter comme seconde destination de sauvegarde le coffre Veeam.
Cliquez sur Avancé :
Cochez la case suivante, configurez un mot de passe, puis cliquez sur OK :
Ajoutez en seconde cible le coffre Veeam, puis cliquez termine la modification de la police de sauvegarde :
Constatez l’apparition d’un second travail de sauvegarde, dont le déclenchement dépendra du premier auquel il est rattaché :
Lancez le premier travail de sauvegarde afin de tester le bon fonctionnement, puis constatez l’apparition de sauvegardes de fichiers objets :
Retournez sur les répertoire de sauvegarde afin de visualiser l’augmentation de la consommation d’espace sur votre coffre Veeam :
Terminons notre test par la restauration d’un fichier objet supprimé dans un conteneur Azure, dont la sauvegarde est répliquée sur le coffre Veeam.
Etape V – Restauration d’un fichier objet :
Supprimez un fichier sur un stockage objet :
Depuis Veeam Backup & Replication, retournez sur les points de sauvegarde associés au coffre Veeam, puis lancez la restauration d’un fichier objet :
Attendez quelques secondes le chargement des points restauration disponibles :
Cliquez sur le fichier supprimé à restaurer, puis déclenchez la restauration par écrasement :
Attendez quelques secondes le déclenchement du travail de restauration :
Attendez quelques minutes la fin du travail de restauration :
Constatez la réapparition du fichier sur le stockage objet :
Conclusion
En adoptant Veeam Data Cloud Vault sur Azure, vous déléguez la complexité opérationnelle et garantissez une protection de vos données conforme à la règle 3-2-1-1-0 :
Déploiement en un clic : plus besoin de scripts ni d’ARM templates.
Sécurité renforcée : immutabilité native et chiffrement bout-en-bout activés par défaut.
Surveillance proactive : Veeam supervise vos jobs et vous alerte immédiatement en cas d’anomalie.
Prévisibilité budgétaire : un tarif fixe par To incluant toutes les opérations et l’egress, sans surprises.
Que vous choisissiez l’édition Foundation ou Advanced, Veeam vous offre une solution SaaS prête à l’emploi, alliant performance, sécurité et tranquillité d’esprit 😎
Dans un contexte où la migration vers le cloud s’accompagne souvent de contraintes d’adressage et de sécurité, le NAT peut être vu comme une solution pouvant résoudre les problématiques de chevauchement d’adresses et de confidentialité. Vraiment ?
Attention ! Recourir au NAT pour masquer des conflits d’adresses n’est pas toujours une approche saine à long terme, car cela peut introduire une complexité opérationnelle accrue et des difficultés de maintenance ; il doit donc être considéré comme une solution transitoire ou de contournement.
Qu’est-ce que le NAT ?
Le NAT ( ou Network Address Translation) est un mécanisme qui permet de faire correspondre des adresses IP privées (non routables sur Internet) à une ou plusieurs adresses IP publiques (routables). Il joue un rôle clé dans la conservation des adresses IPv4 et dans la sécurisation des réseaux privés.
Voici une courte vidéo qui explique le principe du NAT afin de pallier le souci d’adresses IPv4 pour Internet :
Comment fonctionne le NAT ?
Lorsqu’une machine interne (par exemple 10.0.0.1) envoie une requête vers Internet (par exemple 200.100.10.1), le routeur NAT remplace son adresse source privée par une adresse publique (par exemple 150.150.0.1), et stocke dans sa table de traduction la corrélation :
Le routage du trafic impacte alors le traffic de données dans les deux sens :
Sortant : le paquet quitte le réseau interne avec l’adresse publique.
Entrant : la réponse revient à l’adresse publique, le routeur NAT consulte sa table et renvoie le paquet à la machine interne d’origine.
Quels sont ses avantages et ses limites au NAT ?
Avantages
Économie d’adresses IPv4
Masquage du réseau interne (sécurité renforcée)
Contrôle centralisé du trafic sortant/entrant
Limites
Complexité de dépannage (tables de traduction)
Certains protocoles (FTP actif, SIP, etc.) nécessitent des algorithmes NAT-aware ou des « NAT helpers »
Impact potentiel sur la latence et le débit
SNAT vs DNAT ?
En pratique, le NAT (Network Address Translation) se décline en deux grands modes :
Mode
Abréviation
Fonction principale
Exemple d’usage
Source NAT
SNAT (Source NAT)
Modifier l’adresse source et/ou le port d’une connexion sortante
Votre VM privée (10.0.0.5) → Internet apparaît avec l’IP publique du NAT Gateway
Destination NAT
DNAT (Destination NAT)
Modifier l’adresse de destination et/ou le port d’une connexion entrante
Internet (51.210.34.12:80) → redirigé vers votre VM privée (10.0.0.5:8080)
Règles de NAT sortantes : permettent de présenter votre réseau virtuel Azure à vos sites distants avec un plan d’adressage spécifique.
Règles de NAT entrantes : permettent à vos sites distants d’accéder au réseau virtuel Azure en utilisant un plan d’adressage différent.
Et le NAT dans Azure c’est possible ?
Un premier service, appelé Azure NAT Gateway, est conçu pour offrir un moyen simple, fiable et évolutif de gérer le trafic sortant depuis vos réseaux virtuels vers Internet ou d’autres services Azure, sans exposer vos machines virtuelles (VM) directement avec des adresses IP publiques :
Une passerelle NAT Azure est un service de traduction d’adresses réseau entièrement managé et hautement résilient. Vous pouvez utiliser Azure NAT Gateway pour autoriser toutes les instances d’un sous-réseau privé à se connecter à Internet, tout en restant entièrement privées. Les connexions entrantes non sollicitées depuis Internet ne sont pas autorisées via une passerelle NAT. Seuls les paquets arrivant en tant que paquets de réponse à une connexion sortante peuvent passer via une passerelle NAT.
Peut-on donc avoir un chevauchement d’adresses entre le LAN et un réseau virtuel Azure ?
La réponse est oui :
Les organisations utilisent fréquemment des adresses IP privées définies dans le document RFC1918 pour la communication interne dans leurs réseaux privés. Quand ces réseaux sont connectés à l’aide d’un VPN via Internet ou à l’aide d’un WAN privé, les espaces d’adressage ne doivent pas se chevaucher.
Si c’est le cas, la communication échoue. Pour connecter deux réseaux ou plus avec des adresses IP qui se chevauchent, le NAT est déployé sur les appareils de passerelle qui connectent les réseaux.
Voici un exemple d’architecture entre plusieurs sites appliquant différentes règles NAT :
Attention, Microsoft liste ici les contraintes pour la fonctionnalité NAT d’Azure VPN Gateway :
NAT est pris en charge sur les références (SKU) suivantes : VpnGw2~5, VpnGw2AZ~5AZ.
NAT est pris en charge pour les connexions intersites IPsec/IKE uniquement. Les connexions de réseau virtuel à réseau virtuel et les connexions P2S (point à site) ne sont pas prises en charge.
Les règles NAT ne sont pas prises en charge sur des connexions pour lesquelles l’option Utiliser des sélecteurs de trafic basés sur des stratégies est activée.
La taille maximale du sous-réseau de mappage externe prise en charge pour le NAT dynamique est /26.
Les mappages de ports ne peuvent être configurés qu’avec des types NAT statiques. Les scénarios NAT dynamiques ne s’appliquent pas aux mappages de ports.
Les mappages de ports ne peuvent pas prendre de plages pour l’instant. Un port individuel doit être entré.
Les mappages de ports peuvent servir pour les protocoles TCP et UDP.
Et en pratique ?
Pour valider la fonctionnalité de NAT au sein de mon architecture Azure, j’ai mis en place un petit exercice de démonstration. Mon environnement se compose de deux réseaux distincts :
Le premier simulant un réseau on-premise
Le second correspondant à un réseau virtuel Azure
Le schéma ci-dessous présente ces deux réseaux créés dans mon environnement Azure :
Dans le portail Azure, j’ai donc créé deux réseaux virtuels configurés sur la même plage d’adressage (10.0.0.0/16) pour illustrer un cas de chevauchement :
Sur chaque réseau virtuel, j’ai provisionné une machine virtuelle, toutes les deux en 10.0.0.4 pour renforcer l’idée d’adressage complètement identique :
Pour établir la connectivité, j’ai déployé deux VPN Gateway de type VpnGw2, configurées en tunnel IPsec site à site entre elles :
J’ai commencé par ajouter des règles NAT sur la passerelle Azure :
Egress rules –> pour présenter votre réseau virtuel Azure avec un adressage translaté à votre réseau on-premise :
adresses internes : l’adressage IP configuré sur votre réseau virtuel Azure
adresses externes = l’adressage IP translaté vu par votre réseau on-premise
Ingress rules –> pour accéder à votre réseau on-premise avec des IP différentes de celles configurées :
adresses internes = l’adressage IP configuré sur votre réseau on-premise
adresses externes = l’adressage IP translaté vu par votre réseau virtuel Azure
J’ai répliqué la même logique avec une configuration opposée sur la passerelle VPN simulant celle de mon réseau on-premise :
Egress rules –> pour présenter ton réseau on-premise avec un adressage translaté à ton réseau virtuel Azure :
adresses internes : l’adressage IP configuré sur ton réseau on-premise
adresses externes = l’adressage IP translaté vu par ton réseau virtuel Azure
Ingress rules –> pour accéder à ton réseau virtuel Azure avec des IP différentes de celles configurées :
adresses internes = l’adressage IP configuré sur ton réseau virtuel Azure
adresses externes = l’adressage IP translaté vu par ton réseau on-premise
Enfin, j’ai créé deux passerelle de réseau local correspondant à chaque extrémité :
L’une pour présenter le réseau on-premise à la passerelle Azure
L’autre pour présenter le réseau Azure la passerelle on-premise
La première passerelle de réseau local contient l’IP publique de la passerelle VPN Azure et la plage d’adresses 10.0.0.0/16 :
La seconde passerelle de réseau local contient l’IP publique de la passerelle VPN on-premise et la plage d’adresses 10.0.0.0/16 :
J’ai ensuite établi la connexion site-à-site entre mes deux VPN Gateways (VpnGw2) en utilisant la clé pré-partagée définie lors de la création des ressources.
Lors de la configuration de la première connexion, j’ai directement rattaché les règles Ingress NAT et Egress NAT définies précédemment à cette connexion, afin que toute session transitant par le tunnel soit automatiquement traduite.
J’ai reproduit la même configuration sur la seconde connexion : la clé PSK identique, la même plage 10.0.0.0/16 et les règles NAT :
Pour faciliter la connexion de la VM hébergée dans le réseau virtuel Azure, j’ai ajouté le service Azure Bastion :
Une fois Azure Bastion en place, je me suis connecté à la machine virtuelle Azure directement depuis le portail :
Depuis la machine virtuelle Azure, j’ai alors effectué plusieurs tests de connexion vers l’adresse IP externe traduite de la VM simulée on-premise :
Depuis le même service Azure Bastion déployé sur le réseau virtuel Azure, j’ai ouvert une session RDP vers la machine virtuelle simulée sur le réseau on-premise en utilisant l’adresse IP externe traduite définie dans les règles NAT de la connexion VPN :
Depuis la VM simulée on-premise, j’ai alors effectué plusieurs tests de connexion vers l’adresse IP externe traduite de la machine virtuelle Azure :
Conclusion
Grâce à l’association d’Azure VPN Gateway et de règles SNAT, nous avons validé une communication bidirectionnelle transparente entre deux environnements au plan d’adressage identique, sans exposer d’IP publiques aux VM. Cette démonstration illustre la puissance du NAT dans Azure pour contourner le chevauchement d’adresses
Notez toutefois que s’appuyer durablement sur le NAT peut complexifier votre architecture et alourdir le dépannage ; il est donc recommandé de considérer cette solution comme une étape temporaire, en prévoyant à terme une refonte de votre plan d’adressage pour une architecture plus saine.
Réussir la migration d’une infrastructure IT nécessite un objectif clair, un plan d’action, des moyens humains et matériels, et …. , du temps devant soi. Mais il arrive que la migration ne soit pas un parcours de santé, mais plutôt jonché de contraintes impactant les stratégies décidés avant. Par exemple, que doit-on faire si la migration de VMs doit se faire finalement sans aucun accès au niveau hyperviseur ?
Différentes approches de migration ?
Lors d’une migration vers le cloud, plusieurs approches coexistent : le « lift-and-shift » (reprise à l’identique), la replatforming ou refactoring (adaptation partielle) et la reconstruction totale accompagnée de modernisation.
Si le lift-and-shift est souvent privilégié pour sa rapidité de mise en œuvre, il n’exploite pas pleinement les services cloud-native et peut engendrer un surcoût opérationnel à long terme.
À l’inverse, la refonte ou la reconstruction des applications, en recourant par exemple aux microservices, au serverless ou aux bases de données managées, permet d’améliorer la scalabilité, la résilience et l’agilité, tout en optimisant les coûts à terme.
Azure Migrate ?
Bien entendu, dans certains scénarios, notamment lorsqu’on fait face à des délais serrés, à des contraintes budgétaires ou à un manque de compétences, il est nécessaire de migrer en priorité les machines virtuelles existantes « telles quelles ».
On opte alors pour un lift-and-shift à l’aide d’outils comme Azure Migrate ou Azure Site Recovery, qui répliquent les VM sans toucher au code ni à l’architecture.
Pour vous donner un peu de matière, un ancien article parlant d’Azure Migrate vous détaille toutes les grandes étapes.
Mais que faire si l’accès à l’hyperviseur est restreint ?
Toutefois, si aucun niveau d’accès la couche hyperviseur n’est possible, la migration vers Azure s’en trouve alors un peu plus compliquée.
Dans le cadre d’Azure Migrate (et plus précisément du service de réplication Azure Site Recovery), on rencontre 2 rôles clés au sein de l’appliance de réplication déployée :
Serveur de traitement :
Installé par défaut sur le serveur de configuration, il reçoit les données de réplication envoyées par le Mobility Service installé sur vos machines sources.
Il optimise ces flux en effectuant de la mise en cache, de la compression et du chiffrement, puis les transmet vers votre compte de stockage Azure.
Serveur de cible principale :
N’est utilisé que lors du failback (reprise sur site) des machines dès lors qu’elles ont été basculées vers Azure.
Il reçoit alors les données répliquées en provenance d’Azure, reconstitue les disques (VHD/VMDK) et les écrit sur votre infrastructure on-premises pour restaurer les VM sur site.
En synthèse, le Process Server gère l’envoi optimisé des données vers Azure, tandis que le Master Target Server gère la réception et la restauration de ces mêmes données lors d’un retour en local.
En voyant cette excellente vidéo en mode tutoriel, je trouvais intéressant de tester par moi-même ce cas de figure, en partant d’un environnement VMware vers Azure, sans pouvoir utiliser l’accès hyperviseur.
Cet article est donc divisé en 2 démonstrations quasi-identiques :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Afin de réaliser nos 2 tests de migration, nous allons avoir besoin de :
Un tenant Microsoft actif
Une souscription Azure valide
Un environnement hypervisé (Hyper-V ou VMware)
Commençons par effectuer l’exercice de migration en partant du principe que nous pouvons déployer une machine virtuelle jouant le rôle de d’appliance de réplication sur VMware.
Test I – Appliance de réplication VMware :
Sur votre console hyperviseur, créez une machine virtuelle de type Windows Serveur afin d’y installer par la suite notre appliance de réplication :
Connectez-vous à celle-ci avec un compte administrateur local :
Si besoin, installez un navigateur internet récent :
Connectez-vous au portail Azure, puis recherchez le service Azure Migrate :
Cliquez-ici pour commencer un nouveau projet de migration :
Cliquez-ici pour créer le projet de migration :
Renseignez les toutes informations demandées, puis cliquez sur Créer :
Cliquez sur Découvrir afin d’installer l’appliance de réplication :
Renseignez tous les champs, puis cliquez sur Créer les ressources :
Conservez les options suivantes :
Cliquez sur le bouton suivant afin de télécharger l’installeur de l’appliance de réplication :
Cliquez également sur le bouton suivant afin de sauvegarder la clef utilisée par l’appliance de réplication pour s’enrôler au coffre Azure Recovery :
Lancez l’installeur de l’appliance de réplication :
Attendez quelques minutes la fin de la décompression :
Conservez ce choix, puis cliquez sur Suivant :
Acceptez les termes et conditions, puis cliquez sur Suivant :
Rechercher le fichier clef, puis cliquez sur Suivant :
Conservez ce choix, puis cliquez sur Suivant :
Attendez que tous les contrôles soit effectués, puis cliquez sur Suivant :
Définissez un mot de passe pour la base de données MySQL, puis cliquez sur Suivant :
Si cela est votre cas, cochez cette case, puis cliquez sur Suivant :
Cliquez sur Suivant :
Définissez les 2 liaisons réseaux, puis cliquez sur Suivant :
Cliquez sur Installer :
Attendez environ 10 minutes la fin de l’installation de l’appliance de réplication :
Cliquez sur Oui :
Collez cette passphrase dans un fichier texte, puis sauvegardez-le :
Une fois l’installation réussie, cliquez sur Terminer :
L’outil de configuration d’Azure Site Recovery s’ouvre automatiquement, ajoutez-le ou les comptes administrateur de vos machines devant être migrées dans le cloud Azure :
Retournez sur le portail Azure, rafraîchissez la page précédente, puis cliquez ici pour finaliser le processus d’enregistrement de l’appliance de réplication :
Attendez le succès de l’opération via la notification suivante :
Constatez la création de ressources dans le groupe de ressources précédemment défini :
Retournez sur l’appliance de réplication, rendez-vous dans le dossier suivant, puis copiez l’exécutable ci-dessous :
Créez un dossier partagé réseau sur votre appliance de réplication, puis collez-y l’exécutable précédemment copié ainsi que le fichier texte contenant la passphrase :
Retournez sur la console hyperviseur, puis connectez-vous à la machine virtuelle devant être migrée vers Azure :
Sur cette machine virtuelle à migrer, vérifiez la version de PowerShell installée (min 5.1) grâce à la commande suivante :
$PSversiontable
Toujours depuis votre machine virtuelle à migrer, vérifiez la connexion sur le port 9443 vers votre appliance de réplication :
Toujours depuis votre machine virtuelle à migrer, ouvrez le dossier partagé réseau de votre appliance de réplication de réplication :
Copiez les fichiers dans un nouveau répertoire local sur votre machine virtuelle à migrer :
Ouvrez un éditeur de texte afin de reprendre et préparer les commandes suivantes :
cd C:\Temp
ren Microsoft-ASR_UA*Windows*release.exe MobilityServiceInstaller.exe
MobilityServiceInstaller.exe /q /x:C:\Temp\Extracted
cd C:\Temp\Extracted
UnifiedAgent.exe /Role "MS" /InstallLocation "C:\Program Files (x86)\Microsoft Azure Site Recovery" /Platform "VmWare" /Silent /CSType CSLegacy
cd C:\Program Files (x86)\Microsoft Azure Site Recovery\agent
UnifiedAgentConfigurator.exe /CSEndPoint <CSIP> /PassphraseFilePath <PassphraseFilePath>
Modifiez les valeurs en rouge par l’adresse IP de votre appliance de réplication et le chemin du fichier contenant la passphrase :
Ouvrez l’invite de commande en mode administrateur, puis exécutez les commandes suivantes pour copier le programme d’installation sur le serveur à migrer :
Exécutez cette commande pour installer l’agent :
Exécutez ces commandes pour enregistrer l’agent auprès du serveur de configuration :
Avant de continuer, vérifiez le succès des opérations :
Retournez sur le projet Azure Migrate, puis cliquez sur Rafraîchir afin de voir apparaître la machine virtuelle à migrer :
Cliquez ensuite sur Répliquer :
Renseignez toutes les champs, puis cliquez sur Continuer :
Sélectionnez les informations d’identification à utiliser pour installer à distance le service de mobilité sur les machines à migrer, puis cliquez sur Suivant :
Sélectionner les machines à migrer, puis cliquez sur Suivant :
Sélectionnez les propriétés cibles pour la migration. Les machines migrées seront créées avec les propriétés spécifiées, puis cliquez sur Suivant :
Sélectionnez la taille de la VM Azure pour les machines à migrer, puis cliquez sur Suivant :
Sélectionnez le type de disque à utiliser pour les machines à migrée, puis cliquez sur Suivant :
Lancez la réplication en cliquant sur Répliquer :
Les notifications suivantes apparaissent alors :
Des ressources Azure liées au projet de migration sont alors créées :
Le compte de stockage commence à recevoir les premières données liées à la réplication :
Dans le coffre Recovery, la réplication commence elle-aussi à être visible :
Environ 1 heure plus tard, celle-ci est terminée :
Un clic sur la machine virtuelle à migrer nous affiche le schéma de réplication des données :
Si tout est OK, retournez sur le projet de migration, actualiser si nécessaire afin de pouvoir cliquer sur Migrer :
Définissez la destination cible, puis cliquez sur Continuer :
Cochez la machine virtuelle à migrer, puis cliquez sur Migrer :
La notification suivante apparaît :
Quelques secondes plus tard, celle-ci affiche le succès du déclenchement de la migration :
Cette migration est visible sur notre projet Azure Migrate :
Le coffre Recovery nous indique que la migration est terminée :
Le groupe de ressources Azure contient alors de nouvelles ressources créées lors de la migration :
Afin de pouvoir nous connecter à la machine virtuelle via Azure Bastion, copiez les commandes suivantes depuis la page Azure de votre machine virtuelle migrée :
# 1. Autoriser les connexions RDP
Write-Host "Activation des connexions RDP…" -ForegroundColor Cyan
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' `
-Name 'fDenyTSConnections' -Value 0
# 2. Ouvrir le Pare-feu Windows pour RDP
Write-Host "Configuration du Pare-feu pour autoriser RDP…" -ForegroundColor Cyan
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
# 3. Redémarrer le service TSE/RDP
Write-Host "Redémarrage du service TermService…" -ForegroundColor Cyan
Restart-Service -Name 'TermService' -Force
Write-Host "RDP activé et Pare-feu configuré. Vous pouvez maintenant vous connecter." -ForegroundColor Green
Collez ces commandes, puis lancez celles-ci :
Ensuite, connectez-vous à votre machine virtuelle migrée via Azure Bastion :
Constatez l’ouverture de session Windows sur votre machine virtuelle migrée :
La migration de notre machine virtuelle hébergée sur VMware vers Azure s’est déroulée avec succès.
Continuons l’exercice de migration en partant cette fois du principe que nous ne pouvons pas créer une machine virtuelle jouant le rôle d’appliance de réplication sur l’hyperviseur, et que celle-ci doit donc alors être obligatoirement déployée sur Azure.
Test II – Appliance de réplication sur Azure :
Pour cette approche, commencez par créer un réseau virtuel Azure comprenant plusieurs sous-réseaux virtuels :
Un sous-réseau dédié à l’appliance de réplication.
Un sous-réseau dédié à Azure Bastion.
Un sous-réseau dédié à la passerelle VPN, pour connecter notre machine virtuelle à migrer à notre appliance de réplication hébergée sur Azure.
Créez une machine virtuelle ayant pour futur rôle l’appliance de réplication :
Connectez-vous à celle-ci via Azure Bastion :
Afin de connecter par la suite la machine virtuelle à migrer à l’appliance de réplication Azure, via une connexion Point à Site, des certificats sont nécessaires pour l’authentification IKEv2.
Pour cela, depuis l’appliance de réplication Azure, générez et exportez les certificats :
Un certificat racine auto-signé (à exporter en .cer pour Azure)
Un certificat client signé par ce root (à exporter en .pfx pour votre machine cliente)
Sur votre appliance de réplication Azure, ouvrez une fenêtre PowerShell, puis lancez le script suivant pour générer le certificat racine :
Ouvrez le gestionnaire des certificats utilisateurs afin de constater sa présence :
Afin d’enregistrer les données du certificat public dans Azure, exportez ce dernier depuis le gestionnaire des certificats utilisateurs :
Choisissez Non, puis cliquez sur Suivant :
Sélectionnez Format Base-64 encodé X.509 (.CER), puis cliquez sur Suivant :
Indiquez le chemin de sauvegarde, puis cliquez sur Suivant :
Ouvrez le fichier en base-64 avec un éditeur, puis copiez tout le texte (sauf -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----) :
Dans le portail Azure, rendez-vous sur la page de votre passerelle VPN, puis démarrez la configuration Point à Site :
Définissez un espace d’adressage, le type de tunnel en IKEv2, collez le texte en Base-64 que vous venez de copier dans Données du certificat racine, puis cliquez sur Enregistrer.
Après quelques instants, constatez la notification Azure suivante :
Télécharger le client VPN afin de configurer plus tard le client VPN Windows natif sur la machine virtuelle à migrer :
Toujours sur appliance de réplication Azure, recherchez le service Azure Migrate :
Cliquez-ici pour commencer un projet de migration :
Cliquez-ici pour créer un projet de migration :
Renseignez toutes les informations demandées, puis cliquez sur Créer :
Cliquez sur Découvrir afin d’installer l’appliance de réplication :
Renseignez tous les champs, puis cliquez sur Créer les ressources :
Conservez les options suivantes :
Cliquez sur le bouton suivant afin de télécharger l’installeur de l’appliance de réplication :
Cliquez également sur le bouton suivant afin de sauvegarder la clef utilisée par l’appliance de réplication pour s’enrôler au coffre Azure Recovery :
Une fois téléchargé, lancez l’installeur :
Attendez quelques minutes la fin de la décompression :
Conservez ce choix, puis cliquez sur Suivant :
Acceptez les termes et conditions, puis cliquez sur Suivant :
Rechercher le fichier clef, puis cliquez sur Suivant :
Conservez ce choix, puis cliquez sur Suivant :
Attendez que les contrôles soit effectués, puis cliquez sur Suivant :
Définissez un mot de passe pour la base de données MySQL, puis cliquez sur Suivant :
Si cela n’est pas votre cas, cochez cette case, puis cliquez sur Suivant :
Cliquez sur Suivant :
Définissez les 2 liaisons réseaux, puis cliquez sur Suivant :
Cliquez sur Installer :
Attendez environ 10 minutes la fin de l’installation :
Cliquez sur Oui :
Collez cette passphrase dans un fichier texte, puis sauvegardez-le :
Une fois l’installation réussie, cliquez sur Terminer :
L’outil de configuration d’Azure Site Recovery s’ouvre automatiquement, ajoutez-le ou les comptes administrateur des machines devant être migrées dans le cloud Azure :
Retournez sur le portail Azure, rafraîchissez la page précédente, puis cliquez ici pour finaliser le processus d’enregistrement de l’application de réplication :
Attendez le succès de l’opération avec la notification suivante :
Constatez la création de nouvelles ressources dans le groupe de ressources précédemment défini :
Retournez sur l’appliance de réplication, rendez-vous dans le dossier suivant, puis copiez seulement l’exécutable ci-dessous :
Créez un dossier partagé réseau sur votre appliance de réplication, puis collez-y :
L’exécutable précédemment copié
Le fichier texte contenant la passphrase
Rendez-vous sur la console hyperviseur, puis connectez-vous à la machine virtuelle devant être migrée sur Azure :
Sur cette machine virtuelle, vérifiez la version de PowerShell installée (min 5.1) grâce à la commande suivante :
Installez le certificat root dans le magasin Trusted Root Certification Authorities du gestionnaire des certificats machines :
Installez le certificat client dans le magasin Personal du certificats utilisateurs :
Installez la configuration VPN Windows précédemment téléchargée depuis la page Azure de la passerelle VPN :
Lancez la connexion VPN :
Cliquez sur Connecter :
Vérifiez le statut de la connexion VPN :
Depuis votre machine virtuelle à migrer, vérifiez la connexion sur le port 9443 vers votre appliance de réplication Azure :
Toujours depuis cette VM à migrer, ouvrez le dossier partagé réseau de votre appliance de réplication de réplication :
Copiez les fichiers dans un nouveau répertoire local sur votre machine virtuelle à migrer :
Ouvrez un éditeur de texte afin de reprendre et préparer les commandes suivantes :
cd C:\Temp
ren Microsoft-ASR_UA*Windows*release.exe MobilityServiceInstaller.exe
MobilityServiceInstaller.exe /q /x:C:\Temp\Extracted
cd C:\Temp\Extracted
UnifiedAgent.exe /Role "MS" /InstallLocation "C:\Program Files (x86)\Microsoft Azure Site Recovery" /Platform "VmWare" /Silent /CSType CSLegacy
cd C:\Program Files (x86)\Microsoft Azure Site Recovery\agent
UnifiedAgentConfigurator.exe /CSEndPoint <CSIP> /PassphraseFilePath <PassphraseFilePath>
Modifiez les valeurs en rouge par l’adresse IP de votre appliance de réplication et le chemin du fichier contenant la passphrase :
Ouvrez l’invite de commande en mode administrateur, puis exécutez les commandes suivantes pour copier le programme d’installation sur le serveur à migrer :
Exécutez cette commande pour installer l’agent :
Exécutez ces commandes pour enregistrer l’agent auprès du serveur de configuration :
Avant de continuer, vérifiez le succès des opérations :
Retournez sur le projet Azure Migrate, puis cliquez sur Rafraîchir afin de voir apparaître la machine virtuelle à migrer :
Cliquez ensuite sur Répliquer :
Renseignez toutes les champs, puis cliquez sur Continuer :
Sélectionnez les informations d’identification à utiliser pour installer à distance le service de mobilité sur les machines à migrer, puis cliquez sur Suivant :
Sélectionner les machines à migrer, puis cliquez sur Suivant :
Sélectionnez les propriétés cibles pour la migration. Les machines migrées seront créées avec les propriétés spécifiées, puis cliquez sur Suivant :
Sélectionnez la taille de la VM Azure pour les machines à migrer, puis cliquez sur Suivant :
Sélectionnez le type de disque à utiliser pour les machines à migrer, puis cliquez sur Suivant :
Lancez la réplication en cliquant sur Répliquer :
Les notifications suivantes apparaissent alors :
Le compte de stockage commence à recevoir les premières données liées à la réplication :
Dans le coffre Recovery, la réplication commence elle-aussi à être visible :
Environ 1 heure plus tard, celle-ci est terminée :
Un clic sur la machine virtuelle à migrer nous affiche le schéma de réplication des données :
Si tout est OK, retournez sur le projet de migration, actualiser si nécessaire afin de pouvoir cliquer sur Migrer :
Définissez la destination cible, puis cliquez sur Continuer :
Cochez la machine virtuelle à migrer, puis cliquez sur Migrer :
Quelques secondes plus tard, la notification suivante affiche le succès de déclenchement de la migration :
Cette migration est visible sur notre projet :
Le coffre Recovery nous indique que la migration est terminée :
Le groupe de ressources Azure contient alors de nouvelles ressources créées lors de la migration :
Afin de pouvoir nous connecter à la machine virtuelle via Azure Bastion, copiez les commandes suivantes depuis la page Azure de votre machine virtuelle migrée :
# 1. Autoriser les connexions RDP
Write-Host "Activation des connexions RDP…" -ForegroundColor Cyan
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' `
-Name 'fDenyTSConnections' -Value 0
# 2. Ouvrir le Pare-feu Windows pour RDP
Write-Host "Configuration du Pare-feu pour autoriser RDP…" -ForegroundColor Cyan
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
# 3. Redémarrer le service TSE/RDP
Write-Host "Redémarrage du service TermService…" -ForegroundColor Cyan
Restart-Service -Name 'TermService' -Force
Write-Host "RDP activé et Pare-feu configuré. Vous pouvez maintenant vous connecter." -ForegroundColor Green
Collez ces commandes, puis lancez celles-ci :
Ensuite, connectez-vous à votre machine virtuelle migrée via Azure Bastion :
Constatez l’ouverture de session Windows sur votre machine virtuelle migrée sur Azure :
La migration de notre machine virtuelle hébergée sur VMware vers Azure s’est déroulée avec succès.
Conclusion
En définitive, migrer vos VMs vers Azure sans droits d’infra reste une solution de « seconde main » qui dépanne en cas de contraintes fortes, mais elle ne doit pas devenir la norme.
Pour tirer pleinement parti du cloud, il sera toujours préférable de recréer vos ressources selon les principes cloud-native : refactoring des applications, adoption de services managés et optimisation des coûts.
À long terme, cette approche garantit une meilleure scalabilité, une résilience accrue et une plus grande agilité opérationnelle, tout en maîtrisant vos dépenses. Gardez donc cette méthode de contournement sous le coude, mais visez toujours la modernisation et l’optimisation complètes de votre stack dans Azure.
Microsoft continue d’aider la communauté des développeurs AI et propose désormais de nouveaux modèles d’applications Chat IA développé en .NET. Avec ces modèles d’application comme point de départ, vous pouvez rapidement créer des applications web de chat avec un ou des modèles d’intelligence artificielle dédiés. Tous ces modèles d’application AI en .NET sont désormais disponibles en préversion depuis mars 2025.
Vous souhaitez vous lancer dans le développement de l’IA, mais vous ne savez pas par où commencer ? J’ai un cadeau pour vous : nous avons un nouveau modèle d’application Web de chat sur l’IA qui est maintenant disponible en avant-première. 😊 Ce modèle fait partie de nos efforts continus pour faciliter la découverte et l’utilisation du développement de l’IA avec .NET
A quoi sert une application développée pour du chat IA ?
Une application de chat IA ne se contente pas de générer des réponses : elle les enrichit à partir de contenus existants (comme du code, des documents, etc.).
Un modèle d’embedding, qui transforme des textes en vecteurs numériques. → Il est utilisé pour rechercher les passages les plus pertinents dans une base de connaissances locale ou distante.
Un modèle génératif, qui prend ces passages et génère une réponse claire et naturelle, dans le style d’un assistant conversationnel.
Deux modèles, deux usages ?
Quand on développe une application en relation avec des modèles l’intelligence artificielle intégrant de la données, il est important de comprendre la différence entre deux grandes catégories de modèles d’IA :
1. Modèle de génération de texte (aussi appelés LLM – Large Language Models)
🔹 Objectif : Générer du texte naturel en réponse à une consigne 🔹 Entrée : Une instruction, un prompt ou une question 🔹 Sortie : Une réponse en langage humain, souvent contextualisée 🔹 Cas d’usage :
Assistants conversationnels (chatbots)
Rédaction automatique de contenu
Résumé ou reformulation de documents
Réponse à des questions en langage naturel
🧪 Exemple d’interaction :
Entrée : “Explique-moi le fonctionnement d’un moteur thermique.” Sortie : “Un moteur thermique fonctionne en convertissant la chaleur issue de la combustion d’un carburant en énergie mécanique…”
2. Modèle d’embedding (encodage vectoriel)
🔹 Objectif : Représenter un texte sous forme de vecteur numérique pour comparaison sémantique 🔹 Entrée : Une phrase, un document, une question, etc. 🔹 Sortie : Un vecteur (tableau de nombres) capturant le sens du texte 🔹 Cas d’usage :
Recherche sémantique (trouver un document similaire)
Détection de doublons ou de similarité
Indexation pour des bases vectorielles
Classement ou regroupement de contenus (clustering)
🧪 Exemple d’interaction :
Entrée : “Comment entretenir une voiture électrique ?” Sortie : [0.12, -0.03, 0.57, ...] (vecteur utilisable pour comparer avec d’autres)
Comment ce modèle d’application est-il construit ?
Architecture et technologies :
Application web Blazor (.NET) avec des composants Razor interactifs côté serveur
Base de données SQLite utilisée pour le cache d’ingestion via Entity Framework Core
Intégration avec les modèles d’IA d’Azure OpenAI Service
Fonctionnalités principales :
Chat avec IA augmentée par récupération (RAG)
Utilise un modèle d’IA pour générer des réponses intelligentes
Les réponses sont enrichies par des données extraites de documents
Extrait le texte et crée des embeddings vectoriels via un modèle de type embedding
Stocke les vecteurs dans un JsonVectorStore pour les recherches sémantiques
Interface utilisateur
Composants de chat interactifs (ChatMessageList, ChatInput)
Rendu Markdown et sanitisation HTML via les bibliothèques JavaScript
Workflow :
Au démarrage, l’application ingère les documents (par exemple des fichiers PDF), les découpe en fragments, puis les encode sous forme de vecteurs numériques grâce au modèle d’embedding (Modèle 2).
L’utilisateur interagit via l’interface de chat, en posant une question en langage naturel. Cette requête est ensuite traitée par le modèle génératif (Modèle 1), mais pas directement…
Avant de répondre, le système utilise le modèle d’embedding (Modèle 2) pour retrouver les passages les plus pertinents dans les documents indexés, en comparant leur sens avec celui de la question.
Enfin, le modèle génératif (Modèle 1) s’appuie à la fois sur ces passages trouvés et sur ses propres connaissances générales pour générer une réponse complète, claire et contextualisée.
Comment connecte-t-on cette application avec un modèle d’IA ?
Ces exemples d’application ne contiennent pas l’intelligence artificielle elle-même, mais elle interagit avec un modèle IA externe (hébergé dans le cloud, en local ou dans un container).
Enfin, découvrez le dernier épisode du stand-up de la communauté .NET AI, dans lequel Alex, Bruno et Jordan présentent les nouveaux modèles :
Dans cet article, je vous propose de tester l’application en connectant celle-ci vers 3 modèles d’IA :
GitHub
Azure OpenAI
Ollama
Voici les différentes étapes que nous allons suivre :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Afin de tester les différents modèles AI en .NET, nous allons avoir besoin de :
Un poste local
Un compte GitHub des modèles GitHub Models
Une souscription Azure si utilisation du service Azure OpenAI
Commençons par créer préparer le poste local.
Etape I – Préparation du poste local :
Rendez-vous sur la page suivante afin de télécharger Visual Studio Code :
Une fois téléchargée, lancez l’installation de ce dernier :
Rendez-vous sur la page suivante afin de télécharger la version 9.0 de .NET :
Une fois téléchargée, lancez l’installation :
Une fois l’installation réussie, fermez celle-ci :
Enfin, redémarrez le poste local :
Une fois le poste local redémarré, ouvrez Windows Terminal :
Installer les modèles de projet pour l’extension .NET liée à Microsoft.Extensions.AI, qui fait partie de l’écosystème Semantic Kernel :
dotnet new install Microsoft.Extensions.AI.Templates
Créez un dossier sur votre poste, puis positionnez-vous dedans :
Ne fermez pas cette fenêtre Windows PowerShell.
Notre environnement local est prêt. Avant de déployer des applications basées sur les templates d’IA, nous avons besoin de récupérer les identifiants de connexion (token) de certains modèles IA. Commençons par le plus simple : GitHub.
Etape II – Test de l’application avec le modèle GitHub :
Rendez-vous sur la page d’accueil de GitHub, puis authentifiez-vous, ou créez un compte au besoin :
Cliquez sur votre photo de profil en haut à droite, puis cliquez sur le bouton des Paramètres :
Tout en bas, cliquez sur le menu des paramètres suivant :
Créez un token à granularité fine, pour une utilisation personnelle de l’API GitHub :
Nommez ce token, puis choisissez une date d’expiration :
Cliquez-ici pour générer ce token :
Confirmez votre choix :
Copiez la valeur du token GitHub :
Retournez sur la fenêtre Windows PowerShell ouverte précédemment, puis lancez la commande suivante afin d’utiliser le template aichatweb pour créer une application web de chat IA en lien avec le modèle GitHub :
dotnet new aichatweb -n GitHubModels --provider githubmodels --vector-store local
Ouvrez l’explorateur Windows afin de constater la création d’un nouveau dossier ainsi que le code de l’application :
Sur votre poste local, ouvrez Visual Studio Code, puis choisissez l’action d’ouverture d’un dossier :
Sélectionnez le dossier créé par l’application IA :
Constatez l’ouverture de l’application dans Visual Studio Code :
Ouvrez la fenêtre Terminal :
Stockez un secret utilisateur localement (ici un token) de manière sécurisée pour notre projet .NET :
dotnet user-secrets set GitHubModels:Token github...
Affichez tous les secrets stockés localement pour le projet courant :
dotnet user-secrets list
Ajoutez ou retirer au besoin des fichiers PDF utilisés durant la phase d’indexation sémantique)
Compilez et exécutez l’application .NET dans le dossier courant :
dotnet run
L’application vérifie dans les sources de données si nouveau documents sont à indexer ou vectoriser :
Ce message vous indique que l’application tourne localement sur le port 5145 :
Ouvrez un navigateur web à cette adresse:port, puis posez une question à l’IA sur un sujet d’ordre général ou propre aux documents ingérés :
Constatez la rapidité du résultat et la ou les sources associés, puis cliquez dessus :
Constatez la sélection de texte en correspondance avec la question posée à l’IA :
Le test avec le modèle GitHub a bien fonctionné, pensez à détruire le token sur le portail de GitHub pour des questions de sécurité
Continuons les tests de l’application de chat IA avec le modèle Azure OpenAI.
Etape III – Test de l’application avec le modèle Azure OpenAI :
Depuis le portail Azure, commencez par rechercher le service Azure OpenAI :
Cliquez-ici pour créer un nouveau service :
Renseignez toutes les informations, conservez le modèle de prix S0 (suffisant pour nos tests), puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Créer :
Une fois le déploiement terminé, cliquez-ici :
Copiez les 2 informations suivantes dans votre bloc-notes afin de vous y connecter plus tard à via API :
Afin de créer les deux modèle d’IA nécessaires au travers d’Azure, cliquez-ici pour ouvrir le portail Microsoft AI Foundry :
Sur ce portail, commencez par rechercher le premier modèle d’IA nécessaire à notre application :
Cliquez sur Déployer :
Conservez le nom d’origine, puis cliquez sur Déployer :
Retournez sur le catalogue des modèles d’IA, puis recherchez le second modèle d’IA nécessaire à notre application :
Cliquez sur Déployer :
Conservez le nom d’origine, puis cliquez sur Déployer :
Vérifiez la présence des 2 modèles déployés dans le menu suivant :
Retournez sur la fenêtre Windows PowerShell ouverte précédemment, puis lancez la commande suivante afin d’utiliser le template aichatweb pour créer une application web de chat IA en lien avec le service AzureOpenAI :
dotnet new aichatweb -n AzureOpenAI --provider azureopenai --vector-store local
Ouvrez l’explorateur Windows afin de constater la création d’un nouveau dossier :
Sur votre poste local, ouvrez Visual Studio Code, puis choisissez l’action d’ouverture d’un dossier :
Sélectionnez le dossier créé par l’application IA :
Constatez l’ouverture de l’application dans Visual Studio Code :
Afin de passer d’une authentification basée sur une identité Azure (DefaultAzureCredential) à une authentification explicite par clé API (AzureKeyCredential), remplacer le code suivant :
var azureOpenAi = new AzureOpenAIClient(
new Uri(builder.Configuration["AzureOpenAI:Endpoint"] ?? throw new InvalidOperationException("Missing configuration: AzureOpenAi:Endpoint. See the README for details.")),
new DefaultAzureCredential());
Par celui-ci, puis sauvegardez le fichier Program.cs :
var endpoint = builder.Configuration["AzureOpenAI:Endpoint"]
?? throw new InvalidOperationException("Missing configuration: AzureOpenAI:Endpoint. See the README for details.");
var key = builder.Configuration["AzureOpenAI:Key"]
?? throw new InvalidOperationException("Missing configuration: AzureOpenAI:Key. See the README for details.");
var azureOpenAi = new AzureOpenAIClient(new Uri(endpoint), new AzureKeyCredential(key));
Ouvrez la fenêtre Terminal :
Enregistrez localement (et de manière sécurisée) le point de terminaison de l’instance Azure OpenAI :
dotnet user-secrets set AzureOpenAI:Endpoint https://aichattemplate-rg.openai.azure.co
Enregistrez de manière sécurisée la clé API de l’instance Azure OpenAI dans les secrets utilisateur de .NET :
dotnet user-secrets set AzureOpenAI:Key 1zF4OGPseV...
Affichez tous les secrets stockés localement pour le projet courant :
dotnet user-secrets list
Ajoutez ou retirer au besoin des fichiers PDF utilisées durant la phase d’indexation sémantique)
Compilez et exécutez l’application .NET dans le dossier courant :
dotnet run
Ouvrez un navigateur web à cette adresse:port indiqué, puis posez une question à l’IA sur un sujet d’ordre général ou propre aux documents ajoutés :
Constatez la rapidité du résultat et la ou les sources associés, puis cliquez dessus :
Constatez la sélection de texte en correspondance avec la question posée :
Le test avec le service Azure OpenAI a bien fonctionné, pensez à détruire le service une fois les tests terminés.
Terminons les tests de l’application de chat IA avec le modèle local Ollama.
Etape IV – Test de l’application avec le modèle Ollama :
Rendez-vous sur la page suivante afin de télécharger Ollama :
Une fois téléchargée, lancez l’installation :
Une fois l’installation réussie, vérifiez via l’URL suivante le bon fonctionnement du service :
http://localhost:11434/
Depuis le menu Démarrer, ouvrez l’application CMD, puis lancez la commande suivante :
ollama pull llama3.2
Ollama télécharge alors la version mini de Phi3 d’environ 2 Go
ollama pull all-minilm
Ollama télécharge alors un modèle ouvert d’environ 270 Mo :
Vérifiez la liste des modèles en place avec la commande suivante :
ollama list
Retournez sur la fenêtre Windows PowerShell ouverte précédemment, puis lancez la commande suivante afin d’utiliser le template aichatweb pour créer une application web de chat IA en lien avec le modèle Ollama :
dotnet new aichatweb -n llama3.2Model --provider ollama --vector-store local
Ouvrez l’explorateur Windows afin de constater la création d’un nouveau dossier ainsi que le code de l’application :
Sur votre poste local, ouvrez Visual Studio Code, puis choisissez l’action d’ouverture d’un dossier :
Sélectionnez le dossier créé par l’application IA :
Constatez l’ouverture de l’application dans Visual Studio Code :
Ouvrez la fenêtre Terminal :
Ajoutez ou retirer au besoin des fichiers PDF utilisées durant la phase d’indexation sémantique)
Compilez et exécutez l’application .NET dans le dossier courant :
dotnet run
L’application vérifie dans les sources de données configurées si nouveau documents sont à indexer ou vectoriser :
Cette ligne vous indique que l’application tourne localement sur le port 5145 :
Ouvrez un navigateur web à cette adresse:port, puis posez une question à l’IA sur un sujet d’ordre général ou propre aux documents ajoutés :
Constatez le pic d’usage du CPU/GPU selon la configuration matérielle de votre poste local :
Constatez la rapidité/lenteur du résultat :
Conclusion
Avec l’arrivée des nouveaux templates .NET dédiés à l’intelligence artificielle, il n’a jamais été aussi simple de créer des applications web de chat connectées à des modèles IA.
Que vous choisissiez un modèle cloud (comme Azure OpenAI), un modèle public (via GitHub), ou même un modèle local (comme ceux proposés par Ollama), l’infrastructure est prête à l’emploi et parfaitement intégrée à l’écosystème .NET.
Les solutions de bureau à distance, telles qu’Azure Virtual Desktop et Windows 365, reposent sur des protocoles de transport pour offrir une expérience utilisateur fluide et réactive. Par défaut, UDP est souvent privilégié pour sa faible latence, mais dans certains environnements, la fiabilité et la stabilité offertes par TCP priment.
Cet article détaille les spécificités de chacun de ces protocoles, leurs avantages et inconvénients, et propose deux approches pour forcer l’usage de TCP : une modification côté serveur et une modification côté client, que ce soit directement via le registre ou en déployant une stratégie de groupe (GPO).
TCP et son rôle dans les solutions de bureau à distance :
Le Transmission Control Protocol (TCP) est un protocole orienté connexion qui assure la fiabilité des échanges. Il garantit que les paquets arrivent dans l’ordre et, en cas de perte, les retransmet automatiquement.
Avantages de TCP :
Fiabilité et intégrité des données : Chaque paquet est vérifié et retransmis en cas d’erreur ou de perte.
Contrôle d’erreur et ordonnancement : Les données arrivent dans le bon ordre, ce qui est essentiel pour des applications nécessitant une cohérence stricte.
Inconvénients de TCP :
Surcharge et latence accrue : Les mécanismes de contrôle (comme le handshake initial) ajoutent un certain délai.
Moins performant pour les applications ultra-réactives : La latence induite peut être un frein pour certaines applications en temps réel.
UDP et ses applications dans le Remote Desktop :Le User Datagram Protocol (UDP) est un protocole sans connexion qui envoie les paquets sans vérifier leur réception ni leur ordre. Cette approche permet une transmission rapide avec une latence très réduite, idéale pour des sessions interactives.
Avantages de UDP :
Faible latence : Parfait pour des sessions de Remote Desktop où la réactivité est cruciale.
Moindre surcharge : L’absence de contrôle d’erreur exhaustif accélère le transfert des données.
Inconvénients de UDP :
Fiabilité moindre : Sans retransmission automatique, la perte de paquets peut dégrader la qualité de la session.
Absence de contrôle d’erreur intégré : Dans des environnements instables, cela peut entraîner des distorsions.
Fort de cette comparaison, il apparaît que le choix du protocole doit être adapté au contexte réseau. Par exemple, dans des environnements à qualité réseau variable, forcer l’utilisation de TCP peut s’avérer judicieux pour garantir une meilleure stabilité des connexions.
Forcer le flux TCP côté serveur
Il est possible de forcer le serveur à n’accepter que des connexions TCP, ce qui est particulièrement utile dans des environnements où la stabilité prime. Pour cela, vous pouvez modifier le registre du serveur ou déployer une GPO.
Modification via Registre
Avant modification, le serveur accepte par défaut les connexions en UDP (comme indiqué par vos captures d’écran). Pour forcer TCP, la modification est simple : il suffit d’ajouter la clé de registre SelectTransport.
Pour ce faire, la modification est simple : il suffit d’ajouter la clé de registre SelectTransport :
Voici la commande permettant d’ajouter automatiquement cette clé de registre Windows avec des droits administrateur :
« Use either UDP or TCP (default) » : Si la connexion UDP est possible, la majorité du trafic RDP l’utilisera.
« Use only TCP » : Toutes les connexions RDP se feront exclusivement via TCP.
Si cette stratégie n’est pas configurée ou est désactivée, RDP sélectionnera automatiquement le protocole optimal pour offrir la meilleure expérience utilisateur.
Testons maintenant la configuration côté client.
Forcer le flux TCP côté client
Passons à présent à la configuration côté client. Avant modification, le client se connecte en UDP, comme le montrent les captures d’écran. Pour forcer l’utilisation de TCP (via WebSocket, qui repose sur TCP), il suffit d’ajouter la clé de registre fClientDisableUDP.
Avant modification, le client fonctionnait en UDP, comme vous pouvez le constater sur la capture d’écran ci‑dessous.
Pour ce faire, la modification est simple : il suffit d’ajouter la clé de registre fClientDisableUDP.
Voici la commande permettant d’ajouter automatiquement cette clé de registre Windows avec des droits administrateur :
Après modification, la connexion se fait exclusivement en TCP. Ce changement assure que le client ne tente plus d’établir une connexion via UDP :
Conclusion
Le choix entre TCP et UDP dans des environnements de bureau à distance comme Azure Virtual Desktop et Windows 365 se résume à un compromis entre rapidité et fiabilité :
UDP offre une faible latence, idéale pour des sessions interactives, mais peut souffrir de pertes de paquets dans des réseaux instables.
TCP, même via une couche WebSocket, garantit la transmission fiable des données, au prix d’un léger surcoût en latence.
Note technique : Forcer l’utilisation de TCP est particulièrement recommandé dans les environnements où la qualité du réseau est variable ou sujette à des perturbations. Dans ces situations, bien que TCP puisse introduire une latence légèrement supérieure, il offre une stabilité et une fiabilité accrues, assurant ainsi une expérience utilisateur plus homogène.
En forçant l’utilisation de TCP via une modification de registre côté serveur (ou via une GPO) et/ou côté client, vous pouvez améliorer la stabilité des connexions, particulièrement dans des environnements où la qualité de la connexion est incertaine.
Ces approches vous permettent de mieux contrôler la configuration de votre infrastructure de Remote Desktop, optimisant ainsi l’expérience pour vos utilisateurs.
L’actualité concernant l’intelligence artificielle défile à un rythme effréné. Avec cette avalanche de nouveaux outils, de techniques et de possibles usages, combinant à la fois de réelles avancées, mais aussi parfois des discours marketing très prometteurs, chacun se doit de faire sa propre analyse, et de trier dans ces nouveautés les mises applications possibles dans au quotidien.
Qu’est-ce que les vecteurs dans le domaine de l’IA ?
Dans le domaine de l’IA, un vecteur est généralement utilisé pour représenter des données numériques. Un vecteur est une liste ordonnée de nombres. Par exemple, dans un espace à trois dimensions, un vecteur pourrait être représenté comme [3, 4, 5], où chaque nombre représente une dimension spécifique.
Dans l’IA, les vecteurs, c’est-à-dire des représentations numériques (ou embeddings) de données permettent donc de transformer du texte, des images ou d’autres données en une série de nombres qui représentent leurs caractéristiques essentielles. Ces représentations numériques facilitent la comparaison et la mesure de la similarité entre différents éléments.
L’embedding est une méthode de transformations de données provenant d’images, de textes, de sons, de données utilisateur, ou de tout autre type d’information, en vecteurs numériques. Cela revient à traduire le langage humain en une langue que les machines peuvent interpréter, capturant ainsi les nuances sémantiques ou contextuelles des éléments traités.
Grâce à une IA, la façon de rechercher des informations pertinentes repose sur la comparaison des vecteurs pour identifier les documents ou les images similaires. En d’autres termes, les vecteurs aident à comprendre et à exploiter la signification des données pour améliorer la précision des résultats de recherche.
Où sont stockés les vecteurs ?
Traditionnellement, les vecteurs étaient stockés dans des bases de données dédiées, comme Pinecone ou Milvus, conçues spécifiquement pour gérer des données vectorielles et optimiser les recherches par similarité.
Cependant, avec l’évolution des technologies, certains SGBD relationnels, comme Azure SQL Database, intègrent désormais un support natif pour les vecteurs. Cela permet de stocker et d’interroger directement des vecteurs au sein d’une base de données SQL classique, simplifiant ainsi l’architecture des applications et réduisant la nécessité d’avoir un système séparé.
Depuis quand Azure SQL Database peut stocker les vecteurs ?
Le type vector est un nouveau type de données natif dans Azure SQL Database spécifiquement conçu pour stocker des vecteurs. Plutôt que d’utiliser un format générique comme du JSON ou du varbinary, ce type offre un format dédié, compact et optimisé pour les opérations mathématiques, telles que le calcul de distances (cosinus, euclidienne, etc.).
Il permet ainsi d’effectuer directement dans la base de données des recherches par similarité, sans recourir à des systèmes externes spécialisés dans le stockage vectoriel.
Comment fonctionne la recherche de distance entre 2 vecteurs ?
En utilisant des fonctions intégrées telles que VECTOR_DISTANCE, cela calcule une distance (cosinus, euclidienne, etc.) entre le vecteur de la requête et chaque vecteur stocké, permettant d’ordonner les résultats par similarité (la distance la plus faible indiquant la correspondance la plus proche).
Est-ce disponible sur SQL Server 2022 ?
Non, la fonctionnalité native de support des vecteurs n’est pas disponible dans SQL Server 2022. Actuellement, cette capacité est proposée dans Azure SQL Database. Microsoft prévoit d’intégrer des fonctionnalités similaires dans les futures versions, notamment SQL Server 2025.
Pour la première fois, Microsoft apporte un support vectoriel natif à SQL Server. SQL Server 2025 sera une base de données vectorielle prête pour l’entreprise, capable de générer et de stocker en mode natif des incrustations vectorielles. Cette prise en charge native des vecteurs permettra aux clients de SQL Server d’exécuter des modèles d’IA génératifs en utilisant leurs propres données. Ils peuvent choisir le modèle d’IA requis grâce à la gestion extensible des modèles permise par Azure Arc.
Peut-on tester les vecteurs sur une base de données Azure SQL ?
Comme toujours, Alex Wolf, via son excellente chaîne YouTube The Code Wolf, nous montre la prise en charge des vecteurs IA au sein même des bases de données SQL :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Afin de faire nos tests sur le base de données Azure SQL pour < comprendre le fonctionnement des vecteurs, nous allons avoir besoin de :
Un tenant Microsoft active
Une souscription Azure valide
Commençons par créer la base de données SQL depuis le portail Azure.
Etape I – Création de la base de données Azure SQL :
Depuis le portail Azure, commencez par rechercher le service de bases de données SQL :
Renseignez les informations de base, comme la souscription Azure et le groupe de ressources :
Cliquez-ici pour également créer un serveur SQL hébergeant notre base de données :
Renseignez un nom unique pour votre serveur SQL, indiquez un compte administrateur à ce dernier, puis cliquez sur OK :
Conservez l’option de base pour la puissance votre serveur SQL, la réplication sur LRS, puis cliquez sur Suivant :
Conservez l’accès public pour nos tests, ajoutez-y votre adresse IP publique, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création des ressources :
Attendez environ 5 minutes, puis cliquez-ici pour accéder aux ressources créées :
Copiez les éléments de connexion à cette base de données présents l’onglet ci-dessous, puis conservez cette valeur par la suite dans un éditeur de texte :
Utilisez un outil de gestion de base de données, comme SQL Server Management Studio (SSMS), ou Azure Data Studio, disponible lui sur cette page :
Acceptez les conditions d’utilisations, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Installer :
Cliquez sur Terminer :
Ouvrez Azure Data Studio, puis cliquez-ici pour créer une nouvelle connexion :
Collez les informations de connexion de votre base SQL précédemment copiées, renseignez le mot de passe de votre administrateur, puis cliquez sur Connecter :
Saisissez la commande SQL suivante afin de créer la table liée au stockage des données et de leurs vecteurs :
CREATE TABLE dbo.demo
(
id INT PRIMARY KEY,
filename VARCHAR(50),
vectors VECTOR(1024) NOT NULL
)
Exécutez la commande, puis obtenez la confirmation suivante :
Notre base de données, encore vide en enregistrements et en vecteurs est maintenant prête.
Nous allons maintenant créer un le service d’intelligence artificielle sur Azure afin de créer calculer les vecteurs de nos futures données.
Etape II – Création du service d’IA Computer Vision :
Toujours sur le portail Azure, recherchez le service d’IA suivant :
Cliquez-ici pour créer un nouveau service :
Renseignez toutes les informations, en privilégiant un déploiement dans les régions East US ou West Europe, conservez le modèle de prix F0 (suffisant pour nos tests), puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création des ressources :
Une fois le déploiement terminé, cliquez-ici :
Copiez les 2 informations suivantes dans votre bloc-notes afin de vous y connecter plus tard à via API :
Afin d’envoyer différentes requêtes via API à notre service d’IA, utilisez un service dédié, comme par exemple Postman, disponible ici (créez un compte gratuit si nécessaire) :
Notre environnement manuel est maintenant prêt pour être testé.
La prochaine étape consiste à générer manuellement des vecteurs via notre service d’IA afin de les stocker dans votre base de données SQL.
Etape III – Chargement des vecteurs d’images dans la DB SQL :
Une fois connecté sur votre console Postman, cliquez-ici pour utiliser le service :
Notre premier objectif est de convertir les données d’une image en vecteur. Pour cela, choisissez la méthode de type POST, puis saisissez l’URL composée de la façon suivante :
Point de terminaison de votre service Computer Vision
Service API de vectorisation d’images proposé par Computer Vision
Exécutez la commande suivante, puis constatez le succès de celle-ci :
Contrôlez le résultat du chargement dans la base de données SQL via la requête suivante :
SELECT * FROM dbo.demo
Notre base de données Azure SQL a bien stocké les vecteurs calculés par le service d’intelligence artificielle. La prochaine étape consiste à calculer la distance entre les vecteurs des images et les vecteur d’un mot-clef.
Etape IV – Calcul de distance entre les images et le mot-clef :
Retournez sur le service d’appel API Postman, puis créez un nouvel onglet de requête :
Choisissez à nouveau une méthode de type POST, puis l’URL composée de la façon suivante :
Point de terminaison de votre service Computer Vision
Service API de vectorisation de texte proposé par Computer Vision
Rendez-vous dans l’onglet Headers afin de rajouter à nouveau en valeur la clef de votre service Computer Vision sous la clef Ocp-Apim-Subscription-Key :
Rendez-vous dans l’onglet Body afin de rajouter en RAW le mot-clef :
{
"text":"café"
}
Cliquez ensuite sur Envoyer, changez le format de sortie des vecteurs calculés en RAW, puis copiez tous les vecteurs présents entre les 2 crochets :
Retournez sur Azure Data Studio, puis commencez par coller la requête SQL suivante afin de créer une variable qui stockera les vecteurs de notre mot-clef :
DECLARE @searchVector VECTOR(1024) = '[]'
Entre les 2 crochets de la déclaration de variable, collez les vecteurs du mot-clef précédemment copiés :
Ajoutez en dessous la requête SQL basée sur la fonction VECTOR_DISTANCE :
SELECT TOP(10) id, filename, VECTOR_DISTANCE('cosine', @searchVector, vectors)
AS Distance from demo ORDER BY Distance
Puis exécutez l’ensemble afin de constater le résultat de distance entre le mot-clef et les 3 images :
Ces différents tests nous démontrent la possibilité de stockage des vecteurs et la recherche de résultats basés sur la distance entre ces derniers, le tout dans une base de données SQL.
Toutes ces étapes de génération de vecteurs et de recherche sur les distances sont facilement intégrables dans une application, comme celle justement proposée par Alex Wolf.
Etape V – Automatisation de l’importation des vecteur :
Retournez sur Azure Data Studio afin de créer une seconde table dédiée à notre application :
CREATE TABLE dbo.images
(
id INT PRIMARY KEY,
name VARCHAR(50),
vectors VECTOR(1024) NOT NULL
)
Rendez-vous sur la page GitHub suivante afin de télécharger l’application au format ZIP :
Décompressez l’archivage dans le dossier local de votre choix :
Ouvrez l’application Visual Studio Code, puis ouvrez le dossier correspondant à votre application :
Ouvrez le fichier Program.cs pour y renseigner votre le point de terminaison, ainsi que la clef de votre service Computer vision, puis Sauvegardez :
Ouvrez le fichier AzureBectorDatabaseService.cs pour y renseigner les informations de connexion de votre base SQL précédemment copiées avec le bon mot de passe, puis Sauvegardez :
Démarrez l’application via la commande .NET suivante :
dotnet run
Quelques secondes plus tard, l’application est démarrée, l’URL et le port exposé s’affichent :
Collez cette URL dans un navigateur internet pour ouvrir l’application, puis cliquez sur le bouton ci-dessous pour charger une ou des images au format JPG :
Sélectionnez-le ou les fichiers images de votre choix, puis cliquez sur Ouvrir :
Cliquez-ici pour téléversé le ou les fichiers :
Constatez l’apparition de la vignette de vos images téléversées :
Effectuez la même opération avec d’autres images plus ou moins variées :
Retournez sur Azure Data Studio, puis lancez la requête SQL suivante pour voir le chargement de des données et des vecteurs dans la seconde table créée :
SELECT * FROM dbo.images
Notre application contient maintenant des fichiers images, avec leurs vecteurs dans notre base de données SQL grâce à notre service d’IA Computer Vision.
Il nous reste maintenant qu’à rechercher via un mot-clef, transposé lui-aussi en vecteurs via l’IA, à des images dont les vecteurs lui seraient proches.
Etape VI – Automatisation du calcul de distance vectorielle :
Retournez sur la page web de votre application, saisissez un mot-clef dans la zone prévue à cet effet, puis cliquez sur Rechercher afin de constater la pertinence des résultats :
Refaites d’autres tests en jouant également avec les 3 niveaux du seuil de confiance :
Les résultats retournés varient selon le niveau du seuil de confiance :
La faible quantité d’images chargées et le niveau de confiance réglé sur moyen donne des résultats trop larges :
Cette approximation peut se corriger avec un niveau de confiance élevé :
Conclusion
En conclusion, l’intégration native du type de données vector dans Azure SQL Database marque une avancée majeure pour les développeurs souhaitant exploiter l’intelligence artificielle directement au sein de leur SGBD.
Cette fonctionnalité permet de stocker et d’interroger des vecteurs de manière optimisée, simplifiant ainsi l’architecture des applications en éliminant le besoin d’une base de données vectorielle externe.
En adoptant ces outils, les équipes peuvent désormais transformer et analyser leurs données de façon plus intuitive et sécurisée, tout en tirant parti de l’écosystème SQL existant. C’est un pas décisif vers une intégration plus fluide de l’IA et la modernisation d’environnements traditionnels.
Début février, Microsoft vient d’annoncer une nouvelle fonctionnalité en préversion pour migrer une machine virtuelle, de première génération vers la seconde. Cette bascule de génération est l’occasion de renforcer la sécurité (via Secure Boot et vTPM), d’améliorer les performances (temps de démarrage plus rapides) et d’offrir un support de disques de plus grande capacité. Tout cela, sans avoir besoin de reconstruire la machine virtuelle et en quelques clics.
Depuis quand la génération 2 est disponible sur Azure ?
Microsoft a annoncé la prise en charge des machines virtuelles de génération 2 depuis 2019, avec une généralisation progressive de leur déploiement par la suite.
Il y a quelques jours, Microsoft a annoncé la prévisualisation publique des machines virtuelles de génération 2 sur Azure. Les machines virtuelles de génération 2 prennent en charge un certain nombre de nouvelles technologies telles que l’augmentation de la mémoire, les Intel Software Guard Extensions (SGX) et la mémoire persistante virtuelle (vPMEM), qui ne sont pas prises en charge par les machines virtuelles de génération 1. Mais nous y reviendrons plus tard.
Les machines virtuelles Gen1 restaient toujours utiles pour la migration d’environnements legacy, ou lorsque la compatibilité avec d’anciennes images était nécessaire.
En revanche, les VM Gen 2, avec leur firmware UEFI, offrent la possibilité d’exécuter des fonctionnalités modernes comme la virtualisation imbriquée.
Qu’est-ce que le Trusted Launch ?
Azure propose le lancement fiable pour améliorer de manière fluide la sécurité des machines virtuelles (VM) de génération 2. Le lancement fiable protège contre les techniques d’attaque avancées et persistantes. Le lancement fiable se compose de plusieurs technologies d’infrastructure coordonnées qui peuvent être activées indépendamment. Chaque technologie offre une couche de défense supplémentaire contre les menaces sophistiquées.
Concrètement, Trusted Launch combine plusieurs technologies :
Secure Boot : Assure que seuls des composants logiciels signés et vérifiés sont autorisés à se charger pendant le démarrage.
vTPM (TPM virtuel) : Fournit une zone sécurisée pour stocker des clés cryptographiques et d’autres informations sensibles.
Measured Boot : Enregistre et vérifie les mesures du processus de démarrage pour détecter toute modification non autorisée.
Qu’est-ce que le Secure Boot ?
Le Secure Boot est donc une fonctionnalité de sécurité intégrée au niveau du firmware qui garantit que, lors du démarrage du système, seuls des composants logiciels authentifiés et signés numériquement (bootloader, pilotes, etc.) sont chargés.
Cela permet de prévenir l’exécution de code malveillant dès le démarrage, protégeant ainsi le système contre des attaques telles que les bootkits. En vérifiant l’intégrité et l’authenticité des éléments critiques, Secure Boot contribue à renforcer la sécurité globale de la machine.
Quelles sont les différences entre les 2 générations ?
Ce tableau permet ainsi de choisir la génération en fonction des besoins spécifiques en termes de sécurité, performance et compatibilité :
Fonctionnalité
Machines virtuelles Gen 1
Machines virtuelles Gen 2
Exemple / Explication
1. Type de firmware
BIOS
UEFI
Gen 2 utilise l’UEFI, permettant par exemple l’activation du Secure Boot.
2. Support des systèmes d’exploitation
32 bits et 64 bits
Exclusivement 64 bits
Pour un déploiement Windows Server 2019, seule la Gen 2 est compatible en 64 bits.
3. Interface de disque de démarrage
Utilise un contrôleur IDE
Utilise un contrôleur SCSI
Le démarrage sur SCSI en Gen 2 offre de meilleures performances I/O.
4. Secure Boot
Non disponible
Disponible
La sécurité est renforcée grâce au Secure Boot dans les VM Gen 2.
5. Virtualisation imbriquée
Support limité
Support amélioré
Permet d’exécuter Hyper-V dans la VM Gen 2 pour des environnements de test.
6. Temps de démarrage
Démarrage plus classique
Démarrage généralement plus rapide
Une VM Gen 2 peut démarrer plus vite grâce à l’architecture UEFI optimisée.
7. Taille maximale du disque système
Limité selon les anciens standards
Support de disques système de plus grande taille
Idéal pour des OS nécessitant un volume de boot plus important.
8. Virtualisation basée sur la sécurité
Non supportée
Supportée
Permet d’utiliser des fonctionnalités telles que Windows Defender Credential Guard.
9. Gestion de la mémoire
Standard
Optimisée pour des performances supérieures
Amélioration dans la gestion de la mémoire et la réactivité du système dans la Gen 2.
10. Support des périphériques modernes
Compatible avec du matériel plus ancien
Conçu pour exploiter les dernières technologies matérielles
Par exemple, intégration possible d’un TPM virtuel pour renforcer la sécurité.
11. Déploiement et gestion
Basé sur des modèles plus anciens
Optimisé pour une gestion moderne via Azure Resource Manager
Facilite l’intégration avec les nouvelles options de déploiement automatisé dans Azure.
12. Compatibilité des images
Compatible avec un large éventail d’images anciennes
Restreint aux images récentes optimisées pour UEFI
Gen 1 permet d’utiliser des images plus anciennes, alors que Gen 2 cible les OS modernes.
En résumé, le choix entre Gen1 et Gen2 se fera principalement en fonction des exigences de compatibilité et de sécurité :
Gen1 convient aux scénarios où l’héritage et la compatibilité avec des images plus anciennes priment.
Gen2 est privilégiée pour bénéficier d’une meilleure sécurité et de performances optimisées, notamment grâce aux fonctionnalités comme Secure Boot et le vTPM.
Puis-je utiliser des Gen1/Gen2 avec toutes les familles de machines virtuelles Azure ?
Non. Et pour vous aider, Microsoft vous met à disposition cette liste, disponible via ce lien.
Toutes les images OS sont-elles compatible avec Gen2 ?
Non. Les machines virtuelles Gen2 prennent en charge que certaines images OS :
Windows Server 2025, 2022, 2019, 2016, 2012 R2, 2012
Windows 11 Professionnel, Windows 11 Entreprise
Windows 10 Professionnel, Windows 10 Entreprise
SUSE Linux Enterprise Server 15 SP3, SP2
SUSE Linux Enterprise Server 12 SP4
Ubuntu Server 22.04 LTS, 20.04 LTS, 18.04 LTS, 16.04 LTS
Puis-je basculer une VM de Gen1 à Gen2, et inversement ?
Anciennement, il n’était pas possible de facilement convertir directement une VM existante de Gen1 vers Gen2, en raison des différences fondamentales au niveau du firmware et de la configuration des disques. Pour migrer vers une Gen2, il fallait alors bien souvent recréer la machine virtuelle dans la génération cible.
Qu’est-ce que MBR2GPT ?
MBR2GPT est un outil en ligne de commande de Microsoft qui permet de convertir un disque partitionné en MBR vers le format GPT sans perte de données, facilitant ainsi la transition d’un mode BIOS hérité vers un démarrage UEFI.
Depuis peu, Microsoft vient d’ajouter une fonctionnalité, encore en préversion, pour basculer de Gen1 à Gen2 en quelques clics, dont la source est disponible juste ici.
Enfin, voici d’ailleurs une vidéo de Microsoft parlant en détail de l’outil MBR2GPT :
Comme indiqué dans cette vidéo, l’outil MBR2GPT va travailler sur la conversation des partitions de l’OS :
Le processus sur Azure se fait en seulement quelques clics, et je vous propose de tester tout cela 😎💪
Pour réaliser ce test de conversation de génération (encore en préversion), il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Commençons par créer une machine virtuelle de première génération.
Etape I – Création de la machine virtuelle Gen1 :
Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :
Cliquez-ici pour créer votre machine virtuelle :
Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :
Choisissez une taille de machine virtuelle compatible à la fois Gen1 et Gen2 :
Renseignez les informations de l’administrateur local, puis lancez la validation Azure :
Une fois la validation réussie, lancez la création des ressources Azure :
Quelques minutes plus tard, cliquez-ici pour voir votre machine virtuelle :
Ensuite, cliquez-ici pour déployer le service Azure Bastion :
Attendez quelques minutes la fin du déploiement d’Azure Bastion pour continuer.
L’étape suivante consiste à lancer l’utilitaire intégré MBR2GPT afin de valider et de transformer la partition du disque OS au format GPT, et aussi d’ajouter la partition système EFI requise pour la mise à niveau en Gen2.
Etape II – Transformation du disque OS depuis MBR vers GPT :
Une fois Azure Bastion correctement déployé, saisissez les identifiants renseignés lors de la création de votre machine virtuelle :
Autorisez le fonctionnement du presse-papier pour Azure Bastion :
Confirmez le statut du mode BIOS en Legacy :
Les propriétés du disque OS nous confirme l’utilisation du style de partition MBR (Master Boot Record) :
Depuis le menu Démarrer de votre machine virtuelle, puis cliquez sur Exécutez pour ouvrir le programme cmd :
Lancez la commande MBR2GPT suivante pour exécuter la validation MBR vers GPT :
MBR2GPT /validate /allowFullOS
Assurez-vous que la validation de l’agencement du disque se termine avec succès. Ne continuez pas si la validation du disque échoue :
Lancez la commande MBR2GPT suivante pour exécuter la conversion MBR vers GPT :
MBR2GPT /convert /allowFullOS
Obtenez le résultat suivant :
Cliquez-ici pour fermer votre session Windows :
Une fois la session Windows fermée, cliquez-ici pour fermer l’onglet ouvert pour Azure Bastion :
Depuis le portail Azure, arrêtez votre machine virtuelle :
Confirmez votre choix en cliquant sur Oui :
Quelques minutes plus tard, confirmez que la machine virtuelle est en état Arrêté (désallouée).
Encore en préversion, l’activation des mesures de sécurité sur la machine virtuelle n’est pas possible depuis le portail Azure. Il faut donc utiliser Azure Cloud Shell.
Etape III – Activation du vTPM et du Secure Boot :
Mais avant d’activer le vTPM et le Secure Boot sur notre machine virtuelle Azure, il est nécessaire d’activer la fonctionnalité Gen1ToTLMigrationPreview, encore en préversion, sur notre souscription Azure.
Pour cela, cliquez sur le bouton suivant pour ouvrir la fenêtre d’Azure Cloud Shell :
Une fois Azure Cloud Shell d’ouvert en mode PowerShell, saisissez la commande suivante afin de voir si celle-ci est déjà activée :
Validez la mise à jour du profil de sécurité le dans la configuration de la VM :
# Following command output should be `TrustedLaunch
(Get-AzVM -ResourceGroupName myResourceGroup -VMName myVm | Select-Object -Property SecurityProfile -ExpandProperty SecurityProfile).SecurityProfile.SecurityType
# Following command output should return `SecureBoot` and `vTPM` settings
(Get-AzVM -ResourceGroupName myResourceGroup -VMName myVm | Select-Object -Property SecurityProfile -ExpandProperty SecurityProfile).SecurityProfile.Uefisettings
Le changement de génération de notre machine virtuelle est également visible sur le portail Azure :
De même que le profil de sécurité ainsi que les options activées (une fois que vous avez activé le Trusted launch, les machines virtuelles ne peuvent plus être ramenées au type de sécurité Standard) :
Ces options sont encore modifiables depuis l’écran ci-dessous (Microsoft recommande d’activer le Secure Boot si vous n’utilisez pas de pilotes personnalisés non signés) :
Redémarrez votre machine virtuelle :
Reconnectez-vous à celle-ci via le service Azure Bastion :
Constatez la bonne ouverture de session Windows :
Confirmez le statut du mode BIOS en UEFI, de même que l’activation du Secure Boot :
Relancer la validation de l’agencement du disque sur un disque déjà configuré en GPT provoquera une erreur logique :
Les propriétés du disque OS nous confirme l’utilisation du style de partition GUID (GPT), qui est un schéma de partitionnement moderne qui utilise des identifiants uniques (GUID) pour chaque partition :
Etape IV – Activation de services annexes :
Une fois la bascule en Gen2 effectuée, il n’est plus possible d’activer la sauvegarde via Azure Backup avec une police de type standard :
D’ailleurs, l’activation de la sauvegarde après le changement de Gen1 à Gen2 n’a posé aucun souci :
Il en a été de même pour l’activation de réplication pour une machine migrée de Gen1 à Gen2 :
Dans le cadre d’un test de failover, la nouvelle machine virtuelle, créée temporairement, est bien elle aussi en génération 2 :
La connexion via Azure Bastion sur cette machine virtuelle temporaire est bien fonctionnelle :
Conclusion
En conclusion, cette procédure toute simple et réalisée en quelques clics avec MBR2GPT nous démontre que migrer vos machines virtuelles de Gen1 à Gen2 représente bien plus qu’un simple changement de firmware :
Grâce à une sécurité renforcée avec Secure Boot et vTPM, des performances accrues et une prise en charge des disques de plus grande taille.
Adopter Gen2, c’est ainsi investir dans une plateforme plus robuste, performante et alignée avec les exigences actuelles de la sécurité informatique.
D’abord, un grand merci à Merill Fernando pour ses newsletters toujours intéressantes sur Entra, dont voici le lien. Beaucoup d’articles écrits sur ce blog proviennent de différentes sources en anglais, et dont les travaux et réflexions méritent des tests et une retranscription en français. J’ai toujours du plaisir à essayer de comprendre certains types d’attaque visant le Cloud. Je voulais donc partager avec vous un exemple basé sur du phishing et dont la mise en place est d’une grande simplicité
Attention, ce contenu a une vocation strictement éducative. Les techniques et démonstrations présentées ici sont destinées à sensibiliser aux enjeux de la sécurité informatique et à permettre de mieux comprendre les mécanismes d’attaque afin de mieux s’en protéger.
Il ne s’agit en aucun cas d’un incitatif à la réalisation d’actions malveillantes. Nous vous encourageons vivement à rester dans un cadre légal et à utiliser ces informations uniquement pour renforcer la sécurité de vos systèmes. Je décline toute responsabilité quant à l’utilisation abusive de ces connaissances.
Un précédent article décrivant un autre scénario d’attaque, via le Device Code Flow, est disponible juste ici. Plusieurs sources m’ont aidé à écrire ce nouvel article :
zolder.io ont créé une application fonctionnant sur un Cloudflare Worker qui agit comme un proxy malveillant imitant la page de connexion Microsoft. Cette application intercepte les identifiants de connexion et d’autres informations sensibles, facilitant ainsi l’accès non autorisé aux comptes Microsoft, tout en contournant les mesures de sécurité comme l’authentification multi-facteurs classiques.
Nicola Suter, MVP Microsoft, a lui aussi écrit un article inspiré par Zolder.io en démontrant qu’il est possible de créer un kit de phishing AiTM fonctionnant sur Azure. Les fonctions sur Azure peuvent imiter une page de connexion Entra ID, capter les identifiants et automatiser la reprise de session, tout en contournant des mécanismes de détection classiques.
AiTM, kesako ?
Une attaque AITM exploite un proxy intermédiaire pour intercepter les informations d’authentification pendant qu’un utilisateur se connecte à un service légitime, ce qui permet à l’attaquant de détourner la session et de contourner certaines sécurités mises en place par l’authentification multi-facteurs :
Il s’agit d’une nouvelle technique de phishing encore plus efficace. Cette méthode utilise des sites Web usurpés qui déploient un serveur proxy entre un utilisateur cible et le site Web que l’utilisateur souhaite visiter.
Contrairement au phishing classique, elles ne se contentent pas de tromper l’utilisateur pour lui soutirer ses identifiants. Voici en quoi elles consistent :
Interception en temps réel : L’attaquant crée une page de connexion factice qui sert d’intermédiaire (un proxy) entre la victime et le véritable site légitime. Ainsi, l’utilisateur se connecte en pensant accéder au service habituel, tandis que l’attaquant intercepte les identifiants, cookies et autres données sensibles en temps réel.
Bypass des mesures de sécurité : Puisque l’authentification se fait sur la vraie page (via le proxy), même si l’utilisateur passe une authentification multifacteur (MFA), les tokens et sessions générés peuvent être capturés par l’attaquant, qui peut ensuite les réutiliser pour prendre le contrôle du compte.
Utilisation d’outils serverless : Des plateformes comme Cloudflare Workers ou Azure Functions permettent de déployer rapidement ce type d’attaque sans gérer d’infrastructures traditionnelles, rendant ainsi l’attaque plus facile à mettre en œuvre et plus discrète.
L’attaquant peut voler et intercepter le mot de passe de la victime, détourner les sessions de connexion et le cookie de session (un cookie permet d’authentifier un utilisateur chaque fois qu’il visite un site) et ignorer le processus d’authentification, car le phishing AiTM n’est pas lié à une vulnérabilité dans l’authentification.
Oui, il est possible de réduire le risque contre les attaques AITM en mettant en œuvre une combinaison de mesures préventives et de détection. Voici quelques axes de défense :
Authentification renforcée :
MFA résistant au phishing : Adopter des méthodes d’authentification fortes et moins vulnérables au phishing (comme FIDO2, Windows Hello ou l’utilisation de certificats) permet de réduire les risques, car ces solutions reposent sur des mécanismes difficiles à intercepter via un proxy.
Politiques d’accès conditionnel : Restreindre l’accès aux services sensibles uniquement depuis des dispositifs conformes (registered devices) ou depuis des réseaux de confiance peut empêcher l’exploitation des sessions capturées.
Surveillance et détection :
Analyse comportementale : Mettre en place des outils de détection qui surveillent les anomalies dans les logs de connexion (par exemple, des connexions depuis des adresses IP inhabituelles ou issues des plages d’IP cloud reconnues) permet d’identifier rapidement une activité suspecte.
Canary tokens et autres mécanismes de vigilance : Bien qu’ils puissent parfois être contournés, ces outils permettent de détecter des modifications inattendues sur la page de connexion ou d’autres indices d’une attaque.
Sensibilisation des utilisateurs :
Former les utilisateurs à reconnaître les signes d’une tentative de phishing (URL étranges, absence de certificats de sécurité attendus, etc.) est une barrière importante contre ces attaques.
Encourager la vérification de l’authenticité des sites et des notifications de sécurité peut réduire le risque de compromission.
Gestion des sessions et réponses rapides :
En cas de compromission, disposer de procédures de réinitialisation rapides (révocation des sessions, changements de mots de passe, etc.) permet de limiter les dommages.
L’implémentation de solutions de sécurité capables d’alerter en temps réel sur des activités anormales (via par exemple Microsoft Entra ID Protection ou d’autres outils SIEM) renforce la réaction face à une attaque.
Dans cet article, je vous propose donc de tester 3 déploiements d’une application frauduleuse :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Afin de mettre en place notre application frauduleuse de démonstration, nous allons avoir besoin de :
Une licence Microsoft Teams
Une souscription Azure valide pour le déploiement sur Azure (Etape IV)
Commençons par configurer Teams afin que nous puissions recevoir les notifications et les messages lorsque notre utilisateur de test s’est authentifié au travers de notre application frauduleuse.
Etape I – Configuration Teams :
Ouvrez votre console client de Teams afin de créer un nouveau canal dans l’équipe de votre choix :
Une fois le canal Teams créé, cliquez sur le bouton ci-dessous pour ajouter un connecteur externe :
Cliquez-ici pour ajouter le connecteur Webhook entrant en utilisant la barre de recherche :
Cliquez sur Ajouter :
Une fois le connecteur ajouté, cliquez sur Créer :
Copiez l’URI du connecteur Webhook dans un éditeur de texte :
Commençons par tester la méthode de déploiement proposée par zolder.io via Cloudflare.
Etape II – Méthode Cloudflare :
Cloudflare propose justement un plan gratuit qui permet d’utiliser les Cloudflare Workers, une plateforme serverless pour exécuter du code JavaScript.
Pour cela, connectez-vous sur la page suivante, puis créez un compte Cloudflare :
Si nécessaire, vérifiez votre compte Cloudflare grâce à l’e-mail reçu sur l’adresse renseignée :
Une fois sur votre tableau de bord Cloudflare, rendez-vous dans le menu suivant afin de créer un Worker :
Conservez ses propriétés de base, puis cliquez sur Déployer :
Une fois le Worker déployé, modifiez le code par le bouton ci-dessous :
Ouvrez un nouvel onglet vers ce répertoire GitHub, puis cliquez sur le fichier suivant :
Copiez le code du fichier worker.js :
Collez ce dernier dans un éditeur de texte :
Collez l’URI du connecteur Webhook Teams sur la ligne suivante :
Collez l’ensemble pour remplacer le code déjà présent sur votre worker Cloudflare, puis cliquez sur Déployer :
Attendez quelques secondes la mention de la sauvegarde en bas de page :
Cliquez sur ce lien afin d’ouvrir un nouvel onglet sur votre application frauduleuse :
Attendez quelques minutes et/ou rafraîchissez la page web plusieurs fois au besoin afin d’obtenir le résultat suivant :
Renseignez le nom de compte de votre utilisateur de test, puis cliquez sur Suivant :
Renseignez le mot de passe de votre utilisateur de test, puis cliquez sur Suivant :
Cliquez sur Oui :
Constatez la bascule sur la page web avec l’URL officielle de Microsoft, tout en n’étant toujours pas authentifié :
Retournez sur le canal Teams créé précédemment afin de constater l’apparition d’un premier message provenant du connecteur Webhook, et contenant le login et mot de passe de l’utilisateur de test :
Un second message Teams apparaît également dans le fil, ce dernier reprend les différents cookies générés sur le poste de la victime en relation avec le site officiel de Microsoft : login.onmicrosoft.com :
Copiez ce texte de cookies en entier :
Demandez à n’importe quelle IA générative de parser ce texte en JSON avec le prompt suivant :
Convertis cette chaîne de cookies en un snippet JavaScript qui utilise JSON.parse pour créer un tableau d’objets cookies, puis qui les applique avec document.cookie en leur assignant une date d’expiration fixe, comme dans cet exemple :
JSON.parse('[{"name":"ESTSAUTHPERSISTENT","value":"...","path":"/","domain":"login.microsoftonline.com","httpOnly":true},{"name":"ESTSAUTH","value":"...","path":"/","domain":"login.microsoftonline.com","httpOnly":true},{"name":"SignInStateCookie","value":"...","path":"/","domain":"login.microsoftonline.com","httpOnly":true}]').forEach(c => document.cookie = c.name + "=" + c.value + "; expires=Wed, 05 Aug 2040 23:00:00 UTC; path=/");
Copiez / collez le résultat obtenu par l’IA dans un éditeur de texte :
Une fois sur la page ci-dessous, appuyez sur la touche F12 de votre clavier afin d’ouvrir le mode Console de Google Chrome :
Collez le texte de cookies précédemment copié :
Chrome vous affiche une alerte et vous demande de réécrire la phrase suivante :
allow pasting
Collez à nouveau le texte de cookies, appuyez sur la touche Entrée, puis fermer la fenêtre Console :
Toujours sur la page ci-dessous, appuyez sur la touche F5 de votre clavier afin de rafraîchir la page web d’authentification Microsoft :
Une fois la page actualisée, constatez la bonne authentification de votre utilisateur de test grâce à l’exploitation des cookies interceptés par notre application frauduleuse :
Moins d’une heure après la publication de notre application frauduleuse chez Cloudflare, un nouvel e-mail nous informe de la détection de notre application et la fermeture de celle-ci :
La console Cloudflare de notre application frauduleuse devient alors inexploitable :
Enfin, il en est de même côté client pour l’URL générée pour notre application frauduleuse :
Continuons les tests en effectuant un déploiement en local de l’application frauduleuse.
Etape III – Méthode locale :
Rendez-vous sur la page suivante pour télécharger Node.js :
Lancez l’installation de Node.js, puis cliquez sur Suivant :
Cochez la case pour accepter les termes, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Installer :
Une fois Node.js correctement installé, cliquez sur Terminer :
Rendez-vous sur la page suivante pour télécharger les outils d’exécution locale d’Azure Functions :
Lancez l’installation, puis cliquez sur Suivant :
Cochez la case pour accepter les termes, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Installer :
Une fois les outils Azure Functions correctement installés, cliquez sur Terminer :
Rendez-vous sur la page suivante pour télécharger Visual Studio Code :
Cochez la case pour accepter les termes, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Installer :
Une fois Visual Studio Code correctement installé, cliquez sur Terminer :
Ouvrez un nouvel onglet vers ce répertoire GitHub, puis cliquez-ici pour télécharger l’archive au format ZIP :
Décompressez l’archive ZIP dans un dossier local de votre choix :
Ouvrez Visual Studio Code, puis cliquez sur le bouton ci-dessous :
Choisissez le dossier précédemment créé en local :
Confirmez votre confiance en ce dernier :
Ouvrez par le menu suivant la console Terminal intégrée à Visual Studio Code :
Saisissez la commande suivante afin d’ajouter le webhook de votre canal Teams :
func settings add TEAMS_WEBHOOK_URI "https://"
Constatez l’apparition de votre configuration webhook Teams dans le fichier suivant :
Lancez la commande suivante pour installer le package @azure/functions dans votre projet Node.js et l’ajouter comme dépendance dans le fichier package.json.
npm install @azure/functions --save
Lancez la commande suivante pour démarrer l’application frauduleuse en local tout en affichant des informations détaillées de log pour le diagnostic.
func start --verbose
Choisissez node :
Attendez quelques secondes afin de constater le bon démarrages des 4 fonctions de l’application frauduleuse :
Copiez l’URL suivante :
Ouvrez, via Google Chrome en navigation privée, un onglet vers le site web de votre application frauduleuse hébergée sur Azure, renseignez le nom de compte d’un utilisateur de test ainsi que son mot de passe, puis cliquez sur s’authentifier :
Cliquez sur Oui :
Constatez la bascule sur la page web avec l’URL officielle de Microsoft, tout en n’étant toujours pas authentifié :
Retournez sur le canal Teams créé précédemment afin de constater l’apparition :
d’un premier message provenant du Webhook et contenant le login et mot de passe de l’utilisateur de test :
d’un second message Teams apparaît dans le fil, ce dernier reprend les différents cookies générés sur le poste de la victime en relation avec le site officiel de Microsoft : login.onmicrosoft.com :
Copiez ce texte de cookies en entier :
Ouvrez la page web suivante afin de convertir le format des cookies, collez votre texte de cookies précédemment copié, cliquez sur Convertir, puis copiez la valeur sortante parsée en JSON :
Ouvrez Google Chrome en navigation privée, puis rendez-vous sur la page officielle de Microsoft, puis cliquez-ici pour vous authentifiez :
Une fois sur la page ci-dessous, appuyez sur la touche F12 de votre clavier afin d’ouvrir le mode Console de Google Chrome :
Collez le texte de cookies précédemment copié :
Chrome vous affiche une alerte et vous demande de réécrire la phrase suivante :
allow pasting
Collez à nouveau le texte de cookies, appuyez sur la touche Entrée, puis fermer la fenêtre Console :
Toujours sur la page ci-dessous, appuyez sur la touche F5 de votre clavier afin de rafraîchir la page web d’authentification Microsoft :
Une fois la page actualisée, constatez la bonne authentification de votre utilisateur de test grâce à l’exploitation des cookies interceptés par notre application frauduleuse :
Terminons nos tests par un déploiement de notre application frauduleuse sur Azure.
Etape IV – Méthode Azure :
Ouvrez un onglet vers ce répertoire GitHub, puis cliquez-ici pour déployer votre application frauduleuse sur Azure :
Renseignez tous les champs ci-dessous dont également l’URI de votre webhook Teams, puis lancez la validation Azure:
Une fois la validation Azure réussie, lancez la création des ressources :
Attendez environ 10 minutes la fin de la création des ressources Azure, puis cliquez-ici :
Cliquez sur la fonction Azure créée lors du déploiement :
Copiez l’URL de votre application frauduleuse, puis vérifiez la bonne activation des différentes fonctionnalités :
Ajoutez au besoin un domaine personnalisé afin de rendre l’URL de votre site moins suspicieux :
Ouvrez, via Google Chrome en navigation privée, un onglet vers le site web de votre application frauduleuse hébergée sur Azure, renseignez le nom de compte d’un utilisateur de test ainsi que son mot de passe, puis cliquez sur s’authentifier :
Retournez sur le canal Teams précédemment créé afin de constater l’apparition :
d’un premier message provenant du Webhook et contenant le login et mot de passe de l’utilisateur de test :
d’un second message Teams apparaît dans le fil, ce dernier reprend les différents cookies générés sur le poste de la victime en relation avec le site officiel de Microsoft : login.onmicrosoft.com :
Copiez ce texte de cookies en entier :
Ouvrez la page web suivante afin de convertir le format des cookies, collez votre texte de cookies précédemment copié, cliquez sur Convertir, puis copiez la valeur sortante parsée en JSON :
Ouvrez Google Chrome en navigation privée, puis rendez-vous sur la page officielle de Microsoft, puis cliquez-ici pour vous authentifiez :
Une fois sur la page ci-dessous, appuyez sur la touche F12 de votre clavier afin d’ouvrir le mode Console de Google Chrome :
Collez le texte de cookies précédemment copié :
Chrome vous affiche une alerte et vous demande de réécrire la phrase suivante :
allow pasting
Collez à nouveau le texte de cookies, appuyez sur la touche Entrée, puis fermer la fenêtre Console :
Toujours sur la page ci-dessous, appuyez sur la touche F5 de votre clavier afin de rafraîchir la page web d’authentification Microsoft :
Une fois la page actualisée, constatez la bonne authentification de votre utilisateur de test grâce à l’exploitation des cookies interceptés par notre application frauduleuse :
Testons maintenant si l’ajout d’une MFA renforce la protection de notre compte de test.
Etape V – Ajout de Microsoft Authenticator :
Configurez une méthode MFA de type Microsoft Authenticator sur votre utilisateur de test :
Configurez une police d’accès conditionnel sur Entra ID afin d’exiger une méthode MFA à votre utilisateur de test :
Ouvrez, via Google Chrome en navigation privée, un onglet vers le site web de votre application frauduleuse hébergée sur Azure, renseignez le nom de compte d’un utilisateur de test ainsi que son mot de passe, puis cliquez sur s’authentifier :
Réussissez le challenge MFA demandé par Microsoft via la notification reçue sur votre compte Microsoft Authenticator :
Retournez sur le canal Teams précédemment créé afin de constater l’apparition :
d’un premier message provenant du Webhook et contenant le login et mot de passe de l’utilisateur de test :
d’un second message Teams apparaît dans le fil, ce dernier reprend les différents cookies générés sur le poste de la victime en relation avec le site officiel de Microsoft : login.onmicrosoft.com :
Copiez ce texte de cookies en entier :
Ouvrez la page web suivante afin de convertir le format des cookies, collez votre texte de cookies précédemment copié, cliquez sur Convertir, puis copiez la valeur sortante parsée en JSON :
Ouvrez Google Chrome en navigation privée, puis rendez-vous sur la page officielle de Microsoft, puis cliquez-ici pour vous authentifiez :
Une fois sur la page ci-dessous, appuyez sur la touche F12 de votre clavier afin d’ouvrir le mode Console de Google Chrome :
Collez le texte de cookies précédemment copié :
Chrome vous affiche une alerte et vous demande de réécrire la phrase suivante :
allow pasting
Collez à nouveau le texte de cookies précédemment copié, appuyez sur la touche Entrée, puis fermer la fenêtre du mode Console :
Toujours sur la page ci-dessous, appuyez sur la touche F5 de votre clavier afin de rafraîchir la page web d’authentification Microsoft :
Une fois la page actualisée, constatez la bonne authentification de votre utilisateur de test grâce à l’exploitation des cookies interceptés par notre application, sans souci particulier concernant l’instauration de la MFA :
Etape VI – Restriction des adresses IPs :
Configurez une police d’accès conditionnel avec une restriction sur votre adresse IP publique sur votre utilisateur de test afin d’empêcher toute autre lieu de s’y connecter :
L’utilisateur rencontrera alors sur l’application frauduleuse un message lui interdisant l’accès malgré sa bonne localisation :
Aucun cookie ne sera délivré, mais le mot de passe de l’utilisateur sera quand même récupéré :
Etape VII – Ajout d’une méthode MFA résistante au phishing :
Configurez une police d’accès conditionnel sur Entra ID afin d’exiger une méthode MFA résistante au phishing à votre utilisateur de test :
L’utilisateur rencontrera alors sur l’application frauduleuse un message lui interdisant l’accès :
Aucun cookie ne sera délivré, mais le mot de passe de l’utilisateur sera quand même récupéré :
Etape VIII – Restriction des postes locaux :
Configurez une police d’accès conditionnel sur Entra ID afin d’exiger une machine locale jointe à Entra ID pour votre utilisateur de test :
Malgré que la machine soit jointe à Entra ID et conforme, l’utilisateur rencontrera alors sur l’application frauduleuse un message lui interdisant l’accès :
Aucun cookie ne sera délivré, mais le mot de passe de l’utilisateur sera quand même récupéré :
Conclusion
Qu’il s’agisse d’un déploiement via Cloudflare, d’un environnement local ou d’un déploiement sur Azure, cela illustre la facilité avec laquelle ces attaques peuvent être exécutées.
Pourtant, elles soulignent également l’importance cruciale d’une authentification renforcée (avec des solutions telles que FIDO2 ou autres) et de politiques d’accès conditionnel strictes.
La surveillance continue, la gestion proactive des sessions et la sensibilisation des utilisateurs complètent ce dispositif de défense pour mieux protéger les environnements Cloud. Ces mesures, lorsqu’elles sont correctement implémentées, offrent une barrière robuste contre l’exploitation des failles de sécurité et renforcent significativement la protection des systèmes face aux menaces modernes.
Pour information, environ 12 heures après mon déploiement, la fonction Azure était toujours opérationnelle mais l’URL personnalisée avait bien été détectée et bloquée :
Dans la série des démonstrations très intéressantes sur l’intelligence artificielle, j’appelle le RAG local ! Comme toujours, Alex de la chaîne YouTube The Code Wolf nous montre comment en quelques clics il est possible d’installer et tester une IA sur votre poste local, tout en y ajoutant des données spécifiques (RAG) afin d’en améliorer les réponses.
Mais qu’est-ce que le RAG ?
Le Retrieval Augmented Generation (RAG) est une approche novatrice qui combine le meilleur de deux mondes en IA : la recherche d’informations (retrieval, qui ne génère pas de réponse originale) et la génération de contenu (qui ne s’appuie que sur les données de son entraînement). Traditionnellement, les LLM génèrent du contenu en s’appuyant uniquement sur les informations apprises durant leur phase d’entraînement. Le RAG, en revanche, permet au modèle de « consulter » une base de données ou un corpus de documents externes en temps réel pour enrichir sa génération de texte. Cette capacité de recherche améliore significativement la précision, la pertinence et la richesse du contenu généré.
La qualité de la base de données est un élément crucial pour le fonctionnement du RAG. Une base de données riche, variée et actualisée permet au modèle d’acquérir une connaissance approfondie et de générer des réponses plus précises et pertinentes.
La recherche d’informations joue également un rôle important en permettant au RAG de trouver les éléments les plus pertinents dans la base de données et de les utiliser pour inspirer ses réponses.
Voici un exemple des étapes pour mieux comprendre les interactions :
Étape
Description
1. Question
L’utilisateur demande : « Quelle est la vitesse de la lumière dans le vide ? »
2. Embedding de texte
La question est convertie en vecteur (séquence numérique) pour capturer sa signification.
3. Corpus et base de données vectorielle
Les documents sont découpés en passages courts et convertis en vecteurs, stockés dans une base de données vectorielle.
4. Recherche
Le module de recherche compare les vecteurs de la question aux vecteurs des documents pour trouver les plus similaires.
5. Réponse
Le LLM utilise la question et les extraits récupérés pour générer une réponse pertinente : « La vitesse de la lumière dans le vide est de 299 792 458 mètres par seconde »
Mais comment tester le RAG en local ?
Voici un exemple des ressources nécessaires pour y parvenir :
Composant
Description
Bibliothèques et outils
– SentenceTransformers pour les embeddings de texte. – Un modèle de langage comme ollama. – qdrant, Faiss ou Annoy pour la base de données vectorielle.
Données
– Corpus de documents à utiliser pour la recherche. – Données prétraitées et converties en vecteurs.
Environnement de développement
– Python ou .NET – Docker
Serveur RAG
– Framework comme R2R (Ready-to-Run) pour déployer le pipeline RAG. – API pour interagir avec le pipeline.
Faut-il un GPU pour faire du RAG ?
L’utilisation d’un GPU pour mettre en place le RAG n’est pas strictement nécessaire, mais elle peut grandement améliorer les performances, surtout pour les tâches de génération de texte et de traitement de grandes quantités de données. Voici quelques points à considérer :
Sans GPU :
Possible : Tu peux utiliser un CPU pour les tâches de RAG, mais cela peut être plus lent, surtout pour les modèles de langage volumineux.
Limité : Les performances peuvent être limitées, ce qui peut affecter la rapidité et l’efficacité du système.
Avec GPU :
Accélération : Un GPU peut accélérer les calculs nécessaires pour les embeddings de texte et la génération de réponses.
Efficacité : Améliore la capacité à traiter des requêtes en temps réel et à gérer des corpus de données plus importants.
En résumé, bien que l’on puisse mettre en place un système RAG sans GPU, l’utilisation de ce dernier est recommandée pour des performances optimales, surtout si l’on travaille avec des modèles de langage avancés et des bases de données volumineuse.
Voici donc la vidéo de The Code Wolf qui va nous servir de base à notre démonstration :
Son programme, lui-même basé sur les données de ce GitHub, met en place un chatbot intelligent utilisant des données de Zelda, grâce à la technique RAG.
Dans cet article, je vous propose de tester son application via deux machines virtuelles Azure :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Afin de mettre en place une application RAG en local, nous allons avoir besoin de :
Un poste local ayant un GPU puissant pouvant effectuer de la virtualisation
ou
Un tenant Microsoft active
Une souscription Azure valide
Ayant des crédits Azure, je vous propose dans ma démonstration de partir sur la seconde solution. Un petit souci vient malheureusement heurter mon raisonnement : les SKUs de machine virtuelle Azure pouvant faire de la virtualisation n’ont pas de GPU puissant.
Je vais donc créer 2 machines virtuelles Azure :
Machine virtuelle CPU pour Docker + tests RAG CPU
Machine virtuelle GPU pour tests RAG GPU
Commençons par créer la première machine virtuelle CPU.
Etape I – Préparation de la machine virtuelle CPU :
Depuis le portail Azure, commencez par rechercher le service des réseaux virtuels :
Cliquez-ici pour créer votre réseau virtuel :
Nommez ce dernier, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de votre réseau virtuel :
Environ 30 secondes plus tard, la ressource Azure est créée, cliquez-ici :
Cliquez-ici pour déployer le service Azure Bastion :
N’attendez-pas la fin du déploiement d’Azure Bastion, recherchez le service des machines virtuelles :
Cliquez-ici pour créer votre machine virtuelle CPU :
Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :
Choisissez une taille de machine virtuelle présente dans la famille Dasv6 :
Renseignez un compte d’administrateur local, puis cliquez sur Suivant :
Rajoutez ou non un second disque de données, puis cliquez sur Suivant :
Retirez l’adresse IP publique pour des questions de sécurité, puis lancez la validation Azure :
Une fois la validation réussie, lancez la création des ressources Azure :
Quelques minutes plus tard, cliquez-ici pour voir votre machine virtuelle CPU :
Renseignez les identifiants renseignés lors de la création de votre VM :
Acceptez les conditions Microsoft :
Rendez-vous sur la page suivante afin de télécharger la version 9.0 de .NET :
Une fois téléchargée, lancez l’installation :
Une fois l’installation réussie, fermez l’installation :
Rendez-vous sur la page suivante afin de télécharger Visual Studio Code :
Une fois téléchargée, lancez l’installation :
Une fois l’installation réussie, redémarrez la machine virtuelle :
Quelques secondes plus tard, relancez une connexion via Azure Bastion :
Rendez-vous sur la page suivante afin de télécharger Ollama :
Une fois téléchargée, lancez l’installation :
Une fois l’installation réussie, vérifiez via l’URL suivante le bon fonctionnement du service :
http://localhost:11434/
Depuis le menu Démarrer, ouvrez l’application CMD, puis lancez la commande suivante :
ollama pull phi3:mini
Ollama télécharge alors la version mini de Phi3 d’environ 2 Go :
Lancez la seconde commande suivante :
ollama pull nomic-embed-text
Ollama télécharge alors un modèle ouvert d’environ 270 Mo :
Vérifiez la liste des modèles en place avec la commande suivante :
ollama list
Rendez-vous sur la page suivante afin de télécharger Docker en version Desktop :
Conservez ces 2 cases cochées, puis cliquez sur OK pour lancer l’installation :
Attendez quelques minutes que l’installation se termine :
Cliquez-ici pour redémarrer à nouveau la machine virtuelle CPU :
Quelques secondes plus tard, relancez une connexion via Azure Bastion :
Attendez si nécessaire la fin de l’installation de composants additionnels :
Depuis le menu Démarrer de la session Windows, ouvrez l’application Docker :
Acceptez les conditions d’utilisation de Docker :
Cliquez sur le bouton Finaliser :
Cliquez-ici :
Cliquez-ici :
Attendez le démarrage du service de virtualisation Docker :
Une fois le service correctement démarré, vous ne devriez voir pour le moment aucun conteneurs :
Depuis le menu Démarrer, ouvrez l’application CMD, puis lancez la commande suivante :
docker run -p 6333:6333 -p 6334:6334 -d --name qdrant qdrant/qdrant
Cette commande Docker permet de Qdrant, qui est une base de données vectorielle sous forme de conteneur.
Cela te permet d’utiliser Qdrant pour stocker et rechercher des vecteurs dans ton pipeline RAG :
Autorisez Docker à pouvoir passer au travers de Windows Firewall :
Retournez sur la console de Docker afin de constater le bon démarrage du conteneur :
Notre environnement de test est en place, nous allons maintenant pouvoir récupérer l’application et les données RAG.
Etape II – Chargement de la base de données vectorielle :
Ce premier programme effectue plusieurs tâches pour créer une base de données vectorielle avec Qdrant et générer des embeddings de texte à l’aide d’Ollama.
Voici un résumé des étapes :
Création des clients :
Crée un client Qdrant pour interagir avec la base de données vectorielle.
Crée un client Ollama pour générer des embeddings de texte.
Chargement des données :
Charge des enregistrements de différents fichiers JSON (lieux, boss, personnages, donjons, jeux) et les désérialise en objets ZeldaRecord.
Vectorisation des données chargées :
Pour chaque enregistrement, génère un embedding en utilisant le client Ollama.
Crée une liste de structures de points (PointStruct) contenant les embeddings et les informations associées (nom et description).
Insertion des données dans Qdrant :
Crée une collection dans Qdrant pour stocker les enregistrements vectorisés.
Insère les enregistrements dans la base de données Qdrant.
Lancez l’extraction des fichiers dans un dossier local de votre choix :
Ouvrez Visual Studio Code installé précédemment, puis ouvrez le dossier créé :
Confirmez la confiance dans le dossier comme ceci :
Ouvrez le terminal de Visual Studio Code via le menu suivant :
Positionnez-vous dans le dossier populateDb, puis lancez la commande suivante :
dotnet run
Le chargement des données dans la base de données vectorielle commence :
Ouvrez le gestionnaire des tâches Windows afin constater l’utilisation du CPU pour ce traitement :
Quelques minutes plus tard, en fonction de la performance de votre machine virtuelle, le traitement se termine via le message de succès suivants :
Ouvrez la page web suivante afin de constater dans la console qdrant la création de la collection RAG, puis cliquez-ici :
http://localhost:6333/dashboard
Choisissez sur un point présent dans la liste de la collection, puis cliquez ici pour y voir plus détail :
Constatez la représentation graphique de la base de données :
Cliquez sur un des points en relation avec le premier consulté :
Cliquez à nouveau sur un des points en relation avec le second consulté :
Copiez les vecteurs d’un des points consultés :
Ouvrez Notepad pour y coller les valeurs de vecteur afin de voir comment ces derniers sont formulés :
Nos données RAG sont maintenant chargées. Nous allons maintenant pouvoir tester les prompts depuis la seconde partie de l’application.
Etape III – Lancement de prompts IA RAG :
Ce programme va nous permettre de poser des questions sur des sujets liés à Zelda et d’obtenir des réponses pertinentes en utilisant des données spécifiques grâce à la recherche vectorielle et à la génération de texte.
Avant de lancez le programme, vérifiez, et modifiez au besoin la version exacte de celle téléchargée pour phi3, puis sauvegardez vos modifications :
Positionnez-vous dans le dossier RagApp, puis lancez la commande suivante :
dotnet run
Posez une question sans rapport avec l’univers de Zelda dans un premier temps :
Posez ensuite une question en rapport avec l’univers de Zelda :
Constatez les lenteurs de réponse de l’intelligence artificielle et l’utilisation intensive du CPU :
Confirmez la durée d’utilisation du CPU en fonction de la longueur des réponses de l’IA :
Confirmez l’utilisation exclusive du CPU par la commande suivante :
ollama ps
Bien que l’utilisation d’un CPU soit possible pour certaines tâches d’IA, l’absence de GPU peut entraîner des performances réduites, des limitations dans l’utilisation de modèles avancés, une consommation accrue de ressources et des défis en termes de scalabilité.
Nous allons donc continuer les tests avec la mise en place d’une seconde machine virtuelle GPU dans Azure.
Etape IV – Préparation de la machine virtuelle GPU :
Avant de créer la machine virtuelle GPU depuis Azure, créez la règle de firewall Windows suivante sur la première machine virtuelle afin de rendre accessible qdrant :
Recherchez à nouveau le service des machines virtuelles :
Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :
Choisissez une taille de machine virtuelle présente dans la famille N :
Renseignez un compte d’administrateur local, puis cliquez sur Suivant :
Retirez l’adresse IP publique pour des questions de sécurité, puis lancez la validation Azure :
Une fois la validation réussie, lancez la création des ressources Azure :
Quelques minutes plus tard, cliquez-ici pour voir votre machine virtuelle GPU :
Renseignez les identifiants renseignés lors de la création de votre VM :
Acceptez les conditions Microsoft :
Rendez-vous sur la page suivante afin de télécharger la version 9.0 de .NET :
Une fois téléchargée, lancez l’installation :
Rendez-vous sur la page suivante afin de télécharger Visual Studio Code :
Une fois téléchargée, lancez l’installation :
Une fois l’installation réussie, redémarrez la machine virtuelle :
Quelques secondes plus tard, relancez une connexion via Azure Bastion :
Sur cette page, téléchargez le pilote NVIDIA GRID :
Confirmez le dossier de décompression au niveau local :
Attendez environ 30 secondes que la décompression se termine :
Après une rapide vérification système, cliquez sur Accepter et Continuer :
Cliquez sur Suivant :
Une fois l’installation terminée avec succès, cliquez sur Fermer :
Ouvrez le Gestionnaire des tâches Windows afin de constater l’apparition d’une section GPU :
Rendez-vous sur la page suivante afin de télécharger Ollama :
Une fois téléchargée, lancez l’installation :
Une fois l’installation réussie, vérifiez via l’URL suivante le bon fonctionnement du service :
http://localhost:11434/
Depuis le menu Démarrer, ouvrez l’application CMD, puis lancez la commande suivante :
ollama pull phi3:mini
Ollama télécharge alors la version mini de Phi3 d’environ 2 Go :
Lancez la seconde commande suivante :
ollama pull nomic-embed-text
Ollama télécharge alors un modèle ouvert d’environ 270 Mo :
Vérifiez la liste des modèles en place avec la commande suivante :
ollama list
Vérifiez le bon accès à qdrant situé lui sur la machine virtuelle CPU :
Lancez l’extraction des fichiers dans un dossier local de votre choix :
Etape V – Chargement de la base de données vectorielle :
Ouvrez Visual Studio Code, ouvrez le dossier créé, puis indiquez l’IP locale de la machine virtuelle CPU :
Modifiez également 2 fois le nom de la nouvelle collection créée sur la machine virtuelle GPU, puis Sauvegardez :
Positionnez-vous dans le dossier populateDb, puis lancez la commande suivante :
dotnet run
Ouvrez le Gestionnaire des tâches Windows afin constater l’utilisation plus efficace du GPU pour ce traitement de chargement :
Ouvrez la page web suivante afin de constater dans qdrant la création de la seconde collection RAG, puis cliquez-ici :
http://10.0.0.4:6333/dashboard
Etape VI – Lancement de prompts IA RAG :
Avant de lancez le second programme, vérifiez, et modifiez au besoin l’adresse IP, la version de phi3, la collection utilisée, puis Sauvegardez vos modifications :
Positionnez-vous dans le dossier RagApp, lancez la commande suivante, puis posez une question en rapport avec l’univers de Zelda :
dotnet run
Constatez la pleine puissance GPU pour le traitement :
Constatez la rapidité du texte généré par l’IA :
Confirmez l’utilisation du GPU par la commande suivante :
ollama ps
Conclusion
En conclusion, la mise en place d’une IA RAG (Retrieval-Augmented Generation) sur votre propre PC est un processus réalisable, même sans GPU.
Cependant, l’utilisation d’un GPU est fortement recommandée pour améliorer les performances, surtout pour les tâches de génération de texte et de traitement de grandes quantités de données.
Maintenant, il ne reste plus qu’à tester et affiner votre application et vos données pour obtenir des résultats RAG parfait😎
