Leitfaden Einrichtung Radsecproxy für dfn eduroam

Die Verbindung zwischen DFN eduroam-Server und den Einrichtungen erfolgt via radsec-Protokoll (RFC 6614). Eine Möglichkeit hierfür ist das Programm radsecproxy, das auch bereits in einigen Linux Distributionen zu finden ist. Da es nur wenige Anforderungen hat, ist aber auch das Selbst-Kompilieren meist ohne großen Aufwand möglich.

Es läuft momentan nur in Unix-Umgebungen, ist aber ressourcensparend genug, dass es problemlos in einer VM betrieben werden kann.

Es gibt 2 Möglichkeiten für den SP-Betrieb:

<diagram>

</diagram>

Vorteil:

1. Alle Anfragen von Gästen und die allermeisten 'unsauberen' Pakete werden vom RSP bearbeitet und entweder direkt verworfen oder zum DFN geschickt. Beim ggf. im internen Netz stehenden RADIUS-Server landen nur relevante Anfragen.
2. Der RSP leitet auch 'übergroße' EAP-Pakete sauber und korrekt zum DFN, was einige Probleme mit Roaming-Gästen verhindert.

<diagram>

</diagram>

Vorteil:

1. ggf. bereits bestehende Struktur muss nicht verändert werden; es wird nur der RSP zwischen RADIUS-Server und DFN gesetzt.
2. Eine Übergabe von Attributen (zB Client-spezifische VLANs) vom RADIUS-Server vom WLAN-Controller ist einfacher möglich.

Für Ubuntu 16.04. bietet es sich an, zunächst das Paket von https://files.dfn.de/index.php/s/LPjdpDXlHEoXlaF zu verwenden, da hier ein größeres Problem im Zusammenspiel mit neueren Linux-Kerneln geschlossen wurde.

Bei Debian sind die Distri-eigenen Pakete eine gute Wahl.

Andere Distributionen und Betriebssysteme funktionieren auch wunderbar und können gerne eingesetzt werden. Wir können wegen fehlender Personaldecke im Moment jedoch keine tiefgreifende Hilfe dabei leisten.

Zunächst benötigen Sie ein Zertifikat der DFN PKI im .pem-Format sowie den zugehörigen Schlüssel und Zwischen-Zertifikate. Wie Sie diese erhalten, ist in zertifikate beschrieben.

Eine sehr einfache Konfiguration könnte so aussehen:

radsecproxy.conf

# Bsp-Config für den radsecproxy
# 2017-11-30 klemer ät dfn.de
 
 
# Falls der radsecproxy auf dem selben Host wie ein radius-Server
# läuft, muss hier ein anderer Port gewählt werden
listenUDP		*:1812
 
# listenTLS *:2083 ist default, muss nicht gesetzt werden
 
# debug-Logging; im Produktivbetrieb eher auf Stufe 3
LogLevel		5
 
# ggf. via syslog-Protokoll zu einem zentralen
# Syslog-Server schicken
# zunächst aber in eine lokale Datei.
# Log-Rotation nicht vergessen, damit das Dateisystem nicht
# überquillt!
LogDestination		file:///var/log/radsecproxy.log
 
 
# Funktioniert nur, wenn Client und Server den selben Namen haben
# (hier: tld1 bzw. tld2)
LoopPrevention		on
 
 
# die Zertifikate...
tls default {
    # enthaelt beide(!) Telekom-Zertifikate:
    # subject= /C=DE/O=T-Systems Enterprise Services GmbH/OU=T-Systems Trust Center/CN=T-TeleSec GlobalRoot Class 2
    # und Subject: C=DE, O=Deutsche Telekom AG, OU=T-TeleSec Trust Center, CN=Deutsche Telekom Root CA 2
    CACertificateFile /etc/radsecproxy/certs/telekom-zertifikate.pem
 
 
    # Das Server-Zertifikat muss die 'Client'-Eigenschaft haben. Das erreicht man in der DFN-PKI zB dadurch, dass
    # beim Antrag bei 'Typ' Radius-Server statts des voreingestellten 'Webserver' ausgewählt wird.
 
    # enthält (in dieser Reihenfolge!)
    #  - Serverzertifikat
    #  - Erstes Intermediate (meist s:/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Global Issuing CA)
    #  - Zweites Intermediate (meist s:/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Certification Authority 2)
 
    CertificateFile	 /etc/radsecproxy/certs/server.pem
 
    # enthält den Server-Key
    CertificateKeyFile /etc/radsecproxy/certs/server.key
}
 
 
# ENTWEDER:  Falls das WLAN direkt am radsecproxy angeschlossen sein soll:
client wlan-controler-or-access-points {
  host <ip-address-or-net>
  type udp
  secret dievoegel
}
 
# ODER: Falls das WLAN am Radius-Server hängt und dieser den radsecproxy
#        befragt
client local-radius-server {
  host <ip-address-or-net>
  type udp
  secret fliegenum
}
 
# Fuer lokale Tests
client localtest {
  host 127.0.0.1
  type udp
  secret mitternacht
}
 
 
# Die beiden DFN radsec-Server als Clients, für Anfragen
# eigener User auf Reisen
# (Abschnitt entfällt bei reinen SP)
client tld1 {
  host 193.174.75.134
  type tls
  certificatenamecheck off
  matchCertificateAttribute CN:/^(radius1\.dfn|tld1\.eduroam)\.de$/
}
client tld2 {
  host 193.174.75.138
  type tls
  certificatenamecheck off
  matchCertificateAttribute CN:/^(radius2\.dfn|tld2\.eduroam)\.de$/
}
 
 
 
 
# Der lokale RADIUS-Server für die Authentifizierung des eigenen
# Realm
server radius-server1 {
  host <ip-address>
  type udp
  secret deradler
}
 
# ggf. ein zweiter lokaler RADIUS-Server
server radius-server2 {
      host <ip-address>
      type udp
      secret istgelandet
}
 
# Die beiden DFN-Radsec-Server für die Weiterleitung der Anfragen
# fremder User am eigenen Standort
server tld1 {
     host 193.174.75.134
     type tls
     certificatenamecheck off
     matchCertificateAttribute CN:/^(radius1\.dfn|tld1\.eduroam)\.de$/     
     StatusServer on
}
server tld2 {
     host 193.174.75.138
     type tls
     certificatenamecheck off
     matchCertificateAttribute CN:/^(radius2\.dfn|tld2\.eduroam)\.de$/
     StatusServer on
}
 
 
# hier den eigenen Realm eintragen
# (Abschnitt entfällt bei reinen SP)
realm ihr-realm-hier.de {
        server radius-server1
        server radius-server2
}
 
# alles andere geht zum DFN
realm * {
 server tld1
 server tld2
}

Sollten Sie alles aufgesetzt haben und erhalten nun eine Fehlermeldung, dass sich der radsecproxy nicht dem DFN Server verbinden will, weil dieser ein Zertifikat der eduPKI ausliefert, so ist dies völlig normal. Bis Sie den kommenden Punkt weiter zu erledigen nicht abgearbeitet haben, kann es nicht funktionieren.

Vgl. auch unser Admin-FAQ .

Nach der Einrichtung des radsecproxy benötigt der DFN folgende Informationen:

• IP-Adresse des radsecproxy-Servers
• 'CN' des Zertifikats, das der RSP bekommen wird