RADIUS Server High Availability: Active-Active vs Active-Passive

# RADIUS Server High Availability: Active-Active vs Active-Passive ## Purple Technical Briefing — Podcast Script (~10 minuti) --- **PARTE 1 — INTRODUZIONE E CONTESTO (circa 1 minuto)** Benvenuti al Purple Technical Briefing. Sono il vostro ospite e oggi affronteremo una delle decisioni infrastrutturali più importanti per qualsiasi organizzazione che gestisce una rete WiFi aziendale: l'alta disponibilità del server RADIUS. Se siete un network architect o un direttore IT responsabile dell'infrastruttura di autenticazione presso un gruppo alberghiero, una catena retail, uno stadio o una struttura del settore pubblico, questo briefing vi fornirà i framework e i dettagli tecnici specifici necessari per prendere la decisione giusta, evitando gli errori che causano interruzioni dell'autenticazione nei momenti peggiori. Lasciate che vi presenti lo scenario. RADIUS — Remote Authentication Dial-In User Service — è il guardiano della vostra rete. Ogni volta che un dipendente si connette tramite 802.1X, o un ospite si autentica attraverso il vostro Captive Portal, RADIUS è il motore che verifica le credenziali e autorizza l'accesso. È la spina dorsale delle distribuzioni aziendali IEEE 802.1X e WPA3. E a differenza della maggior parte dei servizi IT che si degradano gradualmente in caso di guasto, RADIUS è binario: o funziona, o nessuno può accedere alla rete. Questa asimmetria è ciò che rende l'alta disponibilità così critica. --- **PARTE 2 — APPROFONDIMENTO TECNICO (circa 5 minuti)** Iniziamo con i concetti fondamentali. RADIUS opera su UDP, in genere sulla porta 1812 per l'autenticazione e 1813 per l'accounting. La natura stateless di UDP è in realtà un vantaggio per la progettazione dell'alta disponibilità: poiché ogni richiesta di autenticazione è indipendente, qualsiasi server in un cluster può gestire qualsiasi richiesta senza dover sapere cosa è successo prima. Questa è la proprietà architetturale che rende le distribuzioni active-active così eleganti. Ora, ci sono due modelli principali di alta disponibilità che dovete comprendere. **Active-Passive** è l'approccio tradizionale. Avete un server RADIUS primario che gestisce tutto il traffico di autenticazione e un server secondario in standby, che riceve i dati replicati ma non elabora le richieste. Quando il primario si guasta, il Network Access Device — il vostro access point, il vostro switch, il vostro gateway VPN — rileva il guasto e reindirizza il traffico al secondario. Quanto tempo richiede questo failover? È qui che i dettagli fanno la differenza. Il NAS invia una richiesta RADIUS e attende. Il timeout predefinito del pacchetto è in genere di due secondi. Successivamente, riprova, di solito tre tentativi per server. Con due server configurati, si prevede un tempo massimo di rilevamento del failover di circa sei-dodici secondi in una distribuzione ben ottimizzata. Nel peggiore dei casi, con tre server e timer predefiniti, questo tempo può estendersi a diciotto secondi. Per un ospite d'albergo che tenta di connettersi al check-in, o per un addetto alle vendite che cerca di elaborare una transazione, si tratta di un'attesa frustrante. **Active-Active** è l'approccio più sofisticato e, per la maggior parte delle distribuzioni aziendali, è quello corretto. Entrambi — o tutti — i server RADIUS elaborano simultaneamente le richieste di autenticazione. Il traffico viene distribuito nel cluster tramite rotazione round-robin o tramite un bilanciatore di carico dedicato. Quando un nodo si guasta, i nodi rimanenti assorbono immediatamente il suo traffico. Non c'è alcun ritardo nel rilevamento del failover perché non c'è un failover nel senso tradizionale: il bilanciatore di carico smette semplicemente di inviare richieste al nodo non integro, in genere entro uno o due secondi in base agli intervalli di controllo dello stato (health-check). I vantaggi in termini di prestazioni si sommano. In una sede di grandi dimensioni — pensate a uno stadio da 60.000 posti o a un centro congressi che ospita una grande fiera — si possono registrare migliaia di richieste di autenticazione simultanee all'apertura dei cancelli o durante le pause delle sessioni. Un singolo server RADIUS, anche con specifiche elevate, può diventare un collo di bottiglia. Un cluster active-active scala orizzontalmente: aggiungendo un altro nodo si aggiunge capacità proporzionale. Ora parliamo del livello del database, perché è qui che molte distribuzioni riscontrano problemi. L'autenticazione RADIUS in sé è ampiamente stateless: il server verifica le credenziali rispetto a una directory e restituisce un Accept o un Reject. Ma l'accounting RADIUS è stateful: tiene traccia dell'inizio della sessione, degli aggiornamenti intermedi e degli eventi di arresto della sessione. Se utilizzate l'accounting per la fatturazione, la registrazione della conformità o la gestione delle sessioni, avete bisogno che tali dati siano coerenti su tutti i nodi. L'approccio standard consiste nel supportare il cluster RADIUS con un database replicato. FreeRADIUS, il server RADIUS open-source più diffuso al mondo, si integra con MySQL e MariaDB. Per le distribuzioni active-active, avete due opzioni principali: MySQL NDB Cluster, che fornisce una replica sincrona multi-master con failover inferiore al secondo, o Galera Cluster, che offre una replica sincrona simile con una gestione operativa leggermente più semplice. Entrambi eliminano il rischio di perdita di dati in caso di guasto del nodo. La replica asincrona — la configurazione standard MySQL primario-replica — è più economica ma introduce un ritardo di replica che può causare la perdita di record di accounting se il primario si guasta prima che le modifiche vengano replicate. Permettetemi di affrontare la questione della distribuzione geografica, poiché è sempre più rilevante per gli operatori multi-sito. Se gestite una catena retail con 200 negozi o un gruppo alberghiero con strutture in più paesi, la domanda non è solo "come rendo ridondante il mio server RADIUS?", ma "dove dovrebbero essere posizionati i miei server RADIUS rispetto ai miei access point?". Il backhauling del traffico di autenticazione da un sito remoto a un data center centrale introduce latenza WAN e un singolo punto di errore sul collegamento WAN. Se quel collegamento si interrompe, il sito remoto non può autenticare nessuno, indipendentemente da quanto sia ridondante il vostro cluster RADIUS centrale. La soluzione consiste nel distribuire istanze RADIUS locali in ciascun sito — il che comporta un notevole sovraccarico operativo — o nell'utilizzare un servizio Cloud RADIUS con nodi edge distribuiti geograficamente. Le piattaforme Cloud RADIUS risolvono il problema dell'alta disponibilità a livello architetturale. Invece di creare e gestire un'infrastruttura ridondante, il provider gestisce RADIUS su più zone di disponibilità e regioni. Il failover tra i nodi avviene automaticamente, in genere in meno di un secondo, perché è gestito dal bilanciamento del carico interno della piattaforma anziché dai timer di retry del NAS. Gli impegni SLA dei provider Cloud RADIUS aziendali sono in genere del 99,99% di uptime, ovvero meno di 53 minuti di inattività all'anno. C'è anche un'importante dimensione di conformità. Lo standard PCI DSS richiede severi controlli di autenticazione per gli ambienti con dati dei titolari di carta. Il GDPR tratta i log di autenticazione come dati personali, richiedendo una gestione appropriata e controlli sulla residenza dei dati. I provider Cloud RADIUS in genere possiedono certificazioni SOC 2 Type II e offrono accordi sul trattamento dei dati GDPR con opzioni di residenza dei dati regionali. Le distribuzioni on-premise offrono il controllo completo sulla posizione dei dati, il che è importante negli ambienti sanitari soggetti a framework di governance dei dati o nelle strutture governative con requisiti di sovranità dei dati. --- **PARTE 3 — RACCOMANDAZIONI DI IMPLEMENTAZIONE E TRAPPOLE COMUNI (circa 2 minuti)** Permettetemi di presentarvi due scenari reali che illustrano questi principi nella pratica. Primo: un gruppo alberghiero europeo con 45 strutture in sei paesi. Il loro team IT composto da tre ingegneri eseguiva FreeRADIUS su macchine virtuali in ogni struttura: 45 istanze separate da aggiornare, monitorare e mantenere. Quando un certificato TLS è scaduto in una struttura, ha causato un'interruzione completa del WiFi per gli ospiti durante un'importante conferenza. La risoluzione ha richiesto l'accesso remoto di un ingegnere per rinnovare manualmente il certificato, un processo durato 40 minuti durante i quali gli ospiti non sono stati in grado di connettersi. Dopo la migrazione a un servizio Cloud RADIUS con gestione centralizzata delle policy, il team ha eliminato completamente la manutenzione per singolo sito. La rotazione dei certificati è diventata automatica. I tre ingegneri hanno recuperato circa il 40% del tempo precedentemente dedicato alle operazioni RADIUS. Cosa ancora più importante, l'architettura active-active della piattaforma su più regioni cloud ha fatto sì che il guasto di un singolo nodo — che in precedenza avrebbe causato un'interruzione del sito — diventasse un evento impercettibile. Secondo scenario: uno stadio sportivo nazionale che ospita 60.000 tifosi per un grande evento. Il team di rete aveva distribuito una configurazione RADIUS active-passive con un server primario e uno in standby a caldo. Durante un test di carico pre-evento, hanno scoperto che il server primario si saturava durante il picco di autenticazione all'apertura dei cancelli, elaborando 8.000 richieste di autenticazione al minuto. Il secondario passivo rimaneva inattivo mentre il primario era in difficoltà. La soluzione è stata quella di riconfigurare i dispositivi NAS per utilizzare il bilanciamento del carico round-robin su entrambi i server, convertendo di fatto la distribuzione in active-active. La capacità di autenticazione è raddoppiata immediatamente. Hanno anche aggiunto un terzo server per fornire margine per il carico di picco e hanno configurato la replica Galera Cluster per il database di accounting. Il risultato è stato una distribuzione in grado di assorbire la perdita di un singolo nodo senza alcun impatto visibile per l'utente. Ora, le trappole comuni. L'errore più frequente è trattare il server RADIUS secondario come un backup da configurare e dimenticare. Le configurazioni divergono. I certificati scadono sul secondario mentre il primario funziona correttamente. Quando il primario alla fine si guasta e il secondario subentra, fallisce anch'esso, per un motivo completamente diverso. La soluzione è semplice: testate regolarmente il failover, almeno trimestralmente, e trattate entrambi i nodi come sistemi di produzione. La seconda trappola consiste nel trascurare il ritardo di replica del database. Se utilizzate la replica asincrona e il nodo del database primario si guasta, potreste perdere i record di accounting per le sessioni attive al momento del guasto. Per la conformità PCI DSS, questa è una lacuna grave. Utilizzate la replica sincrona — Galera o NDB — per qualsiasi distribuzione in cui l'integrità dei dati di accounting sia un requisito di conformità. --- **PARTE 4 — DOMANDE E RISPOSTE RAPIDE (circa 1 minuto)** Permettetemi di rispondere alle domande che sento più spesso dai network architect. "Qual è la configurazione minima di alta disponibilità consigliata?" Due server RADIUS con failover active-passive, sincronizzazione della chiave segreta condivisa e un backend di database replicato. Questo è il livello minimo. Per qualsiasi scenario con più di 500 utenti simultanei, passate all'active-active. "Posso utilizzare un bilanciatore di carico hardware per RADIUS?" Sì, ma RADIUS utilizza UDP e molti bilanciatori di carico sono ottimizzati per TCP. Assicuratevi che il vostro bilanciatore supporti il bilanciamento del carico UDP con controlli dello stato. HAProxy Enterprise dispone di un modulo UDP RADIUS dedicato. F5 BIG-IP lo gestisce nativamente. "Come gestisco l'attendibilità dei certificati EAP in un cluster ad alta disponibilità?" Tutti i nodi devono presentare lo stesso certificato server o, come minimo, certificati della stessa catena di CA. I client convalidano il certificato del server durante gli handshake EAP-TLS e PEAP: se i nodi presentano certificati diversi, si verificheranno errori di autenticazione dopo il failover. "Cloud RADIUS funziona con Active Directory on-premise?" Sì, tramite un connettore leggero o un proxy LDAP che interroga la vostra AD locale senza esporla direttamente a Internet. Questo è il modello di integrazione standard per gli ambienti ibridi. --- **PARTE 5 — RIEPILOGO E PROSSIMI PASSI (circa 1 minuto)** Concludo con le decisioni chiave che dovete prendere. Se gestite meno di 500 utenti simultanei in un singolo sito con un team stabile per la gestione dell'infrastruttura, la configurazione active-passive con una procedura di failover ben testata è una scelta sostenibile. Mantenete la semplicità, testatela regolarmente e utilizzate la replica sincrona del database. Se gestite un patrimonio multi-sito, una sede ad alta densità o se la larghezza di banda del vostro team è limitata, l'active-active è l'architettura corretta e Cloud RADIUS rappresenta il percorso più rapido per ottenerla senza dover creare l'infrastruttura da soli. Qualunque sia il modello scelto, i principi sono gli stessi: distribuire piuttosto che duplicare, automatizzare le decisioni di failover e testare gli scenari di guasto prima che si verifichino nella realtà. Per saperne di più su come la piattaforma di Purple gestisce l'autenticazione RADIUS su scala, inclusa l'integrazione con 802.1X, WPA3 enterprise e i portali WiFi per gli ospiti, visitate purple.ai. Alla prossima.