Intune

Vous avez un Cloud PC qui refuse de provisionner, un Win32 qui ne descend jamais, une session qui rame sans raison apparente, et vous passez trois jours à interroger Intune alors que le coupable est une règle de pare-feu écrite il y a deux ans ? Cet article est fait pour vous. On part d’une VM Windows toute neuve et on va dérouler, capture après capture, un diagnostic réseau complet de vos endpoints Microsoft Intune, Windows 365 et Azure Virtual Desktop, puis on va casser le réseau exprès pour vérifier que l’outil dit bien la vérité.

L’outil en question s’appelle Microsoft Cloud Endpoint Network Health Check. Il est écrit et maintenu par Daniel Bowker, Microsoft MVP sur Windows 365, et publié sous licence MIT sur GitHub:

Il ne s’agit pas d’un produit commercial ni d’un module à installer : c’est un script PowerShell unique, sans dépendance, qui teste en un seul run l’ensemble des prérequis réseau que Microsoft publie sur quatre pages de documentation différentes.

Pour vous guider plus facilement dans cet article, voici des liens rapides :

1. Le vrai problème : des prérequis réseau éparpillés
2. D’où vient l’outil et ce qu’il couvre
3. Workload et Mode : la distinction que tout le monde rate
4. Étape 0 : les prérequis avant de lancer quoi que ce soit
5. Étape 1 : le premier run et la baseline tout verte
6. Lire les résultats : OK, FAIL, DNS!, TLS!, INSP, ZONE, INFO
7. Le lab de pannes : on casse le réseau exprès
8. Du symptôme utilisateur au correctif réseau
9. Ce que l’outil ne fait pas
10. Conclusion et pièges à retenir

1. Le vrai problème : des prérequis réseau éparpillés

Le problème, ce n’est pas la difficulté technique, c’est le périmètre. La documentation Windows 365 le dit noir sur blanc : les prérequis se répartissent sur quatre familles distinctes, l’appareil physique, le service Microsoft Intune, la machine virtuelle session host Azure Virtual Desktop et le service Windows 365.

Although most of the configuration is for the Cloud PC network, end user connectivity occurs from a physical device. Therefore, you must also follow the connectivity guidelines on the physical device network.
Source : Network requirements for Windows 365, Microsoft Learn

Valider le réseau d’un déploiement Cloud Endpoint voulait dire donc ouvrir quatre onglets de documentation Microsoft en parallèle :

Puis extraire à la main les FQDN, les recopier dans un tableur, et lancer une boucle de Test-NetConnection maison en espérant n’avoir rien oublié…

Concrètement, ça donne quoi ? Ça donne un Cloud PC parfaitement provisionné dont l’utilisateur n’arrive pas à se connecter, parce que le poste physique dans l’agence de Lyon sort par un proxy qui ne connaît pas les endpoints du client Windows App. Vous avez validé le réseau Azure, vous n’avez pas validé le réseau du poste. Deux périmètres, deux jeux de règles, deux équipes différentes.

Mon retour terrain : le ticket qui revient le plus souvent n’est pas « rien ne marche », c’est « ça marche pour 90 % des gens ». Et un taux de 90 %, en réseau, c’est presque toujours la signature d’un site, d’un breakout Internet ou d’un profil de proxy qui diverge du reste du parc.

2. D’où vient l’outil et ce qu’il couvre

Le script a une histoire. Il démarre comme un vérificateur réseau Windows 365, publié en février 2026 sous le nom The Ultimate Windows 365 Network Validation Script. Daniel Bowker l’a ensuite élargi bien au-delà de son périmètre initial, et la version 4 marque le vrai basculement : Microsoft Intune obtient sa propre validation dédiée, à côté de Windows 365 et d’Azure Virtual Desktop.

Résultat, la version 4.1 s’appelle désormais Test-CloudEndpointNetworkHealth.ps1. L’ancien nom Test-W365NetworkHealth.ps1 reste disponible comme lanceur de compatibilité, pour ne pas casser les scripts et les runbooks écrits avant le renommage.

Élément	Valeur
Nom du script	Test-CloudEndpointNetworkHealth.ps1
Version couverte ici	v4.1
Auteur	Daniel Bowker, Microsoft MVP Windows 365
Licence	MIT
Dépendances	Aucune, PowerShell seul
Jeu d’endpoints	445 entrées, cloud Microsoft commercial
Périmètre	Microsoft Intune, Windows 365, Azure Virtual Desktop
Fichier de données	Endpoints.csv, téléchargé automatiquement

Le point qui m’a le plus intéressé n’est pas le nombre d’endpoints, c’est la nature des tests. Un script de validation réseau naïf fait un Test-NetConnection sur le port 443 et affiche un joli vert. Celui-ci va nettement plus loin :

vrai handshake TLS avec SNI, pas un simple socket ouvert sur 443
détection de l’inspection SSL probable via l’analyse de la chaîne de certificats
échecs DNS remontés séparément des échecs de port
endpoints wildcard réellement testés quand c’est possible
test UDP réel pour RDP Shortpath
test SNTP/NTP, avec mesure de la dérive d’horloge
vérification d’Azure IMDS et de WireServer
test de connectivité IPv6
mesure de la latence de connexion
détection d’interception par ZTNA ou Secure Web Gateway
validation du port 80 là où Microsoft exige 80 et 443
tests parallélisés et déduplication des couples hôte/port

Cette liste compte douze améliorations, et chacune correspond à un faux positif que vous avez probablement déjà rencontré en production sans le savoir.

3. Workload et Mode : la distinction que tout le monde rate

Au lancement, le script pose deux questions. Elles se ressemblent, elles n’ont rien à voir. C’est le point de design le plus important de l’outil et c’est aussi celui qui provoque le plus de mauvaises interprétations.

La première question, c’est le workload, autrement dit ce que vous validez :

[1] All Cloud Endpoint requirements
[2] Microsoft Intune
[3] Windows 365
[4] Azure Virtual Desktop

Workload égale QUOI, Mode égale OÙ. Retenez ces deux mots et vous ne vous tromperez plus. Un même workload Intune se teste indifféremment depuis un Cloud PC ou depuis un poste physique managé, parce que les prérequis Intune sont des prérequis d’appareil, pas des prérequis de datacenter.

Workload	Ce qui est validé
All	Tout ce qui suit. C’est la valeur par défaut.
Intune	Les prérequis réseau Microsoft Intune publiés pour les appareils Windows
Windows365	Les endpoints du service Windows 365, plus les dépendances AVD, Intune et plateforme Azure sur lesquelles il repose
AVD	Les prérequis Azure Virtual Desktop côté session host et côté client

Le choix de conception à saluer se trouve dans la ligne Windows365. Sélectionner ce workload ne teste pas seulement les FQDN du service Windows 365. Un Cloud PC est un poste managé par Windows 365 qui s’appuie sur Intune, sur les composants de connectivité Azure Virtual Desktop et sur des services de plateforme Azure. Ne tester que les endpoints *.infra.windows365.microsoft.com vous donnerait un résultat entièrement vert alors qu’une vraie dépendance reste bloquée.

Symétriquement, le workload Windows365 exclut volontairement les fonctionnalités Intune optionnelles dont un Cloud PC n’a pas besoin pour être provisionné, managé ou joignable, comme Remote Help et le Microsoft Store. Vous ne verrez donc pas de rouge sur des services que vous n’utilisez pas.

La seconde question, c’est le mode, autrement dit d’où vous testez :

[1] Host / Cloud Network
    (Cloud PC, AVD session host, or Azure VNet VM)
[2] Physical Client Device
    (Intune-managed Windows device, or device connecting to a
     Cloud PC or AVD session host using Windows App)
[3] Both

Attention : Remote Help et Microsoft Store restent dans leurs propres catégories quand vous lancez le workload Intune. Un rouge sur ces lignes ne signifie pas que votre environnement est cassé, juste que vous n’ouvrez pas ces flux. Lisez la catégorie avant de paniquer.

4. Étape 0 : les prérequis avant de lancer quoi que ce soit

Avant la moindre commande, trois règles.

Règle 1, lisez le script avant de l’exécuter. L’auteur documente lui-même la procédure, et c’est tout à son honneur. Un irm | iex exécute du code distant sans que vous ne l’ayez vu, et cette pratique n’a rien à faire dans un environnement de production sans revue préalable :

Invoke-WebRequest https://bowker.cloud/endpointcheck -OutFile .\Test-CloudEndpointNetworkHealth.ps1
notepad .\Test-CloudEndpointNetworkHealth.ps1
.\Test-CloudEndpointNetworkHealth.ps1

Règle 2, exécutez en session élevée. Certaines vérifications de la fabric Azure se comportent différemment hors élévation et peuvent apparaître injoignables alors que tout va bien. Administrateur local suffit, pas besoin d’aller plus loin.

Règle 3, PowerShell 7 de préférence. Windows PowerShell 5.1 fonctionne, mais 7 est la cible recommandée par l’auteur. Pour lancer le script, rien de plus simple et aucune dépendance à installer :

irm https://bowker.cloud/endpointcheck | iex

Ce dernier point mérite d’être souligné : le script ne demande aucun rôle Entra ID, aucun consentement d’application, aucune permission Graph. Il ne lit pas votre tenant. Il teste des sockets. C’est ce qui le rend utilisable par une équipe réseau qui n’a aucun droit dans Intune, et c’est précisément le genre de cloisonnement qu’on rencontre dans les grandes structures.

Voici les paramètres disponibles, tels que documentés dans le dépôt :

Paramètre	Description	Défaut
-Workload	All, Intune, Windows365, AVD	Demandé, puis All
-Mode	1 = Host / Cloud Network, 2 = Physical Client Device, 3 = Both	Demandé, puis 1
-EndpointsCSV	Chemin vers un Endpoints.csv local	Téléchargement auto
-OutputPath	Export des résultats en CSV	Aucun
-NoTlsCheck	Ignore le handshake TLS, TCP uniquement	Off
-NoIntuneIPFilter	Désactive le filtrage optionnel des plages IP Intune. Alias : -NoRegionFilter	Off
-SkipRegionPicker	Ancien nom de paramètre, conservé pour compatibilité	Off
-MaxParallel	Nombre de sondes concurrentes	12

Attention : ne montez pas -MaxParallel à l’aveugle. Douze sondes concurrentes, c’est déjà un profil de trafic qui ressemble beaucoup à du scan sortant. Sur un site protégé par un IPS ou une solution ZTNA agressive, vous risquez de déclencher une alerte SOC ou de vous faire jeter au bout de trente secondes, et vos résultats seront faussés. Prévenez l’équipe sécurité avant le run.

5. Étape 1 : le premier run et la baseline tout verte

Toute la démarche de cet article repose sur une idée simple : un diagnostic ne vaut rien sans point de comparaison. On commence donc par un run de référence sur une machine dont on sait que le réseau est sain, et on garde le résultat sous le coude.

Depuis une console PowerShell élevée :

irm https://bowker.cloud/endpointcheck | iex

Ou, depuis CMD ou la boîte de dialogue Exécuter :

pwsh -ExecutionPolicy Bypass -Command "irm https://bowker.cloud/endpointcheck | iex"

Et pour la baseline de cet article, la version explicite avec export CSV, celle que je vous recommande parce qu’elle vous laisse une trace exploitable à lancer depuis une fenêtre PowerShell :

