Connexion Étoile : procédure d’accès et configuration

Connexion Étoile : principes et topologie pour accès à distance

La Connexion Étoile décrit une architecture où un nœud central relie plusieurs réseaux périphériques. Ce modèle s’applique aussi bien aux infrastructures physiques qu’aux architectures cloud. Dans le contexte d’un accès à distance, le hub central joue le rôle de point d’accès et d’orchestration.

Un exemple concret illustre le fil conducteur de cet article. L’entreprise fictive NovaTech gère trois sites distants et une filiale cloud. NovaTech choisit une topologie en étoile pour centraliser l’authentification, la supervision et la sécurité. Le hub virtuel stocke les règles de routage et les services d’accès.

Fonctionnement et composants clés

Le hub central englobe plusieurs fonctions : routage, authentification, pare-feu et passerelle VPN. Les réseaux périphériques, appelés « spokes », se connectent au hub via des liaisons sécurisées. Les clients distants se connectent ensuite au hub pour accéder aux ressources internes.

Dans l’exemple NovaTech, le hub exécute Virtual WAN et une passerelle point-à-site. Les postes distants utilisent des profils VPN pour joindre le hub. Les machines virtuelles dans les spokes reçoivent des politiques d’accès selon leur rôle.

Avantages concrets pour l’accès à distance

La centralisation facilite la gestion des certificats et des politiques. Les administrateurs appliquent des règles dans un emplacement unique. Un pare-feu central contrôle les flux entrants et sortants.

Autre avantage : la visibilité. Les journaux et métriques du hub offrent une vue consolidée. NovaTech examine ces flux pour détecter les comportements anormaux et activer des règles de quarantaine.

Limites et pièges courants

La dépendance au nœud central est un point à surveiller. Une panne du hub impacte tous les spokes. Pour réduire ce risque, NovaTech met en place des redondances et des sauvegardes de configuration.

La gestion des adresses IP demande une planification stricte. Les plages d’adresses du hub ne doivent pas chevaucher celles des réseaux locaux. Sans vérification, des conflits rendent l’accès instable.

Cas pratique : adoption progressive

NovaTech a procédé par étapes. D’abord, test sur un site pilote. Ensuite, déploiement des certificats et mise en place d’une sonde web pour déterminer la connectivité réseau. La sonde aide à vérifier que les tunnels IPsec sont bien établis.

Ce déroulé illustre une approche prudente. Commencer par un périmètre réduit limite les impacts en cas d’anomalie.

Insight : la topologie étoile centralise le contrôle et simplifie la visibilité, mais exige une planification rigoureuse des services centraux et des plages d’adresses.

Installer et configurer le rôle Accès à distance pour Connexion Étoile

L’installation du rôle Accès à distance sur le serveur qui fera office de hub est la première étape. La procédure peut se faire via l’interface graphique du Gestionnaire de serveur ou via Windows PowerShell.

Sur le plan GUI, il suffit d’ouvrir Ajouter des rôles et des fonctionnalités, sélectionner Accès à distance, puis choisir DirectAccess et VPN (RAS). Suivre les écrans et lancer l’installation. La console confirme l’issue.

Commande PowerShell équivalente

Pour automatiser, utiliser l’applet PowerShell suivante. Elle installe le rôle et les outils de gestion :

Install-WindowsFeature RemoteAccess -IncludeManagementTools

Cette commande évite la navigation dans l’interface. Elle est adaptée aux déploiements répétables et aux scripts d’installation.

Checklist de configuration initiale

• 🔧 Cartes réseau : vérifier la liste des NIC et affecter le bon rôle à chacune.
• 🔐 Certificat IP-HTTPS : nom de sujet correspondant à l’URL publique.
• 🌐 URL publique : définir l’adresse ConnectTo que les clients utiliseront.
• 📡 Paramètres IPv6 : détecter les préfixes nécessaires pour le réseau interne.
• 👥 Groupes de sécurité : préparer les groupes contenant les clients DirectAccess.

La liste ci-dessus aide à vérifier les éléments avant d’exécuter l’assistant de configuration. NovaTech a intégré cette checklist dans son runbook.

Types de déploiement

Lors de la configuration, choisir entre trois options : DirectAccess et VPN, DirectAccess uniquement ou VPN uniquement. Le guide d’exemple suit la méthode DirectAccess uniquement pour certaines étapes.

Le choix impacte les objets de stratégie de groupe et les profils clients. Le déploiement multi-sites et l’authentification à deux facteurs exigent l’authentification par certificat d’ordinateur.

Conseil d’exploitation

Documenter chaque étape. Lors des mises à jour, NovaTech compare les configurations sauvegardées à l’état en production. Cette habitude réduit le temps de résolution en cas d’incident.

Insight : automatiser l’installation via PowerShell et valider les certificats et interfaces réseau avant la mise en service.

Configurer les clients DirectAccess et profils VPN utilisateur pour réseau en étoile

La configuration des clients passe par l’association des machines à un groupe de sécurité ciblé. Les ordinateurs du groupe reçoivent les objets de stratégie de groupe liés à DirectAccess.

Dans la console de gestion de l’accès à distance, la section Clients distants permet de sélectionner les groupes. Un assistant guide la sélection des sondeurs réseau et la création d’une sonde web.

Sondes de connectivité et résolution de noms

La configuration d’au moins une sonde HTTP est essentielle pour vérifier la connectivité interne. La sonde ping n’est pas suffisante, car ping peut être exempté d’IPsec. Sans sonde HTTP, la détection risque d’être incorrecte.

Si la résolution de noms locale est activée, l’utilisateur peut choisir d’utiliser les serveurs DNS configurés sur son poste DirectAccess. Cela influe sur les tests de connectivité et sur l’accès aux ressources internes.

