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

# RADIUS-Server-Hochverfügbarkeit: Aktiv-Aktiv vs. Aktiv-Passiv ## Purple Technical Briefing — Podcast-Skript (~10 Minuten) --- **TEIL 1 — EINFÜHRUNG & KONTEXT (ca. 1 Minute)** Willkommen beim Purple Technical Briefing. Ich bin Ihr Moderator, und heute befassen wir uns mit einer der folgenschwersten Infrastrukturentscheidungen für jedes Unternehmen, das Enterprise-WiFi betreibt: der Hochverfügbarkeit von RADIUS-Servern. Wenn Sie als Netzwerkarchitekt oder IT-Leiter für die Authentifizierungsinfrastruktur einer Hotelgruppe, einer Einzelhandelskette, eines Stadions oder einer öffentlichen Einrichtung verantwortlich sind, liefert Ihnen dieses Briefing die Frameworks und die spezifischen technischen Details, die Sie benötigen, um die richtige Entscheidung zu treffen — und die Fehler zu vermeiden, die im ungünstigsten Moment zu Authentifizierungsausfällen führen. Lassen Sie mich die Ausgangslage beschreiben. RADIUS — Remote Authentication Dial-In User Service — ist der Gatekeeper für Ihr Netzwerk. Jedes Mal, wenn sich ein Mitarbeiter über 802.1X verbindet oder ein Gast sich über Ihr Captive Portal authentifiziert, ist RADIUS die Engine, die die Anmeldedaten überprüft und den Zugriff autorisiert. Es ist das Rückgrat von IEEE 802.1X- und WPA3-Enterprise-Bereitstellungen. Und im Gegensatz zu den meisten IT-Diensten, bei denen die Leistung bei einem Ausfall schrittweise nachlässt, ist RADIUS binär: Es funktioniert entweder, oder niemand kommt ins Netzwerk. Diese Asymmetrie macht die Hochverfügbarkeit so kritisch. --- **TEIL 2 — TECHNISCHER DEEP-DIVE (ca. 5 Minuten)** Beginnen wir mit den Grundlagen. RADIUS arbeitet über UDP — typischerweise Port 1812 für die Authentifizierung und 1813 für das Accounting. Die verbindunglose Natur von UDP ist eigentlich ein Vorteil für das HA-Design: Da jede Authentifizierungsanfrage in sich geschlossen ist, kann jeder Server in einem Cluster jede Anfrage verarbeiten, ohne wissen zu müssen, was zuvor passiert ist. Dies ist die architektonische Eigenschaft, die Aktiv-Aktiv-Bereitstellungen so elegant macht. Es gibt zwei primäre Hochverfügbarkeitsmodelle, die Sie verstehen müssen. **Aktiv-Passiv** ist der traditionelle Ansatz. Sie haben einen primären RADIUS-Server, der den gesamten Authentifizierungsverkehr abwickelt, und einen sekundären Server im Standby-Modus, der replizierte Daten empfängt, aber keine Anfragen verarbeitet. Wenn der primäre Server ausfällt, erkennt das Network Access Device — Ihr Access Point, Ihr Switch, Ihr VPN-Gateway — den Ausfall und leitet den Datenverkehr an den sekundären Server um. Wie lange dauert dieses Failover? Hier kommt es auf die Details an. Das NAS sendet eine RADIUS-Anfrage und wartet. Das Standard-Paket-Timeout beträgt in der Regel zwei Sekunden. Danach wird ein neuer Versuch gestartet — meist drei Versuche pro Server. Bei zwei konfigurierten Servern müssen Sie in einer gut abgestimmten Bereitstellung mit einer maximalen Failover-Erkennungszeit von etwa sechs bis zwölf Sekunden rechnen. Im schlimmsten Fall mit drei Servern und Standard-Timern kann sich das auf achtzehn Sekunden hinziehen. Für einen Hotelgast, der beim Check-in eine Verbindung herstellen möchte, oder einen Mitarbeiter im Einzelhandel, der eine Transaktion verarbeiten will, ist das ein schmerzhaftes Zeitfenster. **Active-Active** ist der anspruchsvollere Ansatz und für die meisten Enterprise-Bereitstellungen die richtige Wahl. Beide – oder alle – RADIUS-Server verarbeiten Authentifizierungsanfragen gleichzeitig. Der Datenverkehr wird entweder per Round-Robin-Verfahren oder über einen dedizierten Load Balancer über das Cluster verteilt. Fällt ein Node aus, übernehmen die verbleibenden Nodes dessen Datenverkehr sofort. Es gibt keine Verzögerung bei der Failover-Erkennung, da es kein Failover im herkömmlichen Sinne gibt: Der Load Balancer stoppt einfach das Senden von Anfragen an den fehlerhaften Node, in der Regel innerhalb von ein bis zwei Sekunden basierend auf den Health-Check-Intervallen. Die Leistungsvorteile summieren sich. In einer großen Location – wie einem Stadion mit 60.000 Sitzplätzen oder einem Konferenzzentrum, das eine große Messe veranstaltet – kann es zu Tausenden von gleichzeitigen Authentifizierungsanfragen kommen, wenn sich die Türen öffnen oder eine Sitzungspause eintritt. Ein einzelner RADIUS-Server, selbst ein gut dimensionierter, kann zum Nadelöhr werden. Ein Active-Active-Cluster skaliert horizontal: Fügen Sie einen weiteren Node hinzu, und Sie erhalten proportional mehr Kapazität. Lassen Sie uns nun über die Datenbankebene sprechen, da hier viele Bereitstellungen in Schwierigkeiten geraten. Die RADIUS-Authentifizierung selbst ist weitgehend zustandslos – der Server gleicht die Anmeldedaten mit einem Verzeichnis ab und gibt ein „Accept“ oder „Reject“ zurück. Das RADIUS-Accounting ist jedoch zustandsbehaftet: Es verfolgt den Sitzungsstart, Zwischen-Updates und Sitzungsstopp-Ereignisse. Wenn Sie das Accounting für die Abrechnung, die Compliance-Protokollierung oder das Sitzungsmanagement nutzen, müssen diese Daten über alle Nodes hinweg konsistent sein. Der Standardansatz besteht darin, Ihr RADIUS-Cluster mit einer replizierten Datenbank zu hinterlegen. FreeRADIUS, der weltweit am häufigsten eingesetzte Open-Source-RADIUS-Server, lässt sich in MySQL und MariaDB integrieren. Für Active-Active-Bereitstellungen haben Sie zwei Hauptoptionen: MySQL NDB Cluster, das eine synchrone Multi-Master-Replikation mit einem Failover im Subsekundenbereich bietet, oder Galera Cluster, das eine ähnliche synchrone Replikation bei etwas einfacherem Betriebsmanagement bietet. Beide eliminieren das Risiko von Datenverlusten bei einem Node-Ausfall. Die asynchrone Replikation – die Standard-MySQL-Primary-Replica – ist kostengünstiger, führt jedoch zu einer Replikationsverzögerung, die zum Verlust von Accounting-Datensätzen führen kann, wenn der Primary ausfällt, bevor die Änderungen repliziert wurden. Lassen Sie mich die Frage der geografischen Verteilung ansprechen, da dies für Betreiber mit mehreren Standorten immer relevanter wird. Wenn Sie eine Einzelhandelskette mit 200 Filialen oder eine Hotelgruppe mit Häusern in mehreren Ländern betreiben, stellt sich nicht nur die Frage „Wie mache ich meinen RADIUS-Server redundant?“, sondern „Wo sollten sich meine RADIUS-Server im Verhältnis zu meinen Access Points befinden?“ Das Backhauling von Authentifizierungs-Traffic von einem Remote-Standort zu einem zentralen Rechenzentrum führt zu WAN-Latenzzeiten und einem Single Point of Failure an der WAN-Verbindung. Wenn diese Verbindung ausfällt, kann der Remote-Standort niemanden authentifizieren, unabhängig davon, wie redundant Ihr zentraler RADIUS-Cluster ist. Die Lösung besteht entweder darin, lokale RADIUS-Instanzen an jedem Standort bereitzustellen – was einen erheblichen betrieblichen Aufwand bedeutet – oder einen Cloud-RADIUS-Dienst mit geografisch verteilten Edge-Knoten zu nutzen. Cloud-RADIUS-Plattformen lösen das HA-Problem auf architektonischer Ebene. Anstatt dass Sie eine redundante Infrastruktur aufbauen und verwalten, betreibt der Anbieter RADIUS über mehrere Availability Zones und Regionen hinweg. Das Failover zwischen den Knoten erfolgt automatisch, in der Regel in weniger als einer Sekunde, da es durch das interne Load Balancing der Plattform und nicht durch NAS-Retry-Timer gesteuert wird. Die SLA-Zusagen von Enterprise-Cloud-RADIUS-Anbietern liegen in der Regel bei 99,99 % Betriebszeit – das entspricht weniger als 53 Minuten Ausfallzeit pro Jahr. Hier gibt es auch eine wichtige Compliance-Dimension. PCI DSS erfordert strenge Authentifizierungskontrollen für Karteninhaber-Datenumgebungen. Die GDPR behandelt Authentifizierungsprotokolle als personenbezogene Daten, was eine angemessene Handhabung und Kontrollen zur Datenresidenz erfordert. Cloud-RADIUS-Anbieter verfügen in der Regel über SOC 2 Type II-Zertifizierungen und bieten GDPR-Datenverarbeitungsvereinbarungen mit regionalen Optionen zur Datenresidenz an. On-Premise-Bereitstellungen geben Ihnen die volle Kontrolle über den Datenspeicherort, was in Gesundheitsumgebungen unter NHS-Data-Governance-Frameworks oder in Regierungseinrichtungen mit Anforderungen an die Datensouveränität von Bedeutung ist. --- **TEIL 3 — IMPLEMENTIERUNGSEMPFEHLUNGEN & FALLSTRICKE (ca. 2 Minuten)** Lassen Sie mich Sie durch zwei reale Szenarien führen, die diese Prinzipien in der Praxis veranschaulichen. Erstens: Eine europäische Hotelgruppe mit 45 Hotels in sechs Ländern. Ihr IT-Team aus drei Ingenieuren betrieb FreeRADIUS auf virtuellen Maschinen an jedem Standort – 45 separate Instanzen, die gepatcht, überwacht und gewartet werden mussten. Als an einem Standort ein TLS-Zertifikat ablief, führte dies während einer großen Konferenz zu einem vollständigen Ausfall des Gäste-WiFi. Die Behebung erforderte, dass sich ein Ingenieur aus der Ferne einwählte und das Zertifikat manuell erneuerte – ein Prozess, der 40 Minuten dauerte, in denen sich die Gäste nicht verbinden konnten. Nach der Migration zu einem Cloud-RADIUS-Dienst mit zentralisiertem Richtlinienmanagement konnte das Team die Wartung pro Standort vollständig einsparen. Die Zertifikatsrotation erfolgt nun automatisch. Die drei Ingenieure gewannen rund 40 Prozent ihrer Zeit zurück, die sie zuvor für den RADIUS-Betrieb aufgewendet hatten. Noch wichtiger war, dass durch die Active-Active-Architektur der Plattform über mehrere Cloud-Regionen hinweg ein einzelner Knotenausfall – der zuvor zu einem Standortausfall geführt hätte – zu einem unbedeutenden Ereignis wurde. Zweites Szenario: Ein nationales Sportstadion mit 60.000 Fans bei einer Großveranstaltung. Das Netzwerkteam hatte eine aktiv-passive RADIUS-Konfiguration mit einem primären Server und einem Hot-Standby implementiert. Während eines Lasttests vor der Veranstaltung stellten sie fest, dass der primäre Server während des Authentifizierungsansturms bei der Stadionöffnung überlastet war – er verarbeitete 8.000 Authentifizierungsanfragen pro Minute. Der passive sekundäre Server lief im Leerlauf, während der primäre überlastet war. Die Lösung bestand darin, die NAS-Geräte so umzukonfigurieren, dass sie ein Round-Robin-Load-Balancing über beide Server hinweg nutzen, was die Bereitstellung effektiv in eine aktiv-aktive Konfiguration umwandelte. Der Authentifizierungsdurchsatz verdoppelte sich sofort. Zudem wurde ein dritter Server hinzugefügt, um Puffer für die Spitzenlast zu schaffen, und eine Galera-Cluster-Replikation für die Accounting-Datenbank konfiguriert. Das Ergebnis war eine Bereitstellung, die den Ausfall eines einzelnen Knotens ohne für den Benutzer sichtbare Auswirkungen verkraften konnte. Nun zu den Fallstricken. Der häufigste Fehler besteht darin, den sekundären RADIUS-Server als „Set-and-Forget“-Backup zu betrachten. Konfigurationen weichen ab. Zertifikate auf dem sekundären Server laufen ab, während der primäre einwandfrei läuft. Wenn der primäre Server schließlich ausfällt und der sekundäre übernimmt, scheitert auch dieser – aus einem völlig anderen Grund. Die Lösung ist einfach: Testen Sie Ihr Failover regelmäßig, mindestens vierteljährlich, und behandeln Sie beide Knoten als Produktionssysteme. Der zweite Fallstrick ist die Vernachlässigung der Datenbank-Replikationsverzögerung. Wenn Sie eine asynchrone Replikation verwenden und Ihr primärer Datenbankknoten ausfällt, verlieren Sie möglicherweise Accounting-Datensätze für Sitzungen, die im Moment des Ausfalls aktiv waren. Für die PCI-DSS-Compliance ist dies eine schwerwiegende Lücke. Verwenden Sie eine synchrone Replikation – Galera oder NDB – für jede Bereitstellung, bei der die Integrität der Accounting-Daten eine Compliance-Anforderung ist. --- **TEIL 4 — SCHNELLE FRAGEN & ANTWORTEN (ca. 1 Minute)** Lassen Sie mich die Fragen beantworten, die ich von Netzwerkarchitekten am häufigsten höre. „Was ist die minimale viable HA-Konfiguration?“ Zwei RADIUS-Server mit aktiv-passivem Failover, Shared-Secret-Synchronisation und einem replizierten Datenbank-Backend. Das ist das absolute Minimum. Ab 500 gleichzeitigen Benutzern sollten Sie auf eine aktiv-aktive Konfiguration umsteigen. „Kann ich einen Hardware-Load-Balancer für RADIUS verwenden?“ Ja, aber RADIUS verwendet UDP, und viele Load Balancer sind für TCP optimiert. Stellen Sie sicher, dass Ihr Load Balancer UDP-Load-Balancing mit Health Checks unterstützt. HAProxy Enterprise verfügt über ein dediziertes RADIUS-UDP-Modul. F5 BIG-IP unterstützt dies nativ. „Wie handhabe ich das EAP-Zertifikatsvertrauen in einem HA-Cluster?“ Alle Knoten müssen dasselbe Serverzertifikat oder zumindest Zertifikate aus derselben CA-Kette vorweisen. Clients validieren das Serverzertifikat während der EAP-TLS- und PEAP-Handshakes – wenn Knoten unterschiedliche Zertifikate vorweisen, kommt es nach dem Failover zu Authentifizierungsfehlern. „Funktioniert Cloud-RADIUS mit einem lokalen Active Directory?“ Ja, über einen leichtgewichtigen Connector oder LDAP-Proxy, der Ihr lokales AD abfragt, ohne es direkt dem Internet auszusetzen. Dies ist das Standard-Integrationsmuster für Hybrid-Umgebungen. --- **TEIL 5 — ZUSAMMENFASSUNG & NÄCHSTE SCHRITTE (ca. 1 Minute)** Lassen Sie mich mit den wichtigsten Entscheidungen schließen, die Sie treffen müssen. Wenn Sie weniger als 500 gleichzeitige Benutzer an einem einzigen Standort mit einem stabilen Team zur Verwaltung der Infrastruktur haben, ist Active-Passive mit einem gut getesteten Failover-Verfahren eine vertretbare Wahl. Halten Sie es einfach, testen Sie es regelmäßig und nutzen Sie synchrone Datenbankreplikation. Wenn Sie einen standortübergreifenden Bestand oder einen Veranstaltungsort mit hoher Dichte betreiben oder die Bandbreite Ihres Teams begrenzt ist, ist Active-Active die richtige Architektur — und Cloud-RADIUS ist der schnellste Weg dorthin, ohne die Infrastruktur selbst aufbauen zu müssen. Für welches Modell Sie sich auch entscheiden, die Prinzipien sind dieselben: verteilen statt duplizieren, Failover-Entscheidungen automatisieren und Ihre Ausfallszenarien testen, bevor sie Sie testen. Weitere Informationen darüber, wie die Plattform von Purple die RADIUS-Authentifizierung im großen Stil handhabt — einschließlich der Integration mit 802.1X, WPA3 Enterprise und Gäste-WiFi-Portalen —, finden Sie unter purple.ai. Bis zum nächsten Mal. --- *Ende des Skripts. Ungefähre Lesezeit bei 150 Wörtern pro Minute: 10 Minuten.*