& ([scriptblock]::Create((irm https://bowker.cloud/endpointcheck))) -Workload All -Mode 2 -OutputPath .\baseline-saine.csv

Mon retour terrain : exportez systématiquement en CSV avec -OutputPath, même quand tout est vert. Le jour où un utilisateur remonte un problème, la comparaison entre le CSV du jour et celui de la mise en service vaut mille suppositions. C’est la même logique qu’un baseline de performance, appliquée au réseau.

6. Lire les résultats : OK, FAIL, DNS!, TLS!, INSP, ZONE, INFO

C’est ici que l’outil se distingue vraiment des scripts maison. La plupart des validations réseau que j’ai vues chez des clients renvoient deux états : ça passe ou ça ne passe pas. Or un problème DNS, un blocage de pare-feu et une inspection SSL cassent tous les trois le service, mais appellent trois correctifs radicalement différents, portés par trois équipes différentes.

Statut	Signification
[ OK ]	Connecté. Sur le port 443, cela signifie un handshake TLS complet avec SNI là où c’est supporté
[FAIL]	Le DNS a résolu, mais la connexion a échoué
[DNS!]	Le nom d’hôte n’a pas résolu
[TLS!]	Le TCP est établi, mais le handshake TLS a échoué
[INSP]	Le TLS aboutit, mais la chaîne de certificats suggère une inspection SSL probable
[ZONE]	Le wildcard n’a pas de nom d’hôte public stable, la zone DNS parente a été validée à la place
[INFO]	Plage IP publiée, vérification propre à Azure, entrée de référence ou autre résultat informatif

Cette granularité change la nature de la conversation. Avec un simple rouge, vous ouvrez un ticket réseau et vous attendez. Avec un [DNS!], vous savez que le pare-feu n’est pas en cause et vous allez voir l’équipe qui gère la résolution de noms. Avec un [INSP], vous savez qu’il faut demander une exclusion d’inspection, pas une ouverture de flux : le flux est déjà ouvert.

Sur ce dernier point, Microsoft est parfaitement explicite dans la documentation Windows 365 :

These traffic interception technologies can cause issues with running Azure network connection checks or Cloud PC provisioning. Make sure no network interception is enforced for Cloud PCs provisioned within the Windows 365 service.
Source : Network requirements for Windows 365, Microsoft Learn

Autrement dit, un environnement où l’inspection SSL est appliquée aux Cloud PC est un environnement hors des rails documentés, et le statut [INSP] est le seul moyen simple que je connaisse de le prouver en une capture d’écran devant l’équipe sécurité.

Deux subtilités à connaître, et elles évitent des faux diagnostics :

Certains endpoints CDN de Windows Update et Delivery Optimization sont volontairement exclus de la validation TLS, parce que les certificats renvoyés par le CDN ne couvrent pas de façon fiable le nom d’hôte Microsoft. Ces entrées sont testées en TCP seul, pour éviter de générer un faux [TLS!].
Les wildcards ne sont plus systématiquement ignorés. Quand il n’existe pas de nom d’hôte public stable derrière, c’est la zone DNS parente qui est validée, d’où le statut [ZONE]. Ce n’est ni un succès complet ni un échec, c’est une validation partielle assumée.

7. Le lab de pannes : on casse le réseau exprès

Le moment de vérité. Un outil de diagnostic qui affiche du vert quand tout va bien, ce n’est pas un exploit. Ce qu’on veut savoir, c’est s’il dit la vérité quand ça va mal, et surtout s’il désigne la bonne cause. J’ai donc monté une VM Windows jetable et j’ai cassé le réseau, panne par panne, avec un run du script après chaque manipulation.

Attention : toutes les manipulations qui suivent se font sur une machine virtuelle jetable, hors production, et de préférence non managée par Intune. Bloquer un port sortant ou casser la résolution DNS sur un poste de production vous fera perdre bien plus de temps que le diagnostic que vous cherchiez à poser.

Voici le rendu du script avant toute modification de la configuration :

Cas n°1 : la résolution DNS est cassée

Le scénario réel derrière ce cas : un serveur DNS interne injoignable, un forwarder mal configuré, ou un split-brain DNS où la zone publique Microsoft n’est plus résolue depuis le réseau interne. C’est fréquent, et c’est très mal diagnostiqué, parce que l’utilisateur décrit un symptôme applicatif alors que le problème est au niveau de la résolution.

La manipulation, dans une console élevée sur la VM de test. On note d’abord la configuration DNS actuelle pour pouvoir la remettre :

Get-DnsClientServerAddress -AddressFamily IPv4

# On pointe la carte vers un resolveur qui n'existe pas
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 127.0.0.1
Clear-DnsClientCache

Puis on relance le script. Le résultat attendu est une avalanche de [DNS!], et surtout aucun [FAIL] : le script doit dire que rien n’a résolu, pas que les ports sont bloqués.

Et là, magie : là où un script maison basé sur Test-NetConnection vous aurait affiché un mur de rouge indifférencié, envoyant l’équipe réseau chercher une règle de pare-feu inexistante pendant deux jours, vous avez immédiatement la bonne piste.

Pour restaurer, remettez l’adresse notée à l’étape précédente, ou repassez en DHCP :

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ResetServerAddresses
Clear-DnsClientCache

Cas n°2 : DNS partiellement cassé, une seule zone tombe

Le cas précédent est brutal et facile à diagnostiquer même sans outil. Le cas vicieux, celui qui coûte vraiment des journées, c’est la panne partielle : tout résout, sauf une famille de noms. Un enregistrement de blocage laissé dans le DNS interne, une entrée hosts oubliée par un collègue en test, une politique de filtrage DNS qui sinkhole une zone.

On simule ça proprement avec le fichier hosts, en pointant un endpoint Windows 365 vers une adresse inexploitable :

notepad C:\Windows\System32\drivers\etc\hosts

Ajouter la ligne suivante, puis enregistrer

192.0.2.1 rdbroker.wvd.microsoft.com

Lancer la commande suivante pour purger le cache :

Clear-DnsClientCache

Ici le nom résout, mais vers une adresse qui ne mène nulle part. Le comportement attendu n’est donc pas le même que dans le cas n°1, et c’est tout l’intérêt de la démonstration. La ligne concernée doit basculer en [FAIL], pas en [DNS!], pendant que le reste du run reste vert :

Le piège classique : sur ce genre de panne, l’utilisateur vous dira que « AVD ne marche pas », alors que le provisioning, l’authentification et Intune fonctionnent parfaitement. Seul le broker de connexion est injoignable. Sans un test endpoint par endpoint, vous cherchez au mauvais endroit.

Pensez à retirer la ligne du fichier hosts et à vider le cache DNS avant de continuer, sinon elle va polluer tous vos runs suivants.

Cas n°3 : le port 5671 bloqué, le grand classique du provisioning

Si vous ne deviez retenir qu’un seul cas de cet article, c’est celui-là. La documentation Windows 365 exige que les endpoints d’enregistrement IoT Hub soient joignables sur deux ports, 443 et 5671, en sortie :

global.azure-devices-provisioning.net      (443 & 5671 outbound)
hm-iot-in-prod-prap01.azure-devices.net    (443 & 5671 outbound)
hm-iot-in-prod-prau01.azure-devices.net    (443 & 5671 outbound)
hm-iot-in-prod-preu01.azure-devices.net    (443 & 5671 outbound)
hm-iot-in-prod-prna01.azure-devices.net    (443 & 5671 outbound)

Or, dans la vraie vie, une équipe réseau qui reçoit une demande d’ouverture pour Windows 365 ouvre le 443 et considère le travail terminé. Le 5671, c’est de l’AMQP, ça ne ressemble pas à du web, et ça passe très souvent à la trappe. Résultat : le Cloud PC ne s’enregistre jamais auprès du service de santé, le provisioning échoue ou reste bloqué, et tous les tests web que vous ferez à la main répondront correctement.

On reproduit la panne avec une règle de pare-feu sortante :

New-NetFirewallRule -DisplayName "LAB Block AMQP 5671" `
    -Direction Outbound `
    -Action Block `
    -Protocol TCP `
    -RemotePort 5671

Puis on relance, en ciblant le workload Windows 365 pour aller droit au but :

.\Test-CloudEndpointNetworkHealth.ps1 -Workload Windows365 -Mode 1

Voilà la démonstration que je cherchais. Le script teste le couple hôte et port, pas seulement l’hôte. Vous voyez le même FQDN en vert sur une ligne et en rouge sur l’autre, et la conversation avec l’équipe réseau devient triviale : le flux existe, il manque un port.

Mon retour terrain : le 5671 est le port oublié numéro un des déploiements Windows 365 avec Azure Network Connection. Juste derrière, le port 80 sur les endpoints où Microsoft exige à la fois 80 et 443, typiquement pour les listes de révocation de certificats. Le script valide ce cas explicitement, et c’est une bonne raison de ne pas se contenter d’un test sur 443.

Nettoyage de la règle une fois la capture prise :

Remove-NetFirewallRule -DisplayName "LAB Block AMQP 5671"

Cas n°4 : l’UDP coupé, la session qui rame sans jamais tomber

Celui-ci est le plus sournois de tous, parce qu’il ne produit aucune erreur. Rien ne tombe. L’utilisateur se connecte, travaille, et vous dit simplement que « c’est mou ». Vous regardez les logs, tout est vert, et vous concluez à un problème de perception.

Ce qui se passe réellement, la documentation Azure Virtual Desktop l’explique très bien. RDP démarre sur un transport TCP en reverse connect, puis tente d’établir la session en UDP. Si l’UDP réussit, le TCP est abandonné. Sinon, le TCP sert de solution de repli :

By default, the Remote Desktop Protocol (RDP) begins a TCP-based reverse connect transport, then tries to establish a remote session using UDP. If the UDP connection succeeds the TCP connection drops, otherwise the TCP connection is used as a fallback connection mechanism.
Source : RDP Shortpath for Azure Virtual Desktop, Microsoft Learn

Ce mécanisme de repli est une excellente idée pour la disponibilité, et une catastrophe pour le diagnostic : il transforme une panne franche en dégradation silencieuse. C’est exactement la raison pour laquelle le test UDP réel de RDP Shortpath est, à mon sens, la fonctionnalité la plus sous-estimée de ce script.

Pour reproduire, on bloque l’UDP sortant sur la VM de test. Lancez d’abord un run normal et relevez dans la sortie le port UDP effectivement testé par le script pour Shortpath, puis créez la règle correspondante :

New-NetFirewallRule -DisplayName "LAB Block UDP Shortpath" `
    -Direction Outbound `
    -Action Block `
    -Protocol UDP `
    -RemotePort 3478

Relancez ensuite en mode client, puisque c’est le poste physique qui initie la négociation Shortpath :

.\Test-CloudEndpointNetworkHealth.ps1 -Workload AVD -Mode 2

Regardez bien cette capture. C’est le seul rouge de tout le run. Sans ce test, votre validation réseau aurait été déclarée conforme à 100 %, et vous auriez cherché la cause du côté du dimensionnement du Cloud PC ou de la carte graphique. Une ligne rouge, quelques secondes de lecture, et vous savez qu’il faut aller ouvrir l’UDP sortant.

Remove-NetFirewallRule -DisplayName "LAB Block UDP Shortpath"

Les cas que je n’ai pas provoqués, mais que le script sait détecter

Par souci d’honnêteté, je ne décris ici que ce que j’ai réellement cassé et observé. Trois autres capacités de l’outil méritent d’être connues, même si je ne les ai pas mises en scène dans ce lab :

l’inspection SSL, qui remonte en [INSP] lorsque la chaîne de certificats renvoyée ne correspond pas à ce que Microsoft présente normalement
le handshake TLS qui échoue alors que le TCP passe, qui remonte en [TLS!], typiquement quand un Secure Web Gateway accepte le socket puis refuse le nom d’hôte au moment du SNI
la dérive d’horloge, mesurée via le test SNTP/NTP, cause classique et rarement soupçonnée d’échecs d’authentification

Si vous disposez d’un proxy d’inspection dans votre environnement de test, ces trois cas se provoquent facilement et feraient un excellent complément à ce lab.

8. Du symptôme utilisateur au correctif réseau

Voici la table de correspondance que j’ai construite à partir de ce lab. C’est elle que je garderais sous le coude en support N2, parce qu’elle part de ce que l’utilisateur dit, pas de ce que la console affiche.

Ce que dit l’utilisateur	Statut renvoyé par le script	Où aller chercher
Plus rien ne fonctionne depuis ce matin	[DNS!] massif	Résolution de noms, forwarders, serveurs DNS de la carte réseau
Windows 365 ne marche pas, mais je reçois mes mails	[FAIL] isolé sur un endpoint	Filtrage DNS, entrée hosts, sinkhole sur une zone précise
Mon Cloud PC est resté en cours de provisioning	[FAIL] sur azure-devices.net en 5671	Pare-feu sortant, port AMQP non ouvert
C’est lent, mais ça marche	Échec du test UDP Shortpath	UDP sortant bloqué, repli TCP en cours
Ça marche à Paris, pas à Lyon	Résultats divergents entre deux runs	Breakout Internet local, profil de proxy par site
Je n’arrive pas à me connecter mais le Cloud PC est vert dans Intune	Échecs en Mode 2 uniquement	Réseau du poste physique, pas le réseau Azure

La dernière ligne mérite un mot. C’est le scénario le plus courant et le plus mal traité, parce que les deux équipes concernées regardent chacune leur périmètre et le déclarent sain. Lancer le script en Mode 2 depuis le poste de l’utilisateur qui se plaint tranche le débat en trois minutes.

9. Ce que l’outil ne fait pas

Un article qui ne présente que les qualités d’un outil ne vous sert à rien. Voici les limites, et elles sont d’ailleurs documentées honnêtement par l’auteur, ce qui est suffisamment rare pour être signalé.

Le jeu d’endpoints couvre le cloud Microsoft commercial. Si vous êtes en GCC, GCC High ou dans un cloud souverain, les FQDN diffèrent et ce jeu de données ne vous concerne pas.
Le workload Intune valide les prérequis réseau publiés par Microsoft pour les appareils Windows. Il ne prétend pas tester tous les endpoints de tous les produits qui s’intègrent à Intune.
Les produits qui disposent de leur propre documentation réseau, comme Microsoft Defender for Endpoint ou Security Copilot, ont des prérequis supplémentaires non couverts ici.
Le script teste la connectivité, pas la configuration du tenant. Un flux ouvert ne garantit pas qu’une stratégie Intune soit correctement ciblée.
Il ne mesure pas la bande passante ni la qualité de la liaison sous charge. La latence est reportée, mais ce n’est pas un outil de capacity planning.

Cinq limites, aucune n’est rédhibitoire, et toutes sont assumées par le périmètre annoncé. C’est un outil de diagnostic de connectivité, il fait ce qu’il dit.

Attention : le fichier Endpoints.csv est téléchargé automatiquement depuis GitHub à chaque exécution. Sur un réseau très fermé, c’est justement ce téléchargement qui va échouer en premier. Récupérez le CSV depuis un poste ayant accès à Internet et passez-le en local avec -EndpointsCSV, sinon vous allez diagnostiquer l’absence d’accès à GitHub plutôt que votre problème réel.

10. Conclusion et pièges à retenir

Voilà, en une commande et quatre pannes provoquées, nous avons vérifié qu’un script PowerShell gratuit, sans dépendance et sans le moindre droit sur le tenant, sait faire la différence entre un DNS cassé, un port fermé et un transport UDP absent. C’est exactement ce qu’on demande à un outil de diagnostic.

Concrètement, ça donne quoi ? Vous gagnez la capacité de qualifier un incident réseau avant de l’escalader. Vous arrivez devant l’équipe réseau avec une ligne précise, un hôte, un port, un protocole et un statut, au lieu d’un « Windows 365 ne marche pas » qui va tourner en boucle pendant une semaine.

Les cinq pièges à retenir :

Ne confondez pas Workload et Mode. Le premier dit ce que vous validez, le second dit d’où vous testez. Un run en Mode 1 ne vous apprend rien sur le poste de l’utilisateur.
Exécutez en session élevée, sans quoi les vérifications de la fabric Azure peuvent apparaître en échec alors qu’elles vont bien.
Le port 5671 n’est pas optionnel pour Windows 365. Un pare-feu qui n’ouvre que le 443 casse le provisioning sans jamais produire d’erreur web.
Un run entièrement vert en TCP ne prouve rien sur la qualité de session. Si l’UDP est bloqué, RDP bascule silencieusement sur son repli TCP et l’utilisateur subit sans que rien ne remonte.
Gardez une baseline. Exportez en CSV le jour de la mise en service, c’est ce qui vous permettra de comparer le jour où ça se dégrade.

Foncez tester. Le script est sous licence MIT, il ne demande aucun droit, il tourne sur une VM jetable en trois minutes, et le pire qui puisse vous arriver est de découvrir que votre réseau n’est pas aussi conforme que vous le pensiez. Ce qui, précisément, est le but recherché.

Tout le mérite revient à Daniel Bowker, qui écrit, maintient et documente cet outil. Le code se trouve sur le dépôt GitHub du projet.

🤖

Contenu assisté par IA Cet article a été rédigé avec l’assistance d’une intelligence artificielle et relu par l’auteur. Conformément à l’AI Act (UE) en vigueur depuis le 2 août 2026.

Fin des IPs basiques sur les VPNs basiques

Si vous avez lu mon article de juillet 2025 sur les VPN Azure et la deadline du 30/09, vous vous souvenez du test avec une VPN Gateway Basic SKU avec une IP publique dynamique. Le verdict était brutal : suppression de la connexion, suppression de la gateway, impossibilité de migrer l’IP dynamique, création d’une nouvelle IP Standard, recréation complète de la gateway, changement d’adresse IP à la clé. Un calvaire. Bonne nouvelle : Microsoft a depuis simplifié la procédure pour les VPN Gateways Basic SKU. En 2026, c’est un clic dans le portail, sans coupure réseau, sans changement d’IP, en moins de cinq minutes.

Pour rappel, jusqu’ici les VPN Gateways Basic SKU pouvaient être créées avec une IP publique Basic SKU. Azure a migré ces IPs en interne vers des IPs Standard SKU depuis. Il reste une dernière action à faire côté client : supprimer la référence à l’ancienne ressource IP Basic dans la configuration de la gateway. C’est ce qu’on va faire ensemble, capture après capture.

Attention : cet article concerne uniquement la VPN Gateway Basic SKU (le SKU développement/lab, sans SLA). Si vous avez une gateway VpnGw1 à VpnGw5 ou un SKU legacy (Standard, High Performance), le processus est différent : utilisez l’outil de migration dédié dans la Configuration de la gateway. Ce n’est pas ce dont on parle ici.

Pour vous guider plus facilement dans cet article, voici des liens rapides :

1. Pré-requis : êtes-vous concerné ?
2. Étape 0 : identifier la présence de la référence IP Basic
3. Étape 1 : vérifier la validation dans le portail
4. Étape 2 : supprimer la référence IP Basic
5. Étape 3 : vérifier le résultat
6. Étape 4 : supprimer l’ancienne ressource IP Basic
7. Pièges à éviter
8. Questions fréquentes
9. Conclusion

1. Pré-requis : êtes-vous concerné ?

Avant de toucher quoi que ce soit, vérifiez que vous êtes bien dans le cas de figure de cet article. Le piège classique : confondre « VPN Gateway Basic SKU » et « IP publique Basic SKU ». Ce sont deux ressources distinctes. Ici, on parle bien du SKU de la gateway elle-même.

Situation	Action
VPN Gateway Basic SKU avec une référence à une IP publique Basic SKU	✅ Vous êtes concerné par cet article
VPN Gateway Basic SKU sans référence IP Basic (déjà nettoyée)	✅ Rien à faire, vous êtes bon
VPN Gateway VpnGw1 à VpnGw5 (non-AZ ou AZ)	❌ Pas cet article : utiliser l’outil « Migrate to Standard IP » dans Configuration
VPN Gateway SKU legacy (Standard, High Performance)	❌ Pas cet article : suivre le guide de migration dédié Microsoft

Pour rappel, la VPN Gateway Basic SKU est un SKU développeur, sans SLA. Elle ne retire pas, contrairement à ce que beaucoup pensaient (moi y compris, au moment de mon article 2025). Microsoft a confirmé qu’elle reste disponible : c’est uniquement la référence à l’IP Basic qui doit être nettoyée.

2. Étape 0 : identifier la présence de la référence IP Basic

Deux façons de vérifier si votre gateway est concernée : depuis la CLI Azure ou directement depuis le portail.

Via Azure CLI : récupérez d’abord l’ID de l’IP publique associée à votre gateway.

az network vnet-gateway show \
    --name <nom-de-votre-gateway> \
    --resource-group <votre-resource-group> \
    --query "ipConfigurations[].publicIpAddress.id" \
    --output tsv

Copiez l’ID retourné, puis vérifiez le SKU de cette IP :

az network public-ip show \
    --ids <id-copié-ci-dessus> \
    --query "sku.name" \
    --output tsv

Si la commande retourne Basic, vous êtes concerné. Si elle retourne Standard, votre gateway est déjà propre :

Via le portail Azure : naviguez vers votre ressource Virtual network gateway. Dans le menu de gauche, sous Settings, cliquez sur Configuration. Si votre gateway est concernée, vous verrez une section Validation avec un bouton Delete Basic Public IP Reference. C’est la confirmation visuelle que vous devez agir.

Si vous ne voyez pas cette section, soit votre gateway n’a plus de référence IP Basic (déjà nettoyée), soit vous n’êtes pas sur un gateway Basic SKU.

3. Étape 1 : vérifier la validation dans le portail

Toujours sur la page Configuration, regardez la section Validation. Chaque ressource listée doit afficher le statut Succeeded avant de pouvoir continuer.

Attention : si une ou plusieurs ressources affichent un statut autre que Succeeded, ne continuez pas. Résolvez d’abord les erreurs signalées avant de déclencher la suppression.

4. Étape 2 : supprimer la référence IP Basic

Toutes les ressources sont en Succeeded ? Le moment de vérité. Cliquez sur le bouton Delete Basic Public IP Reference.

Concrètement, ça donne quoi ? Cette action retire l’association entre la ressource IP publique Basic SKU et la gateway. Ce n’est pas une migration. Azure avait déjà basculé l’IP en interne vers une ressource Standard SKU non visible dans votre subscription : vous ne faites que supprimer le pointeur côté client.

This action removes the association between your Basic SKU public IP address resource and the Basic SKU VPN gateway. It’s not a migration operation. The public IP address itself is already moved internally by Azure to a Standard SKU public IP address resource used by the VPN gateway.
Source : Remove the Basic SKU public IP Reference from a Basic SKU VPN gateway, Microsoft Learn

Mon retour terrain : dans mon article de 2025, le Test III montrait qu’il fallait supprimer la connexion VPN, supprimer la gateway, recréer une IP Standard, et tout reconstruire. L’IP changeait au passage. C’était le comportement de l’époque pour une IP dynamique. La procédure 2026 est radicalement différente pour la Basic SKU Gateway : un bouton, zéro downtime, l’IP reste la même. Microsoft a bien bossé sur ce point.

5. Étape 3 : vérifier le résultat

Une fois l’opération terminée, retournez sur la page de la gateway. Et là, surprise possible : l’adresse IP peut apparaître comme null dans le portail, ou le nom de l’ancienne ressource IP Basic est encore affiché sans lien cliquable.

Attention : ce comportement est un bug cosmétique connu et documenté par Microsoft. La gateway fonctionne parfaitement, l’IP n’a pas changé, et vos connexions S2S/P2S continuent de tourner. Ne paniquez pas.

Pour vérifier l’IP réelle utilisée par la gateway, deux options. Depuis le portail, cliquez sur JSON View en haut à droite de la page Overview de la gateway : les propriétés réelles de la ressource y sont correctement renseignées, avec l’adresse IP effective.

Ou depuis la CLI, via la propriété tunnelIpAddresses :

az network vnet-gateway show \
    --name <nom-de-votre-gateway> \
    --resource-group <votre-resource-group> \
    --query "bgpSettings.bgpPeeringAddresses[0].tunnelIpAddresses[0]" \
    --output tsv

6. Étape 4 : supprimer l’ancienne ressource IP Basic

La suppression de la référence ne supprime pas la ressource IP publique Basic SKU de votre subscription. Elle reste dans votre resource group, et Azure continue de vous la facturer tant que vous ne la supprimez pas manuellement.

Depuis le portail, naviguez vers votre resource group, repérez la ressource de type Public IP address avec le SKU Basic, et supprimez-la. Ou en CLI :

az network public-ip delete \
    --name <nom-de-votre-ip-basic> \
    --resource-group <votre-resource-group>

Une fois supprimée, la facturation de cette ressource s’arrête. La gateway continue d’utiliser une IP Standard SKU gérée en interne par Azure, non visible et non facturée séparément dans votre subscription.

7. Pièges à éviter

Piège n°1 : tenter d’upgrader l’ancienne ressource IP Basic manuellement. Après avoir supprimé la référence, vous pourriez être tenté d’upgrader la ressource IP Basic restante vers un Standard SKU via le portail ou PowerShell. Ne le faites pas. Microsoft a documenté que cette tentative provoque un état de provisionnement Failed sur la ressource. La bonne action est la suppression pure et simple, pas l’upgrade.

Piège n°2 : paniquer devant l’affichage null dans le portail. Comme vu à l’étape 3, le portail peut afficher l’IP comme null ou encore le nom de l’ancienne ressource Basic sans lien. C’est purement cosmétique. Fiez-vous à la vue JSON ou à la CLI pour vérifier l’état réel, et testez vos tunnels VPN : ils fonctionnent.

Piège n°3 : ne rien faire avant le 30 juin 2026. Si vous ne supprimez pas la référence avant la deadline, votre gateway continuera de fonctionner, mais dans une configuration non supportée, sans garantie de SLA. Microsoft ne viendra pas corriger ça pour vous. La VPN Gateway Basic SKU est déjà un SKU sans SLA en temps normal : sans cette action, elle perd toute couverture de support.

8. Questions fréquentes

Microsoft a publié une FAQ détaillée sur cette procédure. Voici les points que je trouve les plus utiles à avoir en tête.

Cette opération change-t-elle le SKU ou migre-t-elle ma gateway ?

Non. C’est le point qui perturbe le plus : on parle de « migration IP » partout, mais cette opération ne migre rien et ne change pas le SKU de la gateway. Elle supprime uniquement la référence côté client.

This operation doesn’t change the VPN Gateway SKU and doesn’t migrate the gateway. It only removes the reference to the Basic SKU public IP address resource from the gateway configuration.
Source : Remove the Basic SKU public IP Reference from a Basic SKU VPN gateway, Microsoft Learn

Qu’arrive-t-il exactement à mon adresse IP ?

La valeur de l’IP ne change pas. En revanche, après l’opération, la ressource IP publique Basic SKU côté client n’est plus liée à la gateway. L’IP est désormais portée par une ressource Standard SKU interne, non visible dans votre subscription.

The IP address value itself doesn’t change and continues to be used by the VPN gateway. However, after removing the reference: the customer-visible Basic SKU public IP address resource is no longer linked to the gateway. The IP address is now associated with an internal Standard SKU public IP address resource that isn’t visible in your subscription.
Source : Remove the Basic SKU public IP Reference from a Basic SKU VPN gateway, Microsoft Learn

Pourquoi ne puis-je pas accéder à la nouvelle ressource IP Standard créée par Azure ?

Parce qu’elle est intentionnellement invisible. C’est une ressource interne Azure-managed, hors du périmètre de votre subscription. Vous ne pouvez pas la gérer, la voir, ni la facturer.

The Standard SKU public IP address that’s used by the VPN gateway after this process is an internal Azure-managed resource. It isn’t customer-visible or customer-manageable.
Source : Remove the Basic SKU public IP Reference from a Basic SKU VPN gateway, Microsoft Learn

Y a-t-il des changements de facturation ?

L’opération elle-même n’entraîne aucun nouveau frais. Mais l’ancienne ressource IP Basic reste dans votre subscription et continue d’être facturée jusqu’à sa suppression manuelle. La nouvelle IP Standard interne, elle, n’est pas facturée séparément.

Dis-associating the Basic public IP reference from your VPN gateway doesn’t introduce any new charges and doesn’t result in additional billing. Once you delete it, billing for that Basic public IP resource stops. Your VPN gateway continues to use an internally managed Standard SKU public IP address provided by Azure. This internal Standard SKU public IP address isn’t customer-visible and isn’t billed separately.
Source : Remove the Basic SKU public IP Reference from a Basic SKU VPN gateway, Microsoft Learn

Que se passe-t-il si je ne fais rien avant le 30 juin 2026 ?

Votre gateway continue de tourner, mais dans une configuration officiellement non supportée. Pas de SLA, pas d’intervention Microsoft. Et contrairement à ce qu’on pourrait espérer, Microsoft ne fera rien à votre place.

If you don’t take action, your VPN gateway will continue running in an unsupported state. The VPN Gateway Basic SKU doesn’t include SLA guarantees and isn’t intended for production use. Microsoft won’t automatically modify or clean up resources in your subscription. Your gateway might continue to function, but reliability, availability, and support aren’t guaranteed.
Source : Remove the Basic SKU public IP Reference from a Basic SKU VPN gateway, Microsoft Learn

9. Conclusion

Voilà, en quatre étapes : vérification CLI ou portail, validation de la section Configuration, clic sur Delete Basic Public IP Reference, suppression de l’ancienne ressource IP Basic. Dix minutes grand maximum, zéro coupure réseau, l’IP ne change pas.

Par rapport à la situation de 2025 décrite dans mon article sur la deadline du 30/09, Microsoft a vraiment simplifié la procédure pour le cas VPN Gateway Basic SKU. En 2025, le seul chemin pour une IP dynamique était la destruction et la recréation complète, avec changement d’IP à la clé. En 2026, c’est un bouton dans le portail.

Les trois pièges à retenir :

Ne pas tenter d’upgrader l’ancienne ressource IP Basic après dissociation, sous peine de la mettre en état Failed.
L’affichage null dans le portail est cosmétique : vérifier via la vue JSON ou la CLI.
Deadline le 30 juin 2026. Microsoft ne fait rien pour vous si vous ne bougez pas.

Foncez tester en lab si vous n’êtes pas encore passé à l’acte, et planifiez la prod dans la foulée. C’est le genre d’opération qui se fait en dix minutes et qui évite une mauvaise surprise après le 30 juin.

Et pendant que vous êtes dans le portail Azure, profitez-en pour jeter un œil au Service Retirement Workbook, accessible depuis Azure Advisor > Workbooks > Service Retirement. Ce classeur liste toutes vos ressources impactées par des retraits Azure en cours, avec les dates d’échéance et les actions recommandées. Je l’avais déjà présenté dans mon article de 2025 et il reste, aujourd’hui encore, le meilleur moyen de ne rien rater dans votre tenant.

Accès sortant par défaut : Microsoft ferme le robinet en septembre 2025

Depuis toujours, Azure offrait une “porte de sortie cachée” vers Internet à toutes les machines virtuelles déployées dans un réseau virtuel sans configuration explicite : le fameux Accès sortant par défaut (Default Outbound Access). En clair, si vous créiez une VM sans NAT Gateway, sans Équilibreur de charge, sans IP publique attachée… eh bien Azure vous donnait quand même un accès internet de secours via une IP publique éphémère. Mais tout cela change bientôt !

À partir du 30 septembre 2025, cette facilité disparaît pour tous les nouveaux réseaux virtuels. Les workloads qui comptaient dessus devront désormais passer par des méthodes explicites de sortie (NAT Gateway, Load Balancer SNAT, ou IP publique directe).

Pas d’inquiétude donc pour vos environnements déjà en place ! Ce changement ne concerne pas les réseaux virtuels déjà déployés avant cette date. Mais une modernisation de ces derniers est à envisager afin de les harmoniser avec les nouveaux réseaux virtuels dépourvus de l’Accès sortant par défaut.

Qu’est-ce que l’Accès sortant par défaut ?

L’Accès sortant par défaut est une connectivité internet implicite que Microsoft Azure attribuait automatiquement aux machines virtuelles créées dans un réseau virtuel sans configuration explicite de sortie.

Dans Azure, lorsqu’une machine virtuelle (VM) est déployée dans un réseau virtuel sans méthode de connectivité sortante explicitement définie, une adresse IP publique sortante lui est automatiquement attribuée.

Cette adresse IP permet la connectivité sortante depuis les ressources vers Internet et vers d’autres points de terminaison publics au sein de Microsoft. Cet accès est appelé « accès sortant par défaut ».

Microsoft Learn

Comment et quand l’accès sortant par défaut était-il utilisé ?

Microsoft décrit ici l’ordre de résolution de la connectivité sortante d’une VM dans Azure par plusieurs tests chaque par ordre de priorité :

Firewall
- NAT Gateway
  - IP publique
    - Équilibreur de charge
      - Accès sortant par défaut

L’accès sortant par défaut n’est donc qu’un dernier recours. Et après la fin septembre 2025, il disparaîtra pour les nouveaux réseaux virtuels, seules les méthodes explicites resteront.

Pourquoi Microsoft le retire ?

Microsoft met fin à ce mécanisme pour trois raisons principales :

La première est la sécurité : cette IP “fantôme” ne figurait souvent dans aucun inventaire, ce qui compliquait la gestion et exposait à des risques.
La deuxième est la stabilité : ces adresses publiques pouvaient changer sans prévenir, cassant certaines intégrations critiques avec des services externes.
Enfin, la troisième est la conformité : dans un contexte d’audit, il était difficile de tracer les flux sortants d’une VM utilisant ce mode implicite. L’objectif est donc de forcer les clients à adopter des méthodes explicites et maîtrisées de connectivité.

Voici un exemple concret avec un Accès sortant par défaut :

Vous déployez une VM, elle se met à parler à internet avec une IP que vous ne connaissiez pas, qui peut changer sans prévenir, et qui n’apparaît pas dans vos inventaires de sécurité. C’était cela l’Accès sortant par défaut.

Dès la fin septembre, Microsoft dit stop à cette approche :

En supprimant cette facilité, Microsoft pousse à adopter des designs réseau clairs, contrôlables et audités. Malgré la contrainte en tant que telle, cela reste une excellente nouvelle pour la gouvernance cloud.

Qui est impacté ?

Tout le monde. Mais seuls les nouveaux réseaux virtuels créés après le 30 septembre 2025 seront concernés :

Après le 30 septembre 2025, les nouveaux réseaux virtuels exigeront par défaut des méthodes de connectivité sortante explicites au lieu d’avoir un repli vers la connectivité d’accès sortant par défaut.

Azure Updates

Les réseaux existants continueront de fonctionner comme avant, mais Microsoft recommande déjà à tous les clients de migrer afin d’éviter les discordances entre les anciens et nouveaux réseaux virtuels :

Toutes les machines virtuelles (existantes ou nouvellement créées) dans les réseaux virtuels existants qui utilisent l’accès sortant par défaut continueront de fonctionner après cette modification. Cependant, nous vous recommandons vivement de passer à une méthode sortante explicite.

Azure Updates

Même confirmation sur le site Learn de Microsoft :

Aucune modification n’est apportée aux réseaux virtuels existants. Cela signifie que les machines virtuelles existantes et les machines virtuelles nouvellement créées dans ces réseaux virtuels continuent de générer des adresses IP sortantes par défaut, à moins que les sous-réseaux ne soient modifiés manuellement pour devenir privés.

Microsoft Learn

Quelles sont les alternatives recommandées ?

Afin de maintenir un accès internet à vos machines virtuelles, plusieurs services sont proposés par Microsoft selon vos besoins :

La solution de référence est le NAT Gateway, qui offre une connectivité sortante hautement disponible, scalable et simple à gérer.
Dans certains cas, on pourra également utiliser un Équilibreur de charge configuré avec des règles SNAT.
Pour des scénarios plus ponctuels, il reste possible d’associer une IP publique directement à une VM, même si cela n’est pas conseillé pour des environnements critiques.
Enfin, dans les architectures plus sécurisées, le trafic sortant peut être centralisé à travers un Azure Firewall, un proxy ou une appliance réseau virtuelle (NVA).

Comment préparer ma migration ?

La première étape est d’inventorier vos workloads et d’identifier ceux qui reposent encore sur ce mode implicite d’Accès sortant par défaut.

Ce script PowerShell parcourt toutes les souscriptions Azure et dresse, pour chaque réseau virtuels et sous-réseaux, l’état de l’option Accès sortant par défaut :

$results = New-Object System.Collections.Generic.List[object]
$subs = Get-AzSubscription -ErrorAction Stop

foreach ($sub in $subs) {
    Set-AzContext -SubscriptionId $sub.Id -Tenant $sub.TenantId | Out-Null
    $vnets = Get-AzVirtualNetwork -ErrorAction SilentlyContinue

    foreach ($vnet in $vnets) {
        foreach ($subnet in $vnet.Subnets) {
            $hasProp = $subnet.PSObject.Properties.Name -contains 'DefaultOutboundAccess'
            $raw = if ($hasProp) { $subnet.DefaultOutboundAccess } else { $null }

            $status = if ($raw -eq $false) { 'Disabled' } else { 'Enabled' }

            $results.Add([PSCustomObject]@{
                SubscriptionName = $sub.Name
                SubscriptionId   = $sub.Id
                ResourceGroup    = $vnet.ResourceGroupName
                VNet             = $vnet.Name
                Region           = $vnet.Location
                Subnet           = $subnet.Name
                DefaultOutbound  = $status
            }) | Out-Null
        }
    }
}

$results |
    Sort-Object SubscriptionName, ResourceGroup, VNet, Subnet |
    Format-Table -AutoSize

Ensuite, choisissez une stratégie adaptée :

Associez une passerelle NAT
Associez un équilibreur de charge
Associez une adresse IP publique
Ajoutez un pare-feu

Puis, testez ensuite vos flux réseau, notamment tout ce qui dépend de l’accès à Internet : mise à jour, activation Windows, appels API externes, DNS.

Quelles sont les limitations des subnets privés ?

Dans un sous-réseau privé entièrement fermé à Internet, certaines contraintes importantes impactent la bonne marche des machines virtuelles.

Plusieurs fonctionnalités essentielles demandent de mettre en place obligatoirement une méthode explicite de connectivité sortante.

Impossibilité d’utiliser les services Microsoft 365
Impossibilité d’activer le système d’exploitation
Impossibilité de mettre à jour le système d’exploitation via Windows Update
Impossibilité d’associer une machine virtuelle à Azure Virtual Desktop
Les routes configurées avec un next hop de type Internet deviennent inopérantes

Note : Les sous-réseaux privés ne s’appliquent pas non plus aux sous-réseaux délégués ou gérés utilisés par des services PaaS. Dans ces scénarios, c’est le service lui-même (par exemple Azure SQL, App Service, etc.) qui gère sa propre connectivité sortante.

Puis-je déjà désactiver l’Accès sortant par défaut avant septembre 2025 ?

Oui, il est déjà possible de désactiver ce mécanisme dans vos réseaux virtuels pour anticiper la transition.

Cela permet de vérifier vos workloads dans des conditions proches de ce qui deviendra la norme à partir de septembre 2025 et d’éviter les mauvaises surprises le jour où le support sera officiellement retiré.

Important : Il est nécessaire d’arrêter/désallouer les machines virtuelles concernées dans un sous-réseau pour que les modifications de l’Accès sortant par défaut soient prises en compte.

Une fois ces choses dites, je vous propose de tester cela depuis un environnement de démonstration afin de voir ce qu’il est actuellement possible de faire ou de ne pas faire de nôtre côté :

Maintenant, il ne nous reste plus qu’à tester tout cela 😎

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer de :

Un abonnement Azure valide
Un tenant Microsoft

Commençons par tester la connectivité à internet depuis un réseau Azure créé avant septembre 2025.

Test I – Connexion internet depuis un sous-réseau non privé :

Dans un réseau virtuel Azure déjà créé, j’ai commencé par créer un premier sous-réseau non privé :

J’ai crée une machine virtuelle sans adresse IP publique associée :

Une fois la VM démarrée, la machine obtient quand même un accès Internet sortant :

Et OneDrive se configure sans problème :

Tout fonctionne comme cela à toujours fonctionné. Passons maintenant à un test reposant sur un sous-réseau virtuel cette fois privé.

Test II – Connexion internet depuis un sous-réseau privé :

Sur ce même réseau virtuel, j’ai crée un second sous-réseau, avec l’option Private subnet cochée :

Une fois connecté à la machine virtuelle, dans les paramétrages Windows, l’état du réseau indique qu’il n’y a plus d’accès Internet :

Impossible d’ouvrir des sites web depuis le navigateur internet :

Windows Update échoue également à télécharger les mises à jour :

L’activation Windows ne se fait pas non plus :

Et cette fois, OneDrive refuse de se configurer :

Et pourtant, j’accède sans problème à un compte de stockage via son URL publique :

Tout montre que l’accès extérieur à Azure, y compris Microsoft 365, est bloqué dans ce sous-réseau privé.

Sur ce second sous-réseau, je décoche l’option précédemment activée, puis je sauvegarde :

Malgré cela, la machine n’a toujours pas retrouvé Internet :

Je tente même un redémarrage de la machine virtuelle depuis le portail Azure :

Mais après ce redémarrage, rien ne change côté accès Internet :

Après un arrêt complet puis un redémarrage manuel, la sortie vers Internet revient :

Cette fois, la VM a bien une IP publique éphémère pour sortir sur Internet :

Ce test nous montre l’impact de cette option sur les ressources externes accessibles à notre machine virtuelle. Continuons avec un test sur le comportement d’Azure Virtual Desktop dont les VMs seraient sur ce type de sous-réseau privé.

Test III – Connexion Azure Virtual Desktop depuis un sous-réseau privé :

Je dispose d’un environnement Azure Virtual Desktop contenant déjà plusieurs machines virtuelles dans le pool d’hôtes :

J’ai donc modifié le sous-réseau AVD pour qu’il soit privé :

J’ai ajouté une nouvelle machine virtuelle via le plan de mise à l’échelle AVD :

La création de la VM se déroule normalement et celle-ci apparaît :

Mais, elle n’a jamais rejoint automatiquement mon Active Directory :

Et elle n’a pas non plus intégré le pool d’hôtes AVD :

Enfin, au bout d’un certain temps, elle s’est même auto-supprimée :

Ce test nous montre qu’un environnement Azure Virtual Desktop déployé après septembre 2025 nécessitera des ressources supplémentaires pour fonctionner correctement.

Continuons nos tests en appliquant les méthodes proposées par Microsoft pour compenser le changement à venir.

Test IV – Connexion internet avec une adresse IP publique :

Je recoche l’option Private subnet sur mon 2ᵉ sous-réseau :

J’y crée une machine virtuelle, cette fois disposant d’une adresse IP publique associée :

La VM a bien accès à Internet, et l’IP vue depuis l’extérieur correspond à l’IP publique de la machine virtuelle :

Voici le coût de cette IP publique dans le Azure Pricing Calculator :

Il s’agit de la solution la plus économique pour retrouver un accès internet. Mais la question va se poser si un grand nombre de machines virtuelles existent. Si l’ajout d’une adresse IP publique sur une machine virtuelle n’est pas sans conséquence sur la sécurité.

Continuons avec le service Azure NAT Gateway.

Test V – Connexion internet avec Azure NAT Gateway :

Je crée un 3ᵉ sous-réseau privé, dédié cette fois à un test avec NAT Gateway :

Je déploie un service NAT Gateway et je lui assigne une IP publique :

Le nouveau sous-réseau privé est bien associé au service NAT Gateway :

Je crée une VM dans ce 3ᵉ sous-réseau :

Les tests montrent que la VM utilise bien l’adresse IP publique du NAT Gateway pour sortir sur Internet :

Je reproduis ensuite ce même test sur le sous-réseau dédié à Azure Virtual Desktop :

Je lance la création d’une 4ᵉ VM AVD :

Cette fois, la VM rejoint correctement mon Active Directory :

Elle est aussi intégrée automatiquement au host pool d’AVD, et devient accessible :

Voici le coût estimé par Azure Pricing Calculator pour un service NAT Gateway et son IP publique :

L’Azure NAT Gateway est un service géré qui permet aux machines virtuelles dans un sous-réseau privé de sortir sur Internet de manière sécurisée, performante et scalable.

Continuons avec le service Azure Firewall.

Test VI – Connexion internet avec Azure Firewall :

Je crée un 4ᵉ sous-réseau privé dédié cette fois à un test avec Azure Firewall :

Je crée aussi le sous-réseau spécifique réservé au service Azure Firewall :

Je déploie un Azure Firewall en SKU Basique pour ce test :

Deux adresses IP publiques sont automatiquement créées pour le Firewall :

Je configure une Firewall Policy avec plusieurs règles et adresses IPs cibles :

Je crée une nouvelle machine virtuelle sur ce nouveau sous-réseau privé :

Enfin je crée une table de routage associée à mon sous-réseau virtuel de test, dont le prochain saut envoie tout le trafic sortant vers l’adresse IP privée de mon Firewall Azure :

Les tests montrent que la sortie Internet se fait bien via l’IP publique de l’Azure Firewall :

Voici le coût estimé par Azure Pricing Calculator pour un service Azure Firewall et ses deux adresses IP publiques :

L’Azure Firewall a un rôle différent d’un NAT Gateway : ce n’est pas juste de la connectivité sortante, c’est une véritable appliance de sécurité managée par Microsoft. Mais d’autres appliances tierces auraient elles-aussi pu faire l’affaire.

Terminons avec un Équilibreur de charge Azure.

Test VII – Connexion internet avec Azure Load Balancer :

Je crée un 5ᵉ sous-réseau privé, cette fois pour tester Azure Load Balancer :

Je crée une nouvelle VM dans ce nouveau sous-réseau privé :

Je déploie un Équilibreur de charge et lui associe une IP publique :

La VM est ajoutée au backend pool :

Je configure une règle SNAT de sortie sur l’Équilibreur de charge :

En me connectant à la VM, je constate que la sortie Internet se fait bien via l’IP publique de l’Équilibreur de charge :

Voici le coût estimé par Azure Pricing Calculator pour un Équilibreur de charge et son adresse IP publique :

Ce service permet aux VM backend de sortir vers Internet sans IP publique dédiée, mais il est limité pour les gros volumes de connexions (NAT Gateway est plus adapté).

Conclusion

La fin de l’Accès sortant par défaut marque une étape clé dans la maturité du cloud Azure. Fini les “raccourcis” implicites : désormais, chaque sortie vers Internet devra être pensée, tracée et gouvernée.

Ce changement n’est pas une contrainte, mais une opportunité :

Opportunité de renforcer la sécurité en éliminant des flux fantômes.
Opportunité d’améliorer la stabilité et la prévisibilité des intégrations.
Opportunité de consolider vos architectures autour de designs réseau clairs, basés sur NAT Gateway, Azure Firewall ou un Équilibreur de charge.

Déployez une passerelle VPN OPNsense

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ésente un tarif particulièrement attractif :

Le 2ème 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.

Forcer le flux TCP sur Azure Virtual Desktop / Windows 365

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 :

REG ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v SelectTransport /t REG_DWORD /d 1 /f

Après modification, la connexion se fait exclusivement en TCP. Cette commande force le serveur à utiliser uniquement TCP pour les connexions RDP.

Déploiement via GPO

Microsoft propose également une stratégie de groupe qui permet de spécifier le protocole RDP à utiliser. Vous pouvez la trouver sous :

Computer Configuration > Administration Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Host > Connections

La politique associée permet de choisir entre :

« 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 :

REG ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" /v fClientDisableUDP /t REG_DWORD /d 1 /f

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.

💪Bastion Premium 💪

Comme tous les services Cloud, Azure Bastion continue d’évoluer et s’améliorer via l’ajout de nouvelles fonctionnalités très pratiques. Au travers de cet article, nous prendrons le temps de refaire un tour du service et de ses changements dans sa gamme et ses fonctionnalités, comme l’enregistrement automatique ou l’accès 100% privé.

Cet article n’est pas le premier à parler d’Azure Bastion sur ce blog, voici un lien vers celui écrit en 2023. Depuis cette date, le produit a subi quelques changements que nous aborderons ici.

Qu’est-ce qu’Azure Bastion ?

Côté Microsoft, le but de ce service de jump n’est pas changé :

Azure Bastion est un service PaaS entièrement managé que vous approvisionnez pour vous connecter en toute sécurité aux machines virtuelles via une adresse IP privée. Il fournit une connectivité RDP/SSH sécurisée et fluide à vos machines virtuelles, directement au travers du protocole TLS depuis le Portail Azure ou via un SSH natif ou un client RDP déjà installé sur votre ordinateur local. Quand vous vous connectez via Azure Bastion, vos machines virtuelles n’ont pas besoin d’adresse IP publique, d’agent ou de logiciel client spécial.

Microsoft Learn

Azure Bastion est donc toujours un service de jump pour accéder aux machines virtuelles sur Azure, que celles-ci soient sous Windows ou Linux.

Le schéma ci-dessous nous montre le tunnel d’accès créé entre Azure Bastion et l’utilisateur initiateur (via une connexion inversée) grâce au protocole TLS :

Bastion fournit une connectivité RDP et SSH sécurisée à toutes les machines virtuelles du réseau virtuel pour lequel il est approvisionné. Azure Bastion protège vos machines virtuelles contre l’exposition des ports RDP/SSH au monde extérieur, tout en fournissant un accès sécurisé à l’aide de RDP/SSH.

Microsoft Learn

J’ai également reposté la vidéo dédiée à Azure Bastion en français juste ici :

Quel est le principal point fort d’Azure Bastion ?

Un seul mot me vient tout de suite en tête : SECURITE.

Comme tout service de jump, Azure Bastion devient de facto la ressource exposée de votre infrastructure Cloud. Dans les faits, ce dernier intègre des fonctions de pare-feu et des mesures périmétriques de sécurité.

De plus, l’accès au service depuis le portail Azure apporte la couche de pré-authentification d’Azure AD. Celui-ci profite alors de toutes ses mesures de sécurité, comme l’Accès conditionnel, la gestion des droits RBAC, etc …

L’approche d’une connexion sécurisée via TLS permet de s’affranchir de règles sécurités lourdes.

Enfin, Azure Bastion mettra tout le monde d’accord grâce au retrait des adresses IP publiques sur vos VMs Azure, car la connexion RDP/SSH entre Bastion et votre machine virtuelle se fera via le réseau virtuel privé Azure, donc grâce et uniquement par son adresse IP privée.

Pour y voir plus clair, Microsoft met à disposition un tableau de ses principaux avantages :

Avantage	Description
RDP et SSH par le biais du portail Azure	Vous pouvez accéder directement à la session RDP et SSH directement dans le portail Azure via une expérience fluide en un seul clic.
Session à distance sur TLS et traversée de pare-feu pour RDP/SSH	Azure Bastion utilise un client web basé sur HTML5 qui est automatiquement diffusé sur votre appareil local. Votre session RDP/SSH utilise TLS sur le port 443. Le trafic peut ainsi traverser les pare-feu de façon plus sécurisée. Bastion prend en charge TLS 1.2. Les versions antérieures de TLS ne sont pas prises en charge.
Aucune adresse IP publique n’est nécessaire sur la machine virtuelle Azure.	Azure Bastion ouvre la connexion RDP/SSH à votre machine virtuelle Azure en utilisant l’adresse IP privée sur votre machine virtuelle. Vous n’avez pas besoin d’une adresse IP publique sur votre machine virtuelle.
Aucune contrainte liée à la gestion des groupes de sécurité réseau (NSG)	Vous n’avez pas besoin d’appliquer des groupes de sécurité réseau sur le sous-réseau Azure Bastion. Comme Azure Bastion se connecte à vos machines virtuelles par le biais d’une adresse IP privée, vous pouvez configurer vos groupes de sécurité réseau pour autoriser RDP/SSH depuis Azure Bastion uniquement. Vous n’avez plus à gérer les groupes de sécurité réseau chaque fois que vous devez vous connecter de manière sécurisée à vos machines virtuelles. Pour plus d’informations sur les groupes de sécurité réseau, consultez Groupes de sécurité réseau.
Vous n’avez pas besoin de gérer un hôte Bastion distinct sur une machine virtuelle	Azure Bastion est un service PaaS de plateforme entièrement géré d’Azure, renforcé en interne pour vous fournir une connectivité RDP/SSH sécurisée.
Protection contre l’analyse des ports	Vos machines virtuelles sont protégées contre l’analyse des ports par des utilisateurs malveillants, car vous n’avez pas besoin de les exposer à Internet.
Renforcement de la sécurité à un seul endroit	Azure Bastion résidant au périmètre de votre réseau virtuel, vous n’avez pas à vous soucier du durcissement de la sécurité de chacune des machines virtuelles de votre réseau virtuel.
Protection contre les exploits zéro-day	La plateforme Azure protège contre les exploits du jour zéro en assurant une sécurité durcie permanente et à jour pour Azure Bastion.

Mais combien coûte Azure Bastion ?

C’est à partir d’ici que les choses ont changé depuis mon dernier article. Il existe maintenant 4 SKUs disponibles pour Azure Bastion :

Développeur
Basic
Standard
Premium

Côté tarif, Microsoft met à disposition une table des tarif d’Azure Bastion sur cette page :

Pour bien se rendre compte des écarts de prix, cela donne les tarifs mensuels suivants :

Comme indiqué au-dessus, Azure Bastion en version Développeur est gratuit, mais votre accès unique repose alors sur une instance partagée d’Azure Bastion :

Pour les autres SKUs, Microsoft le dit et je vous le confirme : Azure Bastion est facturé dès que ce dernier est déployé peu importe son utilisation :

Azure Bastion est facturée toutes les heures à partir du moment où la ressource est déployée jusqu’à sa suppression, quelle que soit l’utilisation des données sortantes. La tarification horaire est basée sur la référence SKU sélectionnée, le nombre d’unités d’échelle configurées et les taux de transfert de données.

Tarification Microsoft

Quel SKU choisir pour Azure Bastion ?

Les fonctionnalités détermineront le SKU le plus adapté à votre besoin :

Fonctionnalité	Référence SKU Développeur	Référence De base	Référence Standard	SKU Premium
Se connecter pour cibler les machines virtuelles dans les mêmes réseaux virtuels	Oui	Oui	Oui	Oui
Se connecter pour cibler les machines virtuelles dans les réseaux virtuels appairés	Non	Oui	Oui	Oui
Prise en charge de connexions simultanées	Non	Oui	Oui	Oui
Accéder aux clés privées des machines virtuelles Linux dans Azure Key Vault (AKV)	Non	Oui	Oui	Oui
Se connecter à une machine virtuelle Linux avec SSH	Oui	Oui	Oui	Oui
Se connecter à une machine virtuelle Windows avec RDP	Oui	Oui	Oui	Oui
Se connecter à une machine virtuelle Linux avec RDP	No	Non	Oui	Oui
Se connecter à une machine virtuelle Windows avec SSH	No	Non	Oui	Oui
Spécifier le port d’entrée personnalisé	No	Non	Oui	Oui
Se connecter à des machines virtuelles à l’aide de Azure CLI	No	Non	Oui	Oui
Mise à l’échelle de l’hôte	No	Non	Oui	Oui
Charger ou télécharger des fichiers	No	Non	Oui	Oui
Authentification Kerberos	Non	Oui	Oui	Oui
Lien partageable	No	Non	Oui	Oui
Se connecter aux machines virtuelles via une adresse IP	No	Non	Oui	Oui

Note : Gardez en tête que pour vous pouvez monter en gamme le SKU de votre Azure Bastion, mais descendre vous sera impossible.

Comment mettre en place Azure Bastion ?

Rien de plus simple, quelques clics suffisent pour déployer Azure Bastion.

Dans cet article, nous allons déployer Azure Bastion, puis tester quelques fonctionnalités des 4 SKUs d’Azure Bastion. Bref, ne perdons pas de temps :

Etape 0 – Rappel des prérequis :

Pour réaliser ce nouvel exercice sur Azure Bastion, dont certaines fonctionnalités sont encore en préversion, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Mon environnement Azure de départ contient déjà 3 machines virtuelles :

Ces 3 machines virtuelles sont réparties sur 2 réseaux virtuels déployés dans 2 régions Azure :

Un appairage entre ces 2 réseaux virtuels est déjà en place :

Pour information, un déploiement rapide d’Azure Bastion est possible depuis une machine virtuelle :

Une autre méthode de déploiement rapide d’Azure Bastion est également disponible depuis un réseau virtuel :

Dans notre cas, nous allons personnaliser le déploiement d’Azure Bastion afin de pouvoir sélectionner le SKU Développeur.

Etape I – Déploiement d’Azure Bastion Développeur :

Comme indiqué en introduction, ce SKU gratuit fonctionne via une ressource Azure Bastion partagée et sécurisée :

L’intérêt principal d’utiliser ce SKU d’Azure Bastion est évidemment son prix, si aucune de ses limitations n’est bloquante pour vous :

Connexion impossible sur les réseaux virtuels appairée
Connexions simultanées impossibles
Authentification Kerberos impossible

Si cela vous convient, recherchez le service Bastion dans la barre de recherche du portail Azure :

Cliquez-ici pour créer votre Azure Bastion :

Renseignez les champs suivants :

Sélectionnez le SKU Développeur :

Constatez la liste réduite des régions Azure disponibles pour ce SKU :

Choisissez votre réseau virtuel déjà en place, puis cliquez sur Suivant :

Constatez que toutes les fonctionnalités annexes sont indisponibles avec ce SKU, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création de votre Azure Bastion :

Attendez environ 1 minute pour que le service soit accessible sur votre environnement :

Sur une machine virtuelle présente sur le même réseau virtuel qu’Azure Bastion, connectez-vous à celle-ci :

La session de bureau à distance Windows s’ouvre bien via le protocole RDP :

Constatez l’URL spécifique de cette session Bastion pointant sur une ressource CDN :

Tentez d’utiliser votre Azure Bastion Développeur sur une autre machine virtuelle présente sur un réseau virtuel appairé au premier, sans succès :

*L’instance d’Azure Bastion **Développeur** déjà en place n’est pas reconnue.*

Sur ce SKU, il est malgré tout possible de restreindre les sources des sessions Bastion :

Bien que son prix soit gratuit, Azure Bastion en version Développeur limite certains besoins. Pour la suite, nous allons donc le migrer vers une gamme supérieure.

Etape II – Déploiement d’Azure Bastion Basic :

A partir de ce niveau de SKU, l’instance Azure Bastion n’est plus partagée mais dédiée à votre infrastructure. Cette intégration s’accompagne d’un sous-réseau dédié aux instances Azure Bastion :

Comparé à Bastion en version Développeur, l’intérêt d’utiliser ce SKU d’Azure Bastion repose sur les arguments suivants :

Connexion au réseaux virtuels appairés
Connexions simultanées
Authentification Kerberos
Intégration du coffre Azure Key Vault pour les clefs Linux

Retournez sur l’instance d’Azure Bastion Développeur déjà en place, puis mettez à jour son SKU en cliquant comme ceci :

A ce moment-là, il vous est demandé de mettre en place une adresse IP publique à votre service Bastion, mais aussi de créer un sous-réseau dédié à ce dernier :

Cliquez-ici pour ajouter un nouveau sous-réseau :

Choisissez dans la liste Azure Bastion, modifiez au besoin l’adressage puis cliquez sur Ajouter :

Une fois le sous-réseau ajouté, cliquez sur la croix en haut à droite :

Une seule option est alors dégrisée avec ce SKU, cochez-là si besoin, puis cliquez sur Appliquer :

Attendez environ 5 minutes pour que le service soit mis à jour sur votre environnement :

Une fois votre Azure Bastion mis à jour, retournez sur une machine virtuelle Windows d’un réseau virtuel appairé, puis lancez une connexion via Bastion comme ceci :

Un nouvel onglet dans votre navigateur ouvre bien une session RDP de votre machine virtuelle :

Refaite le même test sur une machine virtuelle Linux :

Un nouvel onglet dans votre navigateur ouvre bien une session SSH de votre machine virtuelle :

Constatez le changement dans la nature de l’URL pointant cette fois sur un DNS dédié :

Des informations sur les sessions Bastion actuellement en cours sont également disponibles :

Des métriques sur les ressources de votre Azure Bastion sont également visibles :

Enfin, il est également possible de constater les 2 composants Azure déployée sur ce sous-réseau dédié :

Continuons de mettre à jour notre instance Azure Bastion vers un SKU plus avancé.

Etape III – Déploiement d’Azure Bastion Standard :

Comparé à Azure Bastion de base, l’intérêt ce SKU d’Azure Bastion repose sur les arguments suivants :

Connexions via adresse IP
Connexions Linux en RDP
Connexions Windows en SSH
Personnalisation du port d’entrée possible
Augmentation du nombre d’instances
Génération de lien partageable

De nouvelles options sont dégrisées avec ce SKU, cochez-les si besoin, puis cliquez sur Appliquer :

Attendez environ 5 minutes pour que le service soit mis à jour sur votre environnement :

Une fois votre Azure Bastion mis à jour, un nouveau menu dédié aux liens partagés fait son apparition dans les paramètres votre Azure Bastion.

Cliquez-ici pour créer votre premier lien partagé :

Choisissez la machine virtuelle cible, puis cliquer sur Appliquer :

Le nouveau lien partagé s’ajoute aux liens déjà générés, copiez votre lien dans le presse-papier :

Ouvrez un navigateur privé, puis collez votre lien partageable dans la barre d’adresse, renseignez les identifiants de l’administrateur, puis cliquez-ici pour ouvrir la session :

Attendez quelques secondes, puis constatez l’ouverture du bureau à distance Windows :

Après avoir fermé la session Windows ouverte grâce au lien partagé, pensez à supprimer le lien généré :

Retournez sur la configuration d’Azure Bastion afin de faire varier le nombre d’instances, puis cliquez sur Appliquer :

Chaque instance peut prendre en charge 20 connexions RDP simultanées et 40 connexions SSH simultanées pour les charges de travail moyenne.

Si une instance supplémentaire est déployée, un coût additionnel est ajouté :

Azure Bastion propose de choisir le protocole et le port d’entrée pour les machines virtuelles :

Continuons de mettre à jour notre instance Azure Bastion vers un SKU plus avancé.

Etape IV – Déploiement d’Azure Bastion Premium :

Comparé à Azure Bastion Standard, l’intérêt d’utiliser ce nouveau SKU d’Azure Bastion repose sur les arguments suivants :

Enregistrement de session
Déploiement privé uniquement

Toutes les options sont alors dégrisées avec ce SKU, cochez-les si besoin, puis cliquez sur Appliquer :

Attendez environ 5 minutes pour que le service Bastion soit mis à jour sur votre environnement.

Enregistrement de session

Une fois mis à jour, copiez le nom DNS privé de votre service :

Afin de tester l’enregistrement de session d’Azure Bastion, il est nécessaire de créer un compte de stockage :

Une fois le compte de stockage créé, renseignez l’origine en reprenant le protocole https:// suivi du nom DNS privé de votre Azure Bastion.

Cela donne dans mon cas :

https://bst-9c038b3d-e74c-4838-9613-7a38c0f1fda3.bastion.azure.com

Cliquez ici pour créer un conteneur objet blob dédié :

Dans ce nouveau conteneur, créez une clef SAS avec les propriétés suivantes :

Copiez l’URL de votre nouvelle clef SAS :

Retournez sur votre service Azure Bastion afin de rajouter ce stockage :

Collez votre clef SAS, puis cliquez sur le bouton suivant :

Vérifiez l’absence de message d’erreur ou d’avertissement :

Testez l’enregistrement d’une session SSH en ouvrant une nouvelle connexion via Azure Bastion :

Après avoir terminé des manipulations dans votre session SSH, constatez l’apparition d’un blob sur le conteneur créé :

Constatez également l’apparition d’un enregistrement directement visualisable en cliquant ici :

L’enregistrement s’ouvre dans un nouvel onglet avec une barre de lecture :

Testez un second enregistrement pour une session RDP :

Azure Bastion Privé

Note : La mise en place d’une connexion 100% privée pour Azure Bastion déjà en place n’est pas possible après coup :

Il est donc nécessaire de commencer par supprimer votre Bastion déjà en place :

Une fois votre Bastion supprimé, vous pouvez également supprimer son adresse IP publique :

Le déploiement d’Azure Bastion en version privée se décide via la case à cocher suivante :

Une fois déployé, testez une connexion via cet Azure Bastion privé depuis un poste hors d’atteinte du réseau virtuel cible :

Constatez l’échec de cette tentative :

Afin de tester la connexion privée, j’ai créé un second Azure Bastion Standard sur un autre réseau virtuel appairé :

Puis j’ai activé la fonctionnalité lien partageable sur mon Bastion privé :

J’ai ensuite copié le lien partageable généré :

J’ai testé ce lien partageable privé, sans succès, sur mon poste local :

J’ai retesté avec succès ce même lien partageable privé depuis une session ouverte sur mon second Azure Bastion, dont le réseau virtuel est bien appairé à celui contenant mon Bastion privé :

Via cette méthode, j’ai pu me connecter sans souci à ma machine virtuelle de façon 100% privée :

Conclusion

Sécurité et simplicité sont les adjectifs qui définissent très bien Azure Bastion. Azure Bastion permet d’accéder en toute sécurité aux machines virtuelles via RDP/SSH sans nécessiter d’adresse IP publique, ce qui réduit considérablement les risques d’exposition aux menaces comme l’analyse de ports et les exploits zéro-day.

De plus, il centralise le renforcement de la sécurité en une seule couche, éliminant ainsi la nécessité de sécuriser individuellement chaque machine virtuelle. La flexibilité offerte par les différentes architectures et références SKU permet de s’adapter à divers besoins opérationnels tout en garantissant une connectivité fluide et sécurisée, même dans des configurations réseau complexes comme l’appairage de réseaux virtuels.

Azure WAN

Les stratégies de connexion entre des réseaux Cloud et/ou sur site sont déjà possibles grâce aux appairages, aux passerelles VPN et encore bien d’autres. Mais force est de constater qu’Azure WAN simplifie la mise en œuvre d’une architecture multi-réseaux. Et bien figurez-vous que j’ai justement pu enfin trouver le temps pour le tester cet Azure WAN ! 😎

Avant vous parler du test que j’ai réalisé sur ce service, commençons d’abord par quelques notions sur Azure WAN.

Qu’est-ce qu’Azure WAN ?

Azure WAN facilite la connexion des sites distants, des succursales ou des utilisateurs via un réseau centralisé. Cela permet d’intégrer plusieurs réseaux locaux (LAN) sur un WAN global, améliorant ainsi la connectivité et la gestion.

Azure WAN est un concentré de services réseaux déjà disponibles sur le Cloud Microsoft. Il propose de mettre en place et de gérer de façon simple et rapide différents types de liaison dans le Cloud et/ou sur site.

Mais seulement cette simplicité n’est pas un synonyme d’économie : Azure WAN propose dès les premiers liens des puissances assez grandes. Et qui dit performances, dit coûts.

Azure Virtual WAN est un service de mise en réseau qui combine un grand nombre de fonctionnalités de mise en réseau, de sécurité et de routage pour fournir une interface opérationnelle unique.

Microsoft Learn

Voici quelques-unes des fonctionnalités principales :

Connectivité de branche (via l’automatisation de la connectivité à partir d’appareils partenaires Virtual WAN, comme SD-WAN ou CPE VPN).

Connectivité VPN de site à site.

Connectivité VPN d’un utilisateur distant (point à site).

Connectivité privée (ExpressRoute).

Connectivité multicloud (connectivité transitive pour les réseaux virtuels).

Interconnectivité ExpressRoute des VPN.

Routage, Pare-feu Azure et chiffrement pour la connectivité privée.

Microsoft Learn

Grâce à son interface unique et centralisée, les administrateurs réseau peuvent configurer et surveiller facilement l’ensemble du réseau WAN, incluant les connexions des utilisateurs, les VPN, et les passerelles virtuelles. Cela simplifie donc l’administration des réseaux complexes.

Dans quel cas considérer Azure WAN ?

Le service est idéal pour les environnements hybrides ou multicloud, en offrant une connectivité fluide entre les réseaux sur site et divers fournisseurs de cloud.

Azure WAN est avant tout une boîte à outils où les liaisons entre ressources Azure et/ou sur sites sont vraiment très simples à mettre en œuvre.

Quels SKUs sont disponibles pour Azure WAN ?

Azure WAN permet de réduire les coûts en diminuant la nécessité d’équipements réseau sur site. L’approche as-a-service signifie que les entreprises paient uniquement pour ce qu’elles utilisent, réduisant ainsi les coûts d’infrastructure.

A ce jour, 2 SKUs sont déjà disponibles pour Azure WAN. Microsoft nous expose via le tableau ci-dessous les différences :

Type de Virtual WAN	Type de Hub	Configurations disponibles
De base	De base	VPN de site à site uniquement
standard	standard	ExpressRoute VPN utilisateur (point à site) VPN (site à site) Transit de hub à hub et de réseau virtuel à réseau virtuel via le hub virtuel Pare-feu Azure NVA est un WAN virtuel

Autrement dit, l’Azure WAN de base, bien que gratuit (base + traffic), apportera seulement les connexions VPN site à site et aux réseaux virtuels Azure, mais certaines liaisons sont manquantes comme :

Connexion entre les hubs
Connectivité ExpressRoute
Connectivité VPN utilisateur/point à site
Connectivité de réseau virtuel à réseau virtuel Azure
Azure Firewall

Enfin, Il est malgré tout possible de migrer depuis le SKU Basic vers Standard, mais pas l’inverse :

Quels sont les autres coûts liés au services Azure WAN ?

La tarification du service Azure WAN est très fragmenté. La facturation dépendra des différents trafics réseaux, et donc se divisera potentiellement en une myriade de petits frais.

Dans l’image ci-dessous, pas loin de 13 différents types de transfert sont facturés par Microsoft :

Pour y voir plus clair sur le trafic réseaux d’Azure WAN, Microsoft propose différents scénarios concrets disponibles juste là.

Tarification de la liaison :

Microsoft communique également via leur site web le détail tarifaire complet des liaisons réseaux possibles :

Tarification de la données en transit :

Microsoft nous rappelle ici les différents prix au Go de données transférées entre des réseaux sur Azure et/ou sur site :

Afin de comprendre comment déployer Azure WAN, j’ai décidé de recréer une petite infrastructure réseau, répartie sur plusieurs régions Azure :

Par manque de temps et de connaissances, je n’ai pas testé Firewall et la fonctionnalité BGP sur mon test d’Azure WAN.

Mon test d’Azure WAN :

Mon environnement WAN de test est constitué des éléments Azure suivants :

1 Azure WAN avec 2 Azure Hub :

4 réseaux virtuels Azure contenant chacun une machine virtuelle :

2 VPN Gateway Site à Site :

2 VPN Gateway Point à Site avec une configuration P2S VPN globale WAN :

J’ai recréé sur Azure différentes ressources pour simuler deux environnements sur site :

2 réseaux en connexion site à site avec 2 passerelles VPN :

2 réseaux en connexion point à site avec des PCs équipés du client Azure VPN :

Afin d’effectuer mes tests de connectivités entre tous ces réseaux, j’ai également déployé les machines virtuelles suivantes :

Afin d’avoir une vue d’ensemble de l’infrastructure WAN, Microsoft propose une cartographie fidèle avec toutes les liaisons internes et externes :

Toute la configuration WAN côté infrastructure Azure peut s’effectuer directement depuis la page du portail Azure dédiée à mon Azure WAN.

Configuration WAN :

Pour arriver à ce résultat, une fois le WAN déployé, j’ai créé ici les 2 hubs suivants :

J’ai activé les liaisons suivantes via la configuration de mon WAN :

Configuration des 2 hubs :

Pour chacun des 2 hubs, j’ai activé les passerelles VPN Site à Site et Point à Site (30 minutes d’attente par liaison) :

Connexions aux 4 réseaux virtuels Azure :

Depuis la page d’Azure WAN, j’ai connecté les 4 réseaux virtuels internes à mon infrastructure Azure à mes 2 hubs :

J’ai utilisé la route par Default pour chacune des liaisons :

Connexions aux réseaux locaux Site à site :

Depuis la page Azure WAN, j’ai créé 2 sites physiques respectivement connectés à mes 2 hubs :

Pour chacun des 2 sites, j’ai indiqué leur plan d’adressage respectif :

Une fois les 2 liaisons VPN Site à Site déployées et connectées, ces dernières sont alors bien respectivement visibles sur les 2 hubs :

Une fois toutes les connexions internes et externes en place, les différentes routes sont bien visibles sur chacun de mes 2 hubs :

Connexions Points à site :

Toujours sur la page Azure WAN, j’ai mis en place une configuration unique concernant le type de tunnel et la méthode d’authentification Entra ID :

Afin d’assurer une authentification via Entra ID, j’ai mis en place un tunnel Point à Site de type OpenVPN :

Comme mon précédent article parlant déjà du VPN Point à Site, j’ai configuré les informations suivantes en relation avec mon tenant Microsoft :

J’ai installé Azure VPN sur mes 2 PCs situés en mobilité :

La configuration VPN établie par mon WAN repose sur un FQDN unique. Cela permet d’établir la connexion Point à Site vers le hub le plus proche de façon transparente et automatique :

Poste 1 :

Poste 2 :

Une fois la connexion VPN cliente établie, les informations sont visibles sur le hub :

Mon environnement WAN est maintenant en place, il ne me reste plus qu’à tester les accès et la transitivité de l’infrastructure toute entière.

Tests des accès :

Pour cela, j’ai installé le service Azure Bastion sur le réseau virtuel contenant un PC en mobilité :

J’ai démarré la connexion Point à Site via Azure VPN en utilisant le SSO de l’OS :

J’ai pu ouvrir avec succès des connexions RDP vers toutes les machines virtuelles de mon WAN :

Second PC en mobilité ayant une connexion Point à Site ouverte sur l’autre hub
Serveur ayant une connexion Site à Site ouverte sur le même hub
Serveur ayant une connexion Site à Site ouverte sur l’autre hub
Serveurs ayant un appairage de réseau virtuel sur le même hub
Serveurs ayant un appairage de réseau virtuel sur l’autre hub

Le routage vers toutes les machines s’est donc effectuée sans aucun autre composant additionnel qu’Azure WAN lui-même 💪

Surveillance des liaisons :

Une fois le WAN en place, la surveillance des liaisons est indispensable afin d’y remédier au plus vite car ces dernières sont souvent critiques pour un ou plusieurs services de l’entreprise.

Pour cela des métriques sont disponibles via le menu Insights de mon Azure WAN :

De plus, Azure WAN peut s’appuyer sur le service Connection Monitor disponible sous Network Watcher afin d’établir des tests de connectivité et des règles d’alerte.

J’ai configuré Connection Monitor afin d’effectuer des tests ICMP vers Azure, mais aussi vers mes 2 sites physiques :

A peine les tests créés, Connection Monitor affiche les résultats :

Différentes informations sont disponibles sur ces tests :

Afin de simuler une panne, j’ai simplement éteint une machine virtuelle Azure sur site :

A peinte la machine virtuelle éteinte, Connection Monitor indique déjà des échecs dans les tests concernés :

Le détail du test en défaut nous affiche également le routage et même le lieu exact du blocage de la liaison :

Azure Monitor affiche également les 2 alerte déclenchée :

Grâce au groupe d’action configuré sur la règle de l’alerte créée par Connection Monitor, une notification par e-mail me parvient immédiatement :

Afin de retrouver une situation opérationnelle, je rallume la machine virtuelle sur site précédemment éteinte :

Quelques minutes plus tard, les alertes générées sont automatiquement résolues :

De retour sur Connection Monitor, tous les tests repassent alors en vert :

Conclusion

En résumé, Azure WAN offre une solution robuste, sécurisée et évolutive pour connecter et gérer les réseaux distribués à travers le monde. Il simplifie la gestion des infrastructures réseau tout en garantissant des performances et une sécurité optimales, ce qui en fait une option précieuse pour les entreprises cherchant à moderniser leurs infrastructures réseau.

Connectez votre réseau local à Global Secure Access

Restons encore un peu dans la lignée des articles dédiés au Global Secure Access de Microsoft. Abordons cette fois-ci une fonction appelée Remote Network : la connexion d’un réseau local (distant) tout entier à un point Edge du réseau Microsoft. Cette approche est complémentaire aux Clients Global Secure Access installés sur les postes en situation de mobilité.

Si le sujet Global Secure Access vous passionne tout comme moi, je vous invite à lire mes précédents articles sur le sujet :

J’y détaille l’intérêt du service Global Secure Access et la démarche sécuritaire mise en avant par Microsoft.

Qu’est-ce qu’un réseau distant ?

A l’inverse de postes en mobilité, il faut voir ces réseaux comme des réseaux fixes d’une entreprise dont le nombre et la répartition est possiblement mondiale :

Les réseaux distants sont des emplacements distants 🤣 ou des réseaux qui nécessitent une connectivité Internet. Par exemple, de nombreuses organisations ont un siège social central et des filiales dans différentes zones géographiques. Ces filiales ont besoin d’accéder aux données et services d’entreprise. Elles ont besoin d’un moyen sécurisé de communiquer avec le centre de données, le siège social et les travailleurs à distance. La sécurité des réseaux distants est cruciale pour de nombreux types d’organisations.

Les réseaux distants, tels qu’un emplacement de branche, sont généralement connectés au réseau d’entreprise via un réseau étendu dédié (WAN) ou une connexion de réseau privé virtuel (VPN). Les employés de l’emplacement de branche se connectent au réseau à l’aide de l’équipement local du client (CPE).
Microsoft Learn

Comment fonctionne la connectivité réseau à distance Global Secure Access ?

Comme pour une connexion VPN classique, une connexion sécurisée via le service Global Secure Access s’appuie sur un tunnel IP Sec :

Pour connecter un réseau distant à Global Secure Access, configurez un tunnel IPSec (Internet Protocol Security) entre votre équipement local et le point de terminaison Global Secure Access. Le trafic que vous spécifiez est acheminé via le tunnel IPSec vers le point de terminaison Global Secure Access le plus proche.
Microsoft Learn

Pourquoi utiliser Global Secure Access pour nos réseaux ?

Global Secure Access propose une approche plus adaptée que les méthodes traditionnelle (WAN / MPLS) en faisant transiter la donnée via le backbone de Microsoft avec une tarification bien plus abordable que ces concurrents :

Il est de plus en plus difficile de maintenir la sécurité d’un réseau d’entreprise dans un monde de travail à distance et d’équipes distribuées. Security Service Edge (SSE) promet un monde de sécurité où les clients peuvent accéder à leurs ressources d’entreprise n’importe où dans le monde sans avoir à renvoyer leur trafic au siège social.
Microsoft Learn

Qu’est-ce que le Zéro Trust Network Access (ZTNA) ?

L’accès au réseau sans confiance (ZTNA), également connu sous le nom de périmètre défini par logiciel (SDP), est un ensemble de technologies et de fonctionnalités qui permettent un accès sécurisé aux applications internes pour les utilisateurs distants. Il fonctionne sur la base d’un modèle de confiance adaptatif, où la confiance n’est jamais implicite et où l’accès est accordé en fonction du besoin de savoir, sur la base du moindre privilège défini.
Zscaler

De manière plus simple, ZTNA reprend l’approche de ZT en y intégrant en tant que signal d’entrée la couche réseau, afin de rendre les décisions d’accès ou d’interdiction encore plus précises et donc plus sécurisantes :

Afin de se faire une meilleure idée sur le Global Secure Access encore en préversion, je vous propose de réaliser un nouvel exercice. Voici quelques liens vers la documentation Microsoft :

J’ai été assez surpris de voir que Microsoft a même écrit un mode opératoire en simulant comme moi le réseau distant sous Azure 😎

Comme Microsoft, mon but est donc de mesurer l’impact dans l’accès aux services 365 en simulant un réseau distant sous Azure et directement connecté Global Secure Access. Les tâches que nous allons réaliser seront donc les suivantes :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer des éléments suivants :

Un tenant Microsoft
Une souscription Azure valide

Afin de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire de créer une machine virtuelle pour simuler un accès aux services 365 depuis notre réseau distant.

Etape I – Préparation de la VM de test :

Pour cela, rechercher le service Machines virtuelles sur le portail Azure :

Cliquez-ici pour commencer la création de la première machine virtuelle :

Renseignez les informations de base relatives à votre VM en choisissant une image sous Windows Server 2022 :

Choisissez la taille de votre VM, puis définissez un compte administrateur local :

Bloquez les ports entrants, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Retirez l’IP publique, puis cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la première VM, puis attendez environ 2 minutes :

Une fois le déploiement terminé, cliquez-ici pour consulter votre première machine virtuelle :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

Attendez environ 3 minutes que la notification Azure suivante apparaisse :

Notre machine virtuelle est maintenant opérationnelle. La prochaine étape consiste à préparer la connexion VPN côté Azure.

Etape II – Création de la passerelle VPN Azure :

Pour cela, nous allons avoir besoin d’une passerelle VPN Azure. Un ancien article parlait déjà de ce service Azure juste ici.

Recherchez le réseau virtuel créé avec la VM, puis notez sa plage d’adresses réseaux pour la suite :

Profitez-en pour lui ajouter un sous-réseau dédié à la future passerelle VPN :

Cliquez sur Sauvegarder :

Attendez environ 15 secondes que la notification suivante apparaisse :

Recherchez dans le menu Azure le service suivant pour créer la passerelle VPN :

Cliquez-ici pour créer votre passerelle VPN Azure :

Renseignez les informations de base, choisissez le SPU VpnGw1, puis le même réseau virtuel que précédemment :

Désactivez mode actif-actif, activez la fonction BGP, renseignez un numéro ASN valide, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la passerelle VPN, puis attendez environ 30 minutes :

Une fois le déploiement terminé, cliquez-ici afin de récupérer quelques informations sur la passerelle VPN :

Allez dans l’onglet Configuration afin de copier ces informations :

Notre passerelle VPN côté Azure est maintenant en place. Nous devons maintenant configurer Global Secure Access d’Entra ID pour reconnaître les demandes de connexion depuis cette passerelle VPN.

Etape III – Configuration du réseau distant sur GSA :

Rendez-vous sur la page suivante du portail Entra, puis cliquez-ici pour mettre en place la connexion réseau côté Microsoft Entra :

Nommez votre connexion, choisissez la région Azure la plus proche de votre réseau distant, puis cliquez sur Suivant :

Ajoutez un lien réseau à votre connexion :

Renseignez les informations de base en reprenant les informations récupérées de la passerelle VPN, puis cliquez sur Suivant :

Conservez les options suivantes, puis cliquez sur Suivant :

Définissez une clef PSK et conservez-là, puis cliquez sur Suivant :

Cliquez sur suivant :

Cochez la seule case possible à ce jour : seul le traffic vers les services Microsoft 365 sera actuellement routé via cette connexion, puis lancez la validation Entra ID :

Une fois la validation Entra ID réussie, lancez la connexion réseau, puis attendez environ 1 minute :

Une notification Entra ID apparaît alors :

Consultez le menu suivant afin de constater la présence d’un réseau distant uniquement sur le profil Microsoft 365 :

Retournez sur le menu des connexions réseaux afin de récupérer des informations :

Récupérez les 3 informations suivantes pour continuer la configuration de la connexion à la passerelle VPN côté Azure :

La configuration réseau côté Global Secure Access est maintenant terminée. Avançons maintenant côté Azure afin que ce dernier reconnaisse également le réseau GSA.

Etape IV – Configuration du réseau GSA sur Azure :

Retournez sur le portail Azure afin de créer passerelle de réseau local correspondant à la connexion configurée sur Global Secure Access.

Pour cela, recherchez le service suivant sur le portail Azure :

Cliquez-ici pour commencer la création :

Renseignez les informations de base, reprenez l’IP publique récupérée sur Global Secure Access, puis cliquez sur Suivant :

Renseignez les autres informations suivantes provenant de Global Secure Access, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la passerelle de réseau local, puis attendez environ 2 minutes :

Attendez que le déploiement de la passerelle de réseau local soit terminé :

Avant de finaliser la configuration VPN, il serait intéressant de tester une connexion vers les services 365 en y incluant une police d’accès conditionnel potentiellement bloquante.

Etape V – Global Secure Access + Accès Conditionnel :

La signalisation de Global Secure Access fournit des informations sur l’emplacement du réseau à l’accès conditionnel, ce qui permet aux administrateurs de créer des politiques qui limitent l’accès des utilisateurs à des applications spécifiques en fonction de leur utilisation du client Global Secure Access ou d’un réseau distant.
Microsoft Entra

La combinaison de Global Secure Access et de l’Accès Conditionnel va donc permettre de restreindre l’accès à certains services si la connexion via Global Secure Access n’est pas établie.

Pour cela, créez une nouvelle police d’accès conditionnel par le menu suivant :

Spécifiez le groupe d’utilisateurs de test concerné :

Définissez la ou les applications à protéger :

Excluez de cette police les connexions faites via Global Secure Access :

Bloquez l’accès pour toutes les autres tentatives de connexion, activez la police puis sauvegardez-là :

Attendez quelques minutes, puis retournez sur votre VM de test via une session Azure Bastion :

Lancez un ping sur le site outlook.office.com afin de constater l’IP actuelle du service de messagerie de Microsoft :

Ouvrez Edge sur la page office.com afin de vous authentifiez avec un compte 365 de test :

Connectez-vous-y en utilisant l’identité Entra ID de votre compte de test :

Constatez le blocage de l’accès conditionnel mis en place précédemment :

Ce test nous confirme que la connexion GSA via un réseau distant ou le client est maintenant obligatoire pour accéder aux services 365.

Finalisons maintenant la connexion entre notre environnement Azure de test et GSA.

Etape VI – Connexion entre le réseau distant et GSA :

De retour sur le portail Azure, cliquez-ici pour mettre en place la connexion entre la passerelle VPN et Global Secure Access :

Définissez la connexion en IP Sec, puis cliquez sur Suivant :

Renseignez les informations de base dont la clef PSK, cochez la case BGP, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la connexion, puis attendez environ 1 minute :

Attendez que le déploiement de la connexion soit terminé, puis cliquez-ici :

Constatez le statut inconnu de celle-ci :

Retournez sur la page suivante de la passerelle VPN, puis rafraichissez périodiquement afin de constater une changement de status de la connexion :

Le statut devrait changer sous environ 3 minutes :

Consultez la page suivante pour voir les impacts de routage via les communications BGP :

L’environnement est maintenant opérationnel. Il ne reste plus qu’à refaire des tests sur notre machine virtuelle.

Etape VII – Global Secure Access + Accès Conditionnel v2 :

Lancez un ping sur le site outlook.office.com afin de constater la nouvelle IP du service de messagerie Microsoft :

Ouvrez Edge en navigation privée sur la page office.com afin de vous authentifiez avec un compte 365 de test :

Connectez-vous-y en utilisant l’identité Entra ID de votre compte de test :

Cliquez sur Non :

Constatez la bonne connexion au service de Microsoft 365 :

Afin de confirmer nos tests, retirez la connexion entre Azure et GSA pour retrouver le blocage initialement constaté à cause de la police d’accès conditionnelle.

Etape VIII – Retrait de la connexion VPN :

De retour sur le portail Azure, supprimez la connexion VPN Azure précédemment établie :

Confirmez votre choix en cliquant sur Oui :

Attendez que la notification Azure suivante apparaisse :

Lancez un ping sur le site outlook.office.com afin de constater la nouvelle IP du service de messagerie de Microsoft :

Constatez le retour du blocage de l’accès conditionnel mis en place précédemment :

Consultez l’évolution du status de la connexion Global Secure Access via le menu suivant :

Constatez le log de connexion vers les services Microsoft 365 ayant transité par le Global Secure Access via le menu suivant :

Conclusion

Ce nouveau test montre encore une fois la grande simplicité de la connexion entre l’on-premise et les services 365 de Microsoft. Aucun doute que ce service devrait connaître un grand succès une fois sorti de sa préversion et quand sa grille tarifaire sera dévoilée 🤣🙏

Le prochain article devrait parler de l’Accès Privé de Global Secure Access. John a déjà pris de l’avance sur moi 🤣

Azure Bastion est votre ami !

Par moment, les machines virtuelles ont besoin de passer entre les mains de l’IT pour différentes tâches : mises à jour OS, installation d’applications, résolution de problème, etc … A l’inverse des accès utilisateurs, les connexions réalisées par les équipes IT, dont les privilèges sont potentiellement plus élevés, sont souvent occasionnelles et externes.

Ce besoin de connexion irrégulier ne doit pas pourtant donner lieu à abaissement de la sécurité, car des risques pour vos VMs Azure sont toujours présents :

Risques d’attaque plus élevés si la sécurité de l’accès IT est dégradée
Risques de dégâts plus importants compte tenu des privilèges IT élevés

Comme pour n’importe quel accès, des mesures de sécurité en couche sont nécessaires, même pour les équipes IT. Voici des liens vers des articles précédemment écrits de blog :

Qu’est-ce qu’Azure Bastion ?

Voici la définition d’Azure Bastion donnée par Microsoft

Azure Bastion est un service complètement managé qui offre un accès RDP (Remote Desktop Protocol) et SSH (Secure Shell) plus sécurisé et transparent pour les machines virtuelles sans aucune exposition via des adresses IP publiques. Approvisionnez le service directement dans votre réseau virtuel local ou appairé pour prendre en charge toutes les machines virtuelles qu’il contient.
Documentation Azure

Azure Bastion est donc un service de jump pour accéder aux machines virtuelles sur Azure, que celles-ci soient Windows ou Linux.

Le schéma ci-dessous nous montre le tunnel d’accès créé entre Azure Bastion et l’utilisateur initiateur (via une connexion inversée) grâce au protocole TLS :

J’ai également trouvé une vidéo dédiée à Azure Bastion en français, dont voici le lien :

Quel est son point fort ?

Un seul mot doit vous venir en tête :

La sécurité

L’approche d’une connexion sécurisée via TLS permet de s’affranchir de règles sécurités lourdes.

Combien coûte Azure Bastion ?

Disons-le tout de suite, Azure Bastion n’est pas un service gratuit 🤣. La documentation Azure nous donne toutes les informations tarifaires. Voici la copie d’écran du service dans la région Azure Suisse Nord :

Voici ces mêmes données tarifaires pour un mois complet, dans le cas où le service reste actif :

Azure Bastion Basic : 125 CHF environ
Azure Bastion Standard : 192 CHF environ

Gardez à l’esprit que ce service ne nécessite pas systématiquement un déploiement aussi long. Dans beaucoup d’infrastructures IT, il est possible d’envisager son déploiement à la demande.

Cinq petites minutes vous suffiront pour déployer Azure Bastion !

Comment choisir son SKU Bastion ?

Choisir le SKU d’Azure Bastion adapté à vos besoins doit reposer sur les fonctionnalités voulues. Quelques fonctionnalités diffèrent entre les versions Basic et Standard :

A noter qu’il est possible de migrer du SKU Basic au SKU Standard après le déploiement de Bastion, mais pas le chemin inverse n’est plus possible.

Comment mettre en place Azure Bastion ?

Rien de plus simple ! Quelques clics suffisent pour déployer Azure Bastion.

Dans cet article, nous allons déployer Azure Bastion, puis tester quelques fonctionnalités de connexion. Bref, ne perdons pas de temps :

Etape 0 – Rappel des prérequis
Etape I – Préparation de votre environnement Azure
Etape II – Déploiement d’Azure Bastion
Etape III – Azure Bastion via un appairage entre réseaux virtuels Azure
Etape IV – Upgrade d’Azure Bastion vers le SKU Standard
Etape V – Support du client natif d’Azure Bastion
Etape VI – Utilisation de liens partageables Azure Bastion
Etape VII – Utilisations des adresses IP privées

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur Azure Bastion, dont certaines fonctionnalités sont encore en préversion, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Mon environnement Azure de départ ne contient aucune autre ressource, commençons par la préparation d’un nouvel environnement Azure :

Etape I – Préparation de votre environnement Azure :

Commencez par rechercher le service Réseau Virtuel dans la barre de recherche tout en haut :

Cliquez ici pour créer votre premier réseau virtuel Azure :

Créez un premier groupe de ressources, donnez un nom à votre réseau virtuel, puis lancez la validation Azure :

Une fois la validation Azure réussie, cliquez-ici pour commencer la création :

Attendez environ une minute que le processus de création se termine :

Une fois terminé, recherchez le service des Machines Virtuelles Azure :

Cliquez-ici pour créer une première machine virtuelle Azure :

Renseignez les informations de base relatives à votre VM :

Pensez à désactiver les règles publiques de port entrant, puis cliquez sur Suivant :

Aucune option n’est à modifier sur l’onglet des disques, cliquez sur Suivant :

Dans l’onglet réseau, effectuez les modifications suivantes :

Retirez l’adresse IP publique proposée par Azure
Vérifiez que les règles publiques du NSG lié à la carte réseau de la VM sont bien désactivées

Puis, cliquez-ici pour lancer la validation :

Une fois la validation réussie, cliquez-ici pour démarrer le processus de création :

Environ deux minutes plus tard, cliquez-ici pour accéder à votre machine virtuelle Azure :

Cliquez sur Connecter pour démarrer une session de bureau à distance :

Azure commence par effectuer contrôles d’accès. Deux points sur trois sont déjà considérés comme des blocages potentiels :

Port RDP fermé : L’accès publique au port RDP a été volontairement fermé lors de la création de la machine virtuelle.
Absence d’adresse IP publique : celle-ci a volontairement été retirée lors de la création de la machine virtuelle.

Cliquez-ici pour télécharger le fichier RDP préconfiguré pour vous connecter à votre VM :

Exécutez le fichier RDP téléchargé précédemment, puis attendez :

Environ vingt secondes plus tard, un message d’échec de connexion doit apparaître :

Pas d’adresse IP publique et pas de port RDP ouvert en public sont bien les explications logiques du blocage de l’accès distant.

Retrouvez la configuration de ces deux points justes ici :

L’accès RDP à notre machine virtuelle est bien sécurisé. Mais du coup … personne en dehors d’Azure peut s’y connecter ! Il nous faut trouver une solution sans exposer la machine virtuelle.

C’est ici qu’Azure Bastion rentre en scène.

Etape II – Déploiement d’Azure Bastion :

Comme l’indique le schéma ci-dessous, Azure Bastion s’installe sur un sous-réseau dédié dont son nom est normé : AzureBastionSubnet.

Sur votre Portail Azure, recherchez le réseau virtuel créé précédemment :

Dans la section des sous-réseaux, ajoutez-en un :

Le sous-réseau doit avoir la configuration suivante :

Le nom du sous-réseau doit être AzureBastionSubnet.
La taille du sous-réseau doit être /26 ou plus grand
Le sous-réseau ne pourra pas contenir d’autres ressources Azure

Renseignez les champs, puis sauvegardez-le :

Recherchez ensuite le service Bastion dans la barre de recherche du portail Azure :

Cliquez-ici pour créer votre Azure Bastion :

Renseignez les champs nécessaires, en prenant soin de sélectionner un SKU de type Basic, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création de votre Azure Bastion :

Attendez environ 5 minutes pour que le service soit entièrement déployé sur votre environnement :

*Selon la charge présente sur la région Azure sélectionnée, il arrive que le processus de création soit un peu plus long.*

Retournez sur votre machine virtuelle de test, puis lancez une connexion comme ceci :

Renseignez les identifiants de l’administrateur local renseignés lors de la création de votre VM, puis cliquez sur Connecter :

Un nouvel onglet dans votre navigateur interne s’ouvre et ouvre une session Windows sur votre machine virtuelle :

*Si rien ne se passe, vérifiez si ce dernier ne bloque pas les pop-ups Azure.*

Gardez ouverte la session de bureau à distance via Azure Bastion.

Sur la partie gauche de votre session, notez la présence de deux flèches, cliquez dessus, puis constatez le presse-papier de base :

Retournez sur le portail Azure, le menu Session affiche une liste des utilisateurs connectés à Azure Bastion.

Note : Il est en effet possible d’ouvrir plusieurs sessions Bastions vers différentes machines virtuelles.

Votre service Bastion fonctionne bien, l’accès RDP à votre machine virtuelle Windows est sécurisé. Continuons un peu en testant une autre méthode de connexion grâce à Azure Bastion.

Etape III – Azure Bastion via un appairage entre réseaux virtuels Azure :

Bien souvent, les infrastructures Azure contiennent plusieurs réseaux virtuels. Cela fait sens dans le cadre d’architecture multi-régions. Ici, nul besoin de créer et de payer plusieurs Bastion !

Afin de tester le bon fonctionnement d’un seul service Azure Bastion sur un autre réseau virtuel, j’ai créé les ressources Azure suivantes :

Second réseau virtuel Azure
Seconde machine virtuelle Azure
Appairage entre les 2 réseaux virtuels

Voici l’appairage et son statut Connecté sur un des 2 réseaux virtuels :

Sur la seconde machine virtuelle, cliquez sur le service Azure Bastion pour m’y connecter :

Azure recherche si un service Bastion est déployé sur le même réseau virtuel
Si non, Azure recherche un Bastion sur un réseau virtuel appairé à celui-ci

Renseignez les identifiants de l’administrateur local de ma seconde VM, puis cliquez sur Connecter :

Constatez la bonne connexion RDP à ma seconde machine virtuelle :

Azure Bastion fonctionne donc de manière étendue à plusieurs réseaux virtuels. Cette fonction est accessible dès le SKU Basic. Aucun doute que cela est fortement apprécié car il simplifie les méthodes de connexion, mais réduit aussi les coûts !

D’autres méthodes de connexion sont disponibles via Azure Bastion, mais elles nécessitent de changer le SKU de notre service.

Etape IV – Upgrade d’Azure Bastion vers le SKU Standard :

Pour tester les autres méthodes de connexion, il nous est nécessaire de changer le SKU d’Azure Bastion de Basic vers Standard :

*Attention, la migration du SKU en **Standard** n’est pas réversible !*

Attendez quelques minutes qu’Azure applique votre upgrade :

Le changement de SKU d’Azure Bastion entraine d’ailleurs une fermeture des sessions ouvertes via Azure Bastion :

Quelques minutes plus tard, le traitement d’upgrade est terminé :

Notre Azure Bastion est maintenant Standard. Nous allons pouvoir tester d’autres moyens de connexion, comme par exemple via le client natif.

Etape V – Support du client natif d’Azure Bastion :

La fonctionnalité de client natif vous permet de vous connecter à vos machines virtuelles cibles par le biais de Bastion en utilisant Azure CLI
Microsoft Learn

En quelques mots, cette méthode est utile quand on souhaite se passer du portail Azure. Pour utiliser ce moyen de connexion, il est nécessaire d’activer ce service sur Bastion.

Comme les options supplémentaires de Bastion sont maintenant dégrisées, cochez la case Support du client natif, puis cliquez sur Appliquer :

Attendez quelques minutes qu’Azure applique votre modification :

Sur votre poste local, ouvrez une session Terminal :

Commencez par mettre à jour le sous-module réseau d’Azure, utilisé par Azure Bastion :

Update-Module Az.Network -Force

Attendez quelques minutes que le téléchargement, puis l’installation du module se termine :

Copiez l’ID de la souscription contenant votre service Azure Bastion :

Dans votre fenêtre Terminal, lancez le processus d’authentification à Azure :

az login

Microsoft Edge doit alors s’ouvrir pour vous proposer de réutiliser un compte Azure déjà authentifié. Cliquez sur celui-ci si cela est votre cas :

Le message suivant apparaît alors dans votre navigateur :

De retour sur Terminal, saisissez la commande pour vous positionner sur la souscription Azure de votre Bastion :

az account set --subscription "<subscription ID>"

Sur le portail Azure, récupérez l’ID de ressource de votre première machine virtuelle :

Dans votre fenêtre Terminal, saisissez la commande suivante en prenant soin de modifier les 3 variables suivantes :

Nom de votre ressource Azure Bastion
Groupe de ressources votre service Azure Bastion
ID de ressource de votre machine virtuelle

az network bastion rdp --name "<BastionName>" --resource-group "<ResourceGroupName>" --target-resource-id "<VMResourceId>"

Un pop-up RDP s’ouvre alors, cliquez sur Connecter :

Renseignez les identifiants de l’administrateur local renseignés lors de la création de votre VM :

Acceptez le risque en cliquant sur Oui :

Une connexion RDP s’ouvre sur le bureau de votre VM :

Fermez la session de bureau à distance.

Comme Microsoft et d’autres le rappellent, la sécurité de la connexion native peut être renforcée en limitant l’accès uniquement aux ports 22/3389 :

Continuons en testant une autre méthode de connexion à Azure Bastion: les liens partageables.

Etape VI – Utilisation de liens partageables Azure Bastion :

La fonctionnalité lien partageable Bastion permet aux utilisateurs de se connecter à une ressource cible (machine virtuelle ou groupe de machines virtuelles identiques) à l’aide d’Azure Bastion sans accéder au Portail Azure.
Microsoft Learn

Là encore, l’accès au portail Azure n’est peut-être pas possible ou voulue. Le lien partageable peut être communiqué à un tier afin que celui-ci puisse se connecter à la machine virtuelle et y effectuer des opérations IT.

Dans l’écran de configuration d’Azure Bastion, cochez la case suivante, puis cliquez sur Appliquer :

Attendez quelques minutes afin qu’Azure applique votre modification :

Un nouveau menu dédié aux liens partagés fait son apparition dans les paramètres votre Azure Bastion. Cliquez-ici pour créer votre premier lien partagé :

Cochez la ou les machines virtuelles accessibles grâce à ce lien, puis cliquer sur Appliquer :

Le nouveau lien partagé s’ajoute aux liens déjà générés, copiez votre lien dans le presse-papier :

Ouvrez un navigateur privé :

Collez votre lien partageable dans la barre d’adresse, renseignez les identifiants de l’administrateur local renseignés lors de la création de votre VM, puis cliquez-ici pour ouvrir la session :

Attendez quelques secondes, puis constatez l’ouverture du bureau à distance :

Avant de fermer la session ouverte grâce au lien partagé, supprimez le lien généré :

Constatez l’absence de fermeture de session, malgré la suppression du lien.

Fermez la session puis retentez l’ouverture par la même URL précédemment copiée :

L’utilisateur est bien bloqué dans sa seconde tentative de connexion.

Ces liens partagés sont donc intéressant si les utilisateurs sont externes au service IT doivent intervenir très ponctuellement sur une machine virtuelle.

Continuons nos tests sur une autre méthode de connexion : les adresses IP privées.

Etape VII – Utilisations des adresses IP privées :

Une connexion basée sur IP vous permet de vous connecter à vos machines virtuelles Azure et non Azure locales via Azure Bastion sur ExpressRoute ou une connexion VPN site à site en utilisant une adresse IP privée spécifiée.
Microsoft Learn

Grâce à cette fonctionnalité, les équipes IT peuvent se connecter à presque tous les VMS grâce à Azure Bastion ! Peu importe où la ressource se trouve : dans ou en dehors d’Azure.

Pour tester cette fonctionnalité, j’ai modifié quelques peu mon infrastructure Azure déjà en place. J’ai simulé une connexion site à site entre mes 2 réseaux virtuels comme ceci :

J’ai supprimé l’appairage entre mes deux réseaux virtuels
Sur chacun de mes deux réseaux virtuels Azure, j’ai déployé les ressources suivantes :
- Passerelle VPN Basic
- Passerelle de réseau local reprenant l’IP publique du VPN opposé
- Connexion VPN IP Sec

Une des 2 passerelles VPNs configurées :

Une des 2 passerelles de réseau local configurées :

Une des 2 connexions VPN configurées :

Une fois l’infrastructure réseau en place, cochez la case suivante dans la configuration d’Azure Bastion, puis cliquez sur Appliquer :

Attendez quelques minutes qu’Azure applique votre modification :

Un nouveau menu dédié aux adresses IP privées fait son apparition sur votre configuration Azure Bastion. Cliquez-ici pour créer établir une connexion directe :

Attendez quelques secondes, puis constatez l’ouverture du bureau à distance :

Sur une des 2 connexions VPNs, modifiez la clef partagée afin de briser la connexion entre les 2 réseaux virtuels, et de ce fait, couper la session de bureau à distance :

Attendez quelques secondes :

La session d’Azure Bastion fini bien par s’interrompre :

Restaurez la bonne clef partagée, puis sauvegardez :

La connexion du bureau à distance transitant par Bastion est alors automatiquement rétablie :

Conclusion

Bastion rejoint la liste des services managés Azure très utile et très facile à mettre en oeuvre. La non-maîtrise des réseaux rend l’outil encore plus accessible aux débutants, et apporte une première couche de sécurité.

Il ne faut jamais douter des capacités d’attaque de pirates quand des ressources se retrouvent exposées sur internet, Cloud ou pas.

Machine Virtuelle Azure en IPv6

Il arrive par moment que l’on ait besoin de travailler en IPv6. Pourquoi faire ? Par exemple : tester le bon accès d’un autre composant en IPv6 ???? Ceci est effectivement mon cas : ce blog dédié à Azure est hébergé sur Azure via un App Service, fonctionnant en 2023 encore et toujours … en IPv4. Comme certains fournisseurs d’accès internet ont entièrement basculé sur le protocole IPv6, il est nécessaire de trouver une parade pour rendre le site accessible à tous.

Pourquoi faire un article dédié à l’IPv6 sur Azure ?

Comme il arrive que le blog par moment ne soit plus accessible en IPv6, il peut s’écouler pas mal de temps avant que je m’en rende compte. Cet écueil serait sans doute identifié plus rapidement si le site croulait sous l’audience ????.

Pour m’aider, il existe certains sites spécialisés dans l’affichage en IPv4 / IPv6, mais le résultat n’est pas toujours garantie.

Comment rendre un site hébergé sur Azure Web App compatible IPv6 ?

Plusieurs auteurs ont déjà trouvé une parade avant moi, comme Patrickob Blog, ou via un article rédigé sur la Tech Community de Microsoft : l’ajout du service Azure Front Door permet de disposer d’une adresse IPv6 frontale, cela redirige le flux de requêtes vers l’App Service :

Tout cela est possible grâce à l’ajout d’un enregistrement DNS de type CNAME pointant vers le nom d’hôte de votre service Azure Front Door : xxxxxx.azurefd.net.

Il est aussi possible d’utiliser uniquement un enregistrement DNS de type AAAA, pointant vers l’IPv6 de votre service Azure Front Door :

La configuration entre Azure Front Door et Azure App Service est par la suite assez facile :

Dans cet article, nous allons créer une machine virtuelle Azure afin de se connecter à l’App Service, par le biais d’Azure Front Door, et tout cela en IPv6.

Comme le rappelle Microsoft :

L’IPv6 apporte une sécurisation par défaut dans la mesure où la connectivité IPv6 à Internet n’est établie que lorsque vous le demandez explicitement dans votre déploiement.
L’utilisation d’adresses IPv6 publiques ou de préfixes IPv6 publics n’est pas facturée.
La bande passante associées sont facturées au même tarif que le protocole IPv4.

Avant de commencer notre démonstration, quelques rappels sont importants :

Les machines virtuelles uniquement IPv6 ne sont pas pris en charge, chaque carte réseau doit inclure au moins une configuration IPv4.
Il en est de même pour les réseaux virtuels Azure et ses sous-réseaux. Ils ne peuvent disposer d’une IPv6 uniquement, mais bien d’un double adressage IPv4 / IPv6.

Etape 0 – Rappel des prérequis :

Des prérequis sont nécessaires pour réaliser ce test sur un environnement Azure :

Un tenant Microsoft
Une souscription Azure valide

Etape I – Déploiement du Réseau Virtuel Azure :

Commencez par créer un réseau virtuel :

Cochez la case suivante dédiée à l’IPv6, puis ajoutez un plan d0adressage en IPv6 à votre sous-réseau :

Lancez la validation, puis la création :

Attendez la création de votre réseau virtuel pour passer à l’étape suivante :

Un fois le réseau virtuel IPv4 / IPv6 correctement déployé, l’étape suivante consistera à créer une machine virtuelle avec une seule carte réseau sur ce réseau virtuel hybride.

Etape II – Création de la Machine Virtuelle Azure :

Commencez la création de votre machine virtuelle :

Dans l’onglet Réseau, choisissez le sous-réseau comprenant le double adressage IPv4 / IPv6, mais retirez la création de l’IP publique, par défaut prévue en IPv4 :

Lancez la validation, puis la création de votre machine virtuelle :

Attendez la fin de la création de votre machine virtuelle pour passer à l’étape suivante :

L’étape suivante consistera à ajouter une IP publique, mais uniquement sous format IPv6.

Etape III – Déploiement de l’IP publique en IPv6 :

Retournez sur la carte réseau de votre machine virtuelle :

Ajoutez une seconde configuration suivante :

Cliquez sur OK et attendez que la configuration se termine :

Retournez sur la page principale de votre machine virtuelle et constatez l’apparition d’une adresse IPv6 publique seule :

Etape IV – Connexion à la machine virtuelle IPv6 :

Connectez-vous à votre machine virtuelle via le protocole RDP :

Si comme moi vous rencontrez le message d’erreur suivant :

Déployez le service Azure Bastion comme ceci :

Renseignez les champs suivants :

Lancez sa validation, puis sa création :

Attendez la fin de la création d’Azure Bastion :

Connectez-vous à votre machine virtuelle via Azure Bastion nouvellement déployé :

Etape V – Tests IPv6 :

Une fois connecté, ouvrez la configuration IP et constatez la présence d’adresse IP locales en IPv4 et IPv6 :

Ouvrez également Edge et tester les informations réseaux internet depuis un des sites suivants :

Constatez la présence unique de l’IPv6 :

Testez le bon fonctionnement de l’IPv6 du site internet hébergé par l’App Service Azure via le nom de domaine :

Mais aussi via le nom de votre Azure Front Door :

Etape VI – Tests IPv6 d’Azure Front Door :

Afin de vérifier que la connexion entre la machine virtuelle et Azure Front Door s’opère bien uniquement sous le protocole IPv6, il est très facile de désactiver la route de ce dernier comme ceci :

Quelques secondes et un rafraîchissement web plus tard, le status de la route vers l’App Service change de couleur :

Réactualisez la page de votre site de test depuis votre machine virtuelle de test pour constater l’erreur :

Pensez à réactiver la route de votre service Azure Front Door.

Conclusion

Azure a encore du chemin à faire concernant l’implémentation générale de l’IPv6 au sein de l’ensemble de ses services. Nul doute que cela va arriver, mais on peut raisonnablement se demander exactement quand, car l’attente commence à se faire longueeeeeeeeeeeee ????.