Génération des profils VPN et types d’authentification

Pour les connexions VPN utilisateur, créer une configuration P2S dans le Virtual WAN. Les types de tunnel possibles sont IKEv2, OpenVPN et OpenVPN et IKEv2. Chaque type ouvre différentes méthodes d’authentification.

Les méthodes d’authentification acceptées :

🔐 Méthode	📝 Exigences	⚙️ Remarques
📜 Certificat	Certificats client et racine publics	Convient pour IKEv2 et OpenVPN
🖧 RADIUS	IP serveur RADIUS + secret	Prend en charge redondance serveur
🧾 Microsoft Entra	ID application et locataire	Disponible seulement pour OpenVPN

Le tableau synthétise les choix et leurs contraintes. NovaTech a retenu la combinaison RADIUS + certificats pour assurer la compatibilité avec des clients variés.

Génération et distribution du profil client

Après validation de la configuration, générer le package profil depuis le Virtual WAN. Le profil contient les paramètres du client et, selon l’authentification, les certificats racine.

Pour Windows, sélectionner le package compatible avec l’architecture du poste, installer le client et importer le certificat client. Pour macOS, suivre les étapes dédiées au client natif.

Tests et validation

Effectuer des tests de connexion depuis un poste hors du réseau d’entreprise. Valider l’établissement du tunnel et la résolution DNS. Tester l’accès aux ressources internes via les routes apprises par le hub.

Insight : choisir la méthode d’authentification en fonction du parc client et automatiser la distribution des certificats pour réduire les erreurs humaines.

Créer le hub virtuel, la passerelle P2S et la connexion Spoke pour la Connexion Étoile

La création du WAN virtuel constitue la base du hub. Dans le portail Azure, sélectionner Virtual WAN, puis créer un WAN virtuel de type Standard pour bénéficier des hubs standard et des passerelles avancées.

La page de création demande l’abonnement, le groupe de ressources et le nom du WAN. Une fois le WAN en place, ajouter un hub virtuel en spécifiant la région, l’espace d’adressage et la capacité.

Paramètres P2S et pool d’adresses

Lors de la configuration point-à-site, définir le pool d’adresses client. Exemples pratiques : espace d’adressage du hub 10.1.0.0/16 et pool client 10.5.0.0/16. Les pools ne doivent pas chevaucher d’autres plages.

Indiquer jusqu’à cinq serveurs DNS personnalisés pour les clients. Définir la préférence de routage pour choisir si le trafic transite par le réseau Microsoft ou via l’ISP.

Proxy RADIUS et communication

Si la passerelle utilise RADIUS, noter les adresses IP du proxy RADIUS. Le serveur RADIUS doit accepter les demandes provenant de ces adresses. Configurer les associations et les propagations de la connexion pour que le hub puisse joindre le serveur RADIUS.

NovaTech a déployé un serveur RADIUS sur un réseau virtuel connecté au hub. La configuration a inclus la propagation de la route pour garantir la communication entre la passerelle et le serveur RADIUS.

Connexion du réseau virtuel Spoke

Ajouter une connexion réseau virtuel en choisissant le hub et le réseau virtuel spoke. Vérifier l’absence de passerelle sur le spoke. Sélectionner les options de propagation vers les tables de routage et définir les routes statiques si nécessaire.

Un paramètre utile : ignorer l’adresse IP du next hop pour permettre le déploiement d’appliances virtuelles sans forcer tout le trafic via ces appliances.

Insight : planifier les plages d’adresses et les routes avant de créer les hubs pour réduire les interruptions et les erreurs de routage.

Sécuriser et valider la Connexion Étoile : Pare-feu, règles et tests

Un hub virtuel standard n’inclut pas de sécurité intrinsèque. Pour sécuriser le trafic, convertir le hub en hub sécurisé et activer Pare-feu Azure. Cette étape garantit que le trafic passe par un dispositif d’inspection central.

La création d’une stratégie Pare-feu Azure se réalise via Firewall Manager. Définir des collections de règles réseau avec priorité et règles détaillées. Exemple : autoriser le pool d’adresses client à atteindre la VM1 et bloquer l’accès à la VM2.

Exemple de règle et démarche

Créer une collection de règles avec priorité 100. Ajouter une règle qui cible la source (pool client), le protocole et l’IP de destination de la VM autorisée. Appliquer la stratégie au hub virtuel concerné.

Après application, activer l’option Send via Pare-feu Azure pour forcer le trafic private via le pare-feu. Vérifier la table de routage effective pour le hub afin de confirmer la présence du tronçon lié au trafic privé via le pare-feu.

Validation et tests pratiques

Valider la configuration avec des tests simples :

1. 📶 Se connecter au hub via VPN depuis un poste externe.
2. 📡 Ping sur l’adresse IP 10.18.0.4 (VM1) — une réponse doit être reçue.
3. 🚫 Ping sur l’adresse IP 10.18.0.5 (VM2) — aucune réponse attendue.

Ces tests confirment que les règles de pare-feu appliquent correctement la séparation d’accès souhaitée pour NovaTech.

Surveillance et dépannage

Consulter les logs du pare-feu et les métriques du hub pour analyser les flux bloqués. Vérifier aussi les associations de tables de routage et la propagation des connexions. Si un point d’accès privé doit être inspecté, ajouter un préfixe /32 pour chaque endpoint privé dans la configuration de sécurité.

Enfin, vérifier la configuration des règles RADIUS si l’authentification échoue. S’assurer que les adresses IP du proxy RADIUS figurent dans la liste des sources autorisées sur le serveur RADIUS.

Insight : la sécurité d’un hub en étoile repose sur des règles centralisées et une surveillance active. Valider avec des tests simples et documenter les dépendances RADIUS, certificats et routes.