Deutsche Bahn AG

Reisende erleben WLAN heute als selbstverständliche Infrastruktur — vor allem im Zug und im Bahnhof. Was sie nicht erleben sollen: doppelte Anmeldung beim Übergang. Wer sich gerade noch im Wagen-WLAN eines ICE eingeloggt hat und am Bahnhof aussteigt, soll nicht das Captive Portal des Bahnhof-Netzes erneut durchklicken. Genauso wenig in die andere Richtung beim Einsteigen.

Das klingt nach einem trivialen Authentifizierungs-Problem. Es ist es nicht. Hand aufs Herz: Die Deutsche Bahn betreibt nicht alle WLAN-Knoten selbst — Sub-Contracting-Partner und Roaming-Partner stellen einen wesentlichen Teil der Infrastruktur. Ein eingehender Radius-Authentifizierungs-Request muss intelligent an die richtige Authentifizierungs-Quelle geroutet werden — basierend auf dem im Benutzernamen mitgegebenen Realm und der MAC-Adresse. Und das in einer Latenz, die der Reisende als „nahtlos" wahrnimmt.

Standard-Radius-Server-Lösungen wie FreeRadius lösen das Problem nicht out-of-the-box. Sie kennen das Pattern „Schicke die Anfrage an mehrere Provider gleichzeitig und antworte mit der ersten positiven Antwort" schlicht nicht. Wer es trotzdem versucht, baut sich am Ende einen halben Custom-Stack drumherum — und übersieht dabei die Anforderung an Mehrkunden-Fähigkeit, an Realm-spezifisches Routing und an SNMP-basiertes Monitoring der Anfrage-Pfade.

Eine Out-of-the-Box-Lösung war hier keine Option.

Eine kundenspezifische Radius-Proxy-Architektur in zwei Diensten, paketiert für den Container-Betrieb auf Linux-Debian-Infrastruktur.

Der RadiusAggregator als intelligenter Proxy

Der zentrale Dienst nimmt Radius-Access-Requests entgegen und routet sie nach klaren Regeln weiter. Die Architektur folgt vier Prinzipien:

• Mehrere Anfrage-Quellen ("Clients") parallel bedienen — jeder mit eigener IP und eigenem Shared Secret. Der Aggregator weiß, wer fragt.
• Realm-basiertes Routing — der Realm im Benutzernamen entscheidet, an welche Provider (Sub-Contracting-Partner / Roaming-Partner) die Anfrage weitergegeben wird.
• „Fastest positive response wins" — die Anfrage geht an alle plausiblen Provider gleichzeitig, die erste positive Antwort wird an den ursprünglichen Anfragenden zurückgegeben. Das ist exakt das Pattern, das FreeRadius-artige Standard-Lösungen nicht beherrschen.
• Granulares Monitoring aller Pfade — pro Client, pro Realm, pro Provider werden Metriken erhoben und über SNMP einem zentralen Monitoring-System zur Verfügung gestellt.

Der UserService als Daten-Layer

Parallel zum RadiusAggregator läuft ein UserService, der die Endnutzer-relevanten Daten verwaltet — entkoppelt von der Authentifizierungs-Logik. Das hält die beiden Verantwortungen sauber getrennt.

SNMP als erstklassige Beobachtungs-Schicht

Dass der Aggregator selbst seinen Zustand und seine Metriken über SNMP nach außen liefert, ist kein Beiwerk. Es bedeutet: Bestehende Netzwerk-Monitoring-Systeme (Spectre und vergleichbare bei der DB) sehen den Aggregator wie jede andere Netzwerk-Komponente — keine Sonderlocke, keine separate Toolchain. Konfigurierbar sind dabei sowohl die anfragenden Manager-Systeme als auch die Authentifizierungs-Tiefe (None / MD5 / SHA, plus Privacy-Protokoll DES/3DES/AES bis 256). Das System spricht SNMPv2 und SNMPv3.

Container-First-Deployment

