Alta disponibilità del server RADIUS: Active-Active vs Active-Passive

# RADIUS Server High Availability: Active-Active vs Active-Passive ## Purple Technical Briefing - Copione del Podcast (~10 minuti) --- **PARTE 1 - INTRODUZIONE E CONTESTO (circa 1 minuto)** Benvenuti al Purple Technical Briefing. Sono il vostro presentatore e oggi affronteremo una delle decisioni infrastrutturali più importanti per qualsiasi organizzazione che utilizzi reti WiFi aziendali: la high availability dei server RADIUS. Se siete network architect o direttori IT responsabili dell'infrastruttura di autenticazione per 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 - ed evitare gli errori che causano interruzioni del servizio di autenticazione nei momenti peggiori. Lasciate che vi presenti la situazione. Il protocollo RADIUS - Remote Authentication Dial-In User Service - è il custode della vostra rete. Ogni volta che un dipendente si connette tramite 802.1X, o un ospite si autentica attraverso il vostro Captive Portal, il RADIUS è il motore che controlla 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 degradano gradualmente in caso di guasto, il RADIUS è binario: o funziona, o nessuno può accedere alla rete. Questa asimmetria è ciò che rende la high availability così critica. --- **PARTE 2 - APPROFONDIMENTO TECNICO (circa 5 minuti)** Partiamo dalle basi. Il RADIUS opera su UDP - tipicamente sulla porta 1812 per l'autenticazione e sulla 1813 per l'accounting. La natura stateless di UDP è in realtà un vantaggio per la progettazione della HA: poiché ogni richiesta di autenticazione è autoconsistente, qualsiasi server all'interno di un cluster può gestire qualsiasi richiesta senza dover sapere cosa sia accaduto prima. Questa è la proprietà architetturale che rende le implementazioni active-active così eleganti. Ora, esistono due modelli principali di high availability che dovete conoscere. Il modello **Active-Passive** è l'approccio tradizionale. Avete un server RADIUS primario che gestisce tutto il traffico di autenticazione e un server secondario in modalità standby, che riceve i dati replicati ma non elabora le richieste. Quando il server 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 verso il secondario. Quanto tempo richiede questo failover? È qui che i dettagli fanno la differenza. Il NAS invia una richiesta RADIUS e rimane in attesa. Il timeout predefinito del pacchetto è in genere di due secondi. Dopodiché, tenta nuovamente - di solito tre tentativi per server. Con due server configurati, si prospetta un tempo massimo di rilevamento del failover di circa sei-dodici secondi in un'implementazione ben ottimizzata. Nel peggiore dei casi, con tre server e timer predefiniti, tale intervallo può estendersi fino a diciotto secondi. Per l'ospite di un hotel che cerca di connettersi al momento del check-in, o per un addetto alle vendite che cerca di elaborare una transazione, si tratta di un'attesa decisamente frustrante. **Active-Active** è l'approccio più sofisticato e, per la maggior parte delle implementazioni aziendali, è quello corretto. Entrambi - o tutti - i server RADIUS elaborano le richieste di autenticazione contemporaneamente. Il traffico viene distribuito all'interno del cluster tramite rotazione round-robin o da un load balancer dedicato. Quando un nodo si guasta, i nodi rimanenti assorbono immediatamente il suo traffico. Non c'è alcun ritardo nel rilevamento del failover perché non esiste un failover nel senso tradizionale: il load balancer smette semplicemente di inviare richieste al nodo non integro, in genere entro uno o due secondi in base agli intervalli di controllo dello stato. I vantaggi in termini di prestazioni si sommano. In una grande struttura - si pensi 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 se con specifiche elevate, può diventare un collo di bottiglia. Un cluster active-active si adatta orizzontalmente: aggiungendo un altro nodo si aggiunge una capacità proporzionale. Ora parliamo del livello del database, perché è qui che molte implementazioni 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 si utilizza l'accounting per la fatturazione, la registrazione della conformità o la gestione delle sessioni, è necessario 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 implementazioni active-active, le opzioni principali sono due: 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 primary-replica - è più economica ma introduce un ritardo di replica che può causare la perdita di record di accounting se il nodo primario si guasta prima che le modifiche vengano replicate. Vorrei affrontare la questione della distribuzione geografica, poiché è sempre più rilevante per gli operatori multi-sito. Se gestite una catena di negozi con 200 punti vendita o un gruppo alberghiero con strutture in diversi paesi, la domanda non è solo "come posso rendere ridondante il mio server RADIUS?" - bensì "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 centre centrale introduce latenza WAN e un singolo punto di vulnerabilità sul collegamento WAN. Se quel collegamento si interrompe, il sito remoto non può autenticare nessuno, indipendentemente da quanto sia ridondante il cluster RADIUS centrale. La soluzione consiste nel distribuire istanze RADIUS locali in ciascun sito - il che comporta un notevole sovraccarico operativo - oppure nell'utilizzare un servizio cloud RADIUS con nodi edge distribuiti geograficamente. Le piattaforme cloud RADIUS risolvono il problema dell'alta affidabilità a livello architetturale. Invece di dover creare e gestire un'infrastruttura ridondante, il provider gestisce il servizio RADIUS in diverse zone di disponibilità e aree geografiche. Il failover tra i nodi avviene in modo automatico, solitamente in meno di un secondo, perché viene gestito dal bilanciamento del carico interno della piattaforma piuttosto che dai timer di tentativi del NAS. Gli impegni SLA dei provider cloud RADIUS aziendali sono solitamente del 99.99% di uptime - il che equivale a meno di 53 minuti di inattività all'anno. C'è anche un'importante dimensione di conformità da considerare. Lo standard PCI-DSS richiede controlli di autenticazione rigorosi per gli ambienti contenenti dati dei titolari di carta. Il GDPR tratta i log di autenticazione come dati personali, richiedendo controlli adeguati sul trattamento e sulla residenza dei dati. I provider cloud RADIUS possiedono in genere certificazioni SOC 2 Type II e offrono accordi sul trattamento dei dati conformi al GDPR con opzioni di residenza dei dati su base regionale. Le distribuzioni on-premise offrono il controllo completo sulla posizione dei dati, un aspetto fondamentale negli ambienti sanitari regolati dai framework di governance dei dati dell'NHS, o nelle strutture governative con requisiti di sovranità dei dati. - **PARTE 3 - RACCOMANDAZIONI DI IMPLEMENTAZIONE E ERRORI COMUNI (circa 2 minuti)** Vorrei presentarvi due scenari reali che illustrano questi principi all'atto pratico. Primo scenario: un gruppo alberghiero europeo con 45 strutture in sei paesi. Il loro team IT, composto da tre ingegneri, gestiva FreeRADIUS su macchine virtuali presso ogni struttura - 45 istanze separate da aggiornare, monitorare e gestire. Quando un certificato TLS è scaduto in una delle strutture, ha causato un'interruzione totale del servizio WiFi per gli ospiti durante un'importante conferenza. Per risolvere il problema, un ingegnere ha dovuto collegarsi da remoto e rinnovare manualmente il certificato - un processo durato 40 minuti durante i quali gli ospiti non sono riusciti a connettersi. Dopo la migrazione a un servizio cloud RADIUS con gestione centralizzata delle policy, il team ha azzerato 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 nel sito - diventasse un evento del tutto irrilevante. Secondo scenario: uno stadio sportivo nazionale che ospita 60.000 tifosi per un grande evento. Il team di rete aveva implementato una configurazione RADIUS attivo-passivo con un server primario e uno di standby a caldo. Durante un test di carico pre-evento, hanno scoperto che il server primario si stava saturando 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 l'implementazione in attivo-attivo. Il throughput di autenticazione è raddoppiato immediatamente. Hanno anche aggiunto un terzo server per fornire margine di manovra per il carico di picco e hanno configurato la replica Galera Cluster per il database di accounting. Il risultato è stato un'implementazione in grado di assorbire la perdita di qualsiasi singolo nodo senza alcun impatto visibile per l'utente. Ora, le insidie. L'errore più comune è considerare il server RADIUS secondario come un backup "imposta e dimentica". Le configurazioni si discostano. I certificati scadono sul secondario mentre il primario funziona correttamente. Quando alla fine il primario si guasta e il secondario subentra, fallisce anche quest'ultimo, 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 insidia è 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 implementazione in cui l'integrità dei dati di accounting sia un requisito di conformità. - **PARTE 4 - DOMANDE E RISPOSTE RAPIDE (circa 1 minuto)** Lasciate che risponda alle domande che sento più spesso dagli architetti di rete. "Qual è la configurazione HA minima praticabile?" Due server RADIUS con failover attivo-passivo, sincronizzazione dei segreti condivisi e un backend di database replicato. Questo è il livello minimo. Per qualsiasi scenario con più di 500 utenti simultanei, passate all'attivo-attivo. "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 di carico 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 la attendibilità dei certificati EAP in un cluster HA?" Tutti i nodi devono presentare lo stesso certificato server, o almeno certificati della stessa catena 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. "Il cloud RADIUS funziona con Active Directory on-premise?" Sì, tramite un connettore leggero o un proxy LDAP che interroga il vostro AD locale senza esporlo direttamente a Internet. Questo è il pattern di integrazione standard per gli ambienti ibridi. - **PARTE 5 - RIEPILOGO E PROSSIMI PASSI (circa 1 minuto)** Lasciatemi concludere con le decisioni chiave che dovete prendere. Se gestite meno di 500 utenti simultanei su un singolo sito con un team stabile per gestire l'infrastruttura, la configurazione attivo-passivo con una procedura di failover ben testata è una scelta difendibile. Mantenete le cose semplici, 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, la configurazione attivo-attivo è l'architettura corretta - e il cloud RADIUS è la via più rapida per arrivarci senza dover costruire l'infrastruttura da soli. Qualunque sia il modello scelto, i principi sono gli stessi: distribuire anziché duplicare, automatizzare le decisioni di failover e testare gli scenari di guasto prima che siano loro a testare voi. 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. - *Fine della sceneggiatura. Tempo di lettura approssimativo a 150 parole al minuto: 10 minuti.*