Haute disponibilité du serveur RADIUS : Actif-Actif vs Actif-Passif

# Haute disponibilité du serveur RADIUS : Actif-Actif vs Actif-Passif ## Briefing technique Purple — Script de Podcast (~10 minutes) --- **PARTIE 1 — INTRODUCTION & CONTEXTE (environ 1 minute)** Bienvenue dans ce briefing technique Purple. Je suis votre hôte, et aujourd'hui nous nous attaquons à l'une des décisions d'infrastructure les plus cruciales pour toute organisation exploitant un réseau Wi-Fi d'entreprise : la haute disponibilité des serveurs RADIUS. Que vous soyez architecte réseau ou directeur informatique responsable de l'infrastructure d'authentification pour un groupe hôtelier, une chaîne de magasins, un stade ou un établissement du secteur public, ce briefing vous fournira les cadres de réflexion et les détails techniques spécifiques indispensables pour faire le bon choix — et éviter les erreurs qui provoquent des pannes d'authentification au pire moment possible. Plantons le décor. RADIUS — Remote Authentication Dial-In User Service — est le gardien de votre réseau. Chaque fois qu'un employé se connecte via 802.1X, ou qu'un invité s'authentifie via votre Captive Portal, RADIUS est le moteur qui vérifie les identifiants et autorise l'accès. C'est la colonne vertébrale des déploiements d'entreprise IEEE 802.1X et WPA3. Et contrairement à la plupart des services informatiques qui se dégradent de manière progressive en cas de défaillance, RADIUS fonctionne en mode binaire : soit il fonctionne, soit personne ne peut se connecter au réseau. C'est cette asymétrie qui rend la haute disponibilité si critique. --- **PARTIE 2 — ANALYSE TECHNIQUE APPROFONDIE (environ 5 minutes)** Commençons par les fondamentaux. RADIUS fonctionne sur UDP — généralement le port 1812 pour l'authentification et 1813 pour l'accounting. La nature sans état (stateless) d'UDP est en réalité un avantage pour la conception de la haute disponibilité : chaque demande d'authentification étant autonome, n'importe quel serveur d'un cluster peut traiter n'importe quelle demande sans avoir besoin de connaître l'historique des requêtes précédentes. C'est cette propriété architecturale qui rend les déploiements actifs-actifs si élégants. Il existe aujourd'hui deux principaux modèles de haute disponibilité que vous devez comprendre. **Actif-Passif** est l'approche traditionnelle. Vous disposez d'un serveur RADIUS principal qui gère l'ensemble du trafic d'authentification, et d'un serveur secondaire en mode veille (standby), qui reçoit les données répliquées mais ne traite pas les demandes. En cas de défaillance du serveur principal, le Network Access Device (NAD) — votre point d'accès, votre commutateur ou votre passerelle VPN — détecte la panne et redirige le trafic vers le serveur secondaire. Combien de temps prend ce basculement ? C'est là que les détails ont leur importance. Le NAS envoie une requête RADIUS et attend. Le délai d'expiration par défaut du paquet (timeout) est généralement de deux secondes. Après cela, il réessaie — habituellement trois tentatives par serveur. Avec deux serveurs configurés, vous faites face à un temps de détection de basculement maximal d'environ six à douze secondes dans un déploiement bien optimisé. Dans le pire des cas, avec trois serveurs et des temporisateurs par défaut, ce délai peut s'étendre jusqu'à dix-huit secondes. Pour un client d'hôtel qui tente de se connecter lors de son enregistrement, ou un vendeur en magasin qui essaie de traiter une transaction, cette attente est particulièrement frustrante. **Active-Active** est l'approche la plus sophistiquée, et pour la plupart des déploiements d'entreprise, c'est la bonne. Les deux (ou la totalité des) serveurs RADIUS traitent les demandes d'authentification simultanément. Le trafic est réparti sur le cluster soit par rotation round-robin, soit par un répartiteur de charge dédié. Lorsqu'un nœud tombe en panne, les nœuds restants absorbent son trafic immédiatement. Il n'y a pas de délai de détection de basculement car il n'y a pas de basculement au sens traditionnel : le répartiteur de charge cesse simplement d'envoyer des requêtes au nœud défectueux, généralement en une à deux secondes en fonction des intervalles de vérification de l'état (health-check). Les avantages en termes de performances se cumulent. Dans un grand espace — comme un stade de 60 000 places ou un centre de conférences accueillant un salon majeur — vous pouvez voir des milliers de demandes d'authentification simultanées à l'ouverture des portes ou lors d'une pause. Un seul serveur RADIUS, même bien configuré, peut devenir un goulot d'étranglement. Un cluster active-active évolue horizontalement : ajoutez un autre nœud et vous augmentez la capacité de manière proportionnelle. Parlons maintenant de la couche base de données, car c'est là que de nombreux déploiements rencontrent des difficultés. L'authentification RADIUS elle-même est largement sans état (stateless) — le serveur vérifie les identifiants par rapport à un annuaire et renvoie un Accept ou un Reject. Mais la comptabilisation (accounting) RADIUS est avec état (stateful) : elle suit le début de session, les mises à jour intermédiaires et les événements de fin de session. Si vous utilisez la comptabilisation pour la facturation, la journalisation de conformité ou la gestion des sessions, vous avez besoin que ces données soient cohérentes sur tous les nœuds. L'approche standard consiste à adosser votre cluster RADIUS à une base de données répliquée. FreeRADIUS, le serveur RADIUS open-source le plus déployé au monde, s'intègre à MySQL et MariaDB. Pour les déploiements active-active, vous disposez de deux options principales : MySQL NDB Cluster, qui fournit une réplication multi-maître synchrone avec un basculement en moins d'une seconde, ou Galera Cluster, qui offre une réplication synchrone similaire avec une gestion opérationnelle légèrement plus simple. Les deux éliminent le risque de perte de données en cas de défaillance d'un nœud. La réplication asynchrone — la réplication primaire-réplique MySQL standard — est moins coûteuse mais introduit un retard de réplication qui peut entraîner la perte d'enregistrements de comptabilisation si le primaire tombe en panne avant que les modifications ne soient répliquées. Permettez-moi d'aborder la question de la répartition géographique, car elle est de plus en plus pertinente pour les opérateurs multi-sites. Si vous gérez une chaîne de vente au détail de 200 magasins ou un groupe hôtelier possédant des établissements dans plusieurs pays, la question n'est pas seulement de savoir "comment rendre mon serveur RADIUS redondant ?" — mais plutôt "où mes serveurs RADIUS doivent-ils être situés par rapport à mes points d'accès ?" Le backhaul du trafic d'authentification d'un site distant vers un centre de données central introduit de la latence WAN et un point de défaillance unique au niveau de la liaison WAN. Si cette liaison tombe en panne, le site distant ne peut plus authentifier personne, quelle que soit la redondance de votre cluster RADIUS central. La solution consiste soit à déployer des instances RADIUS locales sur chaque site — ce qui génère une charge opérationnelle importante — soit à utiliser un service cloud RADIUS doté de nœuds périphériques géographiquement distribués. Les plateformes cloud RADIUS résolvent le problème de haute disponibilité au niveau architectural. Plutôt que de vous laisser construire et gérer une infrastructure redondante, le fournisseur exploite RADIUS sur plusieurs zones de disponibilité et régions. Le basculement entre les nœuds s'effectue automatiquement, généralement en moins d'une seconde, car il est géré par l'équilibrage de charge interne de la plateforme plutôt que par les temporisateurs de retentative du NAS. Les engagements de SLA des fournisseurs de cloud RADIUS d'entreprise sont généralement de 99,99 % de temps de fonctionnement — soit moins de 53 minutes d'arrêt par an. Il existe également une dimension de conformité importante ici. La norme PCI DSS exige des contrôles d'authentification forts pour les environnements de données de titulaires de cartes. Le GDPR traite les journaux d'authentification comme des données personnelles, ce qui nécessite un traitement approprié et des contrôles de résidence des données. Les fournisseurs de cloud RADIUS détiennent généralement des certifications SOC 2 Type II et proposent des accords de traitement des données GDPR avec des options de résidence régionale des données. Les déploiements sur site vous offrent un contrôle total sur l'emplacement des données, ce qui est crucial dans les environnements de santé régis par les cadres de gouvernance des données du NHS, ou dans les installations gouvernementales ayant des exigences de souveraineté des données. --- **PARTIE 3 — RECOMMANDATIONS D'IMPLÉMENTATION ET PIÈGES À ÉVITER (environ 2 minutes)** Laissez-moi vous présenter deux scénarios réels qui illustrent ces principes en pratique. Premier cas : un groupe hôtelier européen possédant 45 établissements dans six pays. Leur équipe informatique de trois ingénieurs gérait FreeRADIUS sur des machines virtuelles dans chaque établissement — soit 45 instances distinctes à corriger, surveiller et maintenir. Lorsqu'un certificat TLS a expiré dans un établissement, cela a provoqué une panne totale du WiFi des clients lors d'une grande conférence. La résolution a nécessité l'intervention à distance d'un ingénieur pour renouveler manuellement le certificat — un processus qui a pris 40 minutes pendant lesquelles les clients n'ont pas pu se connecter. Après avoir migré vers un service cloud RADIUS avec une gestion centralisée des politiques, l'équipe a totalement éliminé la maintenance par site. La rotation des certificats est devenue automatique. Les trois ingénieurs ont récupéré environ 40 % du temps qu'ils consacraient auparavant aux opérations RADIUS. Plus important encore, l'architecture active-active de la plateforme sur plusieurs régions cloud a permis d'éviter qu'une défaillance d'un seul nœud — qui aurait auparavant causé une panne de site — ne devienne un non-événement. Deuxième scénario : un stade de sport national accueillant 60 000 supporters pour un événement majeur. L'équipe réseau avait déployé une configuration RADIUS actif-passif avec un serveur principal et un serveur de secours (hot standby). Lors d'un test de charge pré-événement, ils ont découvert que le serveur principal devenait saturé lors du pic d'authentification à l'ouverture des portes — traitant 8 000 demandes d'authentification par minute. Le serveur secondaire passif restait inactif pendant que le principal était en difficulté. La solution a consisté à reconfigurer les périphériques NAS pour utiliser un équilibrage de charge de type round-robin sur les deux serveurs, convertissant ainsi efficacement le déploiement en actif-actif. Le débit d'authentification a immédiatement doublé. Ils ont également ajouté un troisième serveur pour offrir une marge de manœuvre lors des pics de charge, et ont configuré la réplication Galera Cluster pour la base de données de comptabilité (accounting). Le résultat a été un déploiement capable d'absorber la perte de n'importe quel nœud unique sans aucun impact visible pour l'utilisateur. Voyons maintenant les pièges. L'erreur la plus courante est de traiter le serveur RADIUS secondaire comme une sauvegarde que l'on configure et qu'on oublie. Les configurations dérivent. Les certificats expirent sur le secondaire alors que le principal fonctionne parfaitement. Lorsque le principal finit par tomber en panne et que le secondaire prend le relais, il échoue également — pour une raison complètement différente. La solution est simple : testez votre basculement régulièrement, au moins tous les trimestres, et traitez les deux nœuds comme des systèmes de production. Le deuxième piège consiste à négliger le retard de réplication de la base de données. Si vous utilisez une réplication asynchrone et que votre nœud de base de données principal tombe en panne, vous risquez de perdre les enregistrements de comptabilité pour les sessions qui étaient actives au moment de la panne. Pour la conformité PCI DSS, il s'agit d'une lacune grave. Utilisez la réplication synchrone — Galera ou NDB — pour tout déploiement où l'intégrité des données de comptabilité est une exigence de conformité. --- **PARTIE 4 — QUESTIONS-RÉPONSES RAPIDES (env. 1 minute)** Permettez-moi de répondre aux questions que j'entends le plus souvent de la part des architectes réseau. « Quelle est la configuration HA minimale viable ? » Deux serveurs RADIUS avec basculement actif-passif, synchronisation des secrets partagés et un backend de base de données répliqué. C'est votre base minimale. Pour tout ce qui dépasse 500 utilisateurs simultanés, passez à l'actif-actif. « Puis-je utiliser un équilibreur de charge matériel pour RADIUS ? » Oui, mais RADIUS utilise UDP, et de nombreux équilibreurs de charge sont optimisés pour TCP. Assurez-vous que votre équilibreur de charge prend en charge l'équilibrage de charge UDP avec des contrôles de santé (health checks). HAProxy Enterprise dispose d'un module UDP RADIUS dédié. F5 BIG-IP le gère nativement. « Comment gérer la confiance des certificats EAP dans un cluster HA ? » Tous les nœuds doivent présenter le même certificat serveur, ou au minimum des certificats de la même chaîne d'autorité de certification (CA). Les clients valident le certificat du serveur lors des handshakes EAP-TLS et PEAP — si les nœuds présentent des certificats différents, vous constaterez des échecs d'authentification après le basculement. « Est-ce que le RADIUS cloud fonctionne avec un Active Directory sur site ? » Oui, via un connecteur léger ou un proxy LDAP qui interroge votre AD local sans l'exposer directement à Internet. Il s'agit du modèle d'intégration standard pour les environnements hybrides. --- **PARTIE 5 — RÉSUMÉ ET PROCHAINES ÉTAPES (environ 1 minute)** Laissez-moi conclure avec les décisions clés que vous devez prendre. Si vous gérez moins de 500 utilisateurs simultanés sur un seul site avec une équipe stable pour gérer l'infrastructure, l'architecture actif-passif avec une procédure de basculement bien testée est un choix défendable. Restez simple, testez-la régulièrement et utilisez une réplication de base de données synchrone. Si vous gérez un parc multi-sites, un site à haute densité ou si la bande passante de votre équipe est limitée, l'architecture actif-actif est le bon choix — et le RADIUS cloud est le chemin le plus rapide pour y parvenir sans avoir à construire l'infrastructure vous-même. Quel que soit le modèle choisi, les principes sont les mêmes : distribuer plutôt que dupliquer, automatiser les décisions de basculement et tester vos scénarios de panne avant qu'ils ne vous testent. Pour en savoir plus sur la manière dont la plateforme de Purple gère l'authentification RADIUS à grande échelle — y compris l'intégration avec le 802.1X, le WPA3 d'entreprise et les portails WiFi invités — visitez purple.ai. À la prochaine. --- *Fin du script. Temps de lecture approximatif à 150 mots par minute : 10 minutes.*