Beide Dienste sind als Docker-Container paketiert und werden via Docker Compose gemeinsam orchestriert. Das hat einen unscheinbaren, aber wichtigen Effekt: die Lösung lässt sich an einem neuen Standort innerhalb von Minuten deployen, statt einem komplexen Linux-Setup mit System-Dienst-Konfiguration.

Hinweis aus der Praxis: Linux ist hier keine Geschmacksfrage — beide Dienste müssen die Quell-IP eingehender UDP-Pakete sehen, um den logischen Sender zuordnen zu können. Docker auf Windows oder macOS schreibt die Quell-IP per NAT um — das funktioniert nur, wenn es genau einen Anfragenden gibt. Für Multi-Client-Szenarien ist Linux Pflicht.

Konfiguration als JSON, nicht als Code

Sowohl der RadiusAggregator als auch der UserService werden über zwei JSON-Dateien gesteuert: daemonconfig.json (Basis-Verhalten, Logging, SNMP, Radius-Ports) und infrastructure.json (Anfrage-Quellen, Provider, Server, Routing-Regeln). Damit kann ein Operator die Topologie verändern, ohne Code anzufassen — neue Provider hinzufügen, Realms umrouten, Secrets rotieren.

• Aus „erneut anmelden" wird „weitersurfen". Der Reisende erlebt einen Übergang, der für ihn nicht existiert.
• Die DB kann Sub-Contracting-Partner integrieren, ohne ihre eigene Architektur jedes Mal anzupassen. Neue Provider werden über infrastructure.json aufgenommen, ohne den Aggregator neu zu deployen.
• „Fastest positive response wins" reduziert die spürbare Latenz für den Endnutzer. Wer schneller antwortet, gewinnt — der Aggregator wartet nicht auf alle Provider.
• SNMP-First bedeutet keine zweite Monitoring-Welt. Bestehende Netzwerk-Operations-Tools sehen den Aggregator als gewohnten Teilnehmer.
• Docker-Compose-Deployment senkt die Hürde für neue Standorte und Test-Umgebungen — von „Linux-Setup-Workshop" zu „eine Compose-Datei und drei Sekunden".

• Wir liefern keine WLAN-Hardware. Access Points bleiben Aufgabe des jeweiligen Standort-Betreibers; wir konzentrieren uns auf die Authentifizierungs-Schicht.
• Wir treffen keine Geschäftsentscheidungen über Provider-Verträge. Welche Sub-Contracting-Partner integriert werden, entscheidet die DB; der Aggregator kennt nur die Konfiguration.
• Wir betreiben das System nicht 24/7. Nach dem Rollout übernimmt der DB-Operations-Bereich. Wir liefern Container, Dokumentation und Updates — der laufende Betrieb gehört in die Verantwortung der internen IT.
• Kein eigener Identitäts-Stack. Die Identität bleibt bei den jeweiligen Authentifizierungs-Providern. Der Aggregator entscheidet nicht über Wahrheit, er routet nur die Frage und gibt die erste verlässliche Antwort weiter.

Der Aufbau funktioniert überall dort, wo eine Multi-Standort-Infrastruktur mit Roaming-Anforderung existiert und Standard-Radius-Lösungen nicht ausreichen — Verkehrsbetriebe (Bus, Tram, Schiff), Hospitality-Ketten mit standortübergreifendem WLAN, Stadien-Verbünde, Hochschul-Netze (Eduroam-artig), Konzern-Filial-Strukturen mit gemeinsamem Identitäts-Pool.

Das Muster: Standort-Captive-Portal → Custom Radius-Aggregator (Realm-Routing + Fastest-Response) → Multiple Authentifizierungs-Provider parallel → nahtloser Übergang zwischen Standorten ohne erneute Anmeldung. Mit Docker-Compose-Deployment und SNMP-Monitoring ohne separate Operations-Welt.

Die DB-Lösung läuft seit 2020 produktiv. Das Pattern selbst ist seitdem mehrfach in Variationen wiederverwendet worden.