Zurück zur Server-Übersicht
FsRdpServer unter Linux installieren
Vollständige Anleitung von einem frisch aufgesetzten Linux-Server bis zur
ersten funktionierenden Client-Verbindung – für Ubuntu Server, Debian und
Raspberry Pi OS (64 Bit). Jeder Befehl ist einzeln erklärt.
Entwicklungsversion:
Der Server richtet sich derzeit an ausgewählte Pilotkunden. Bitte
kontaktieren Sie mich vor der Installation, damit wir Servername und
Lizenz gemeinsam abstimmen können.
1. Was am Ende laufen soll
FsRdpServer ist ein Vermittlungsserver. Er nimmt keine
Bildschirminhalte auf und speichert keine Sitzungsinhalte – er verbindet
lediglich die Teilnehmer eines Raums miteinander. Alle Clients verbinden
sich zum Server, nie direkt zueinander. Deshalb muss ausschließlich der
Server erreichbar sein, kein einziger Client.
Nach der Installation lauscht der Dienst auf diesen TCP-Ports:
| Port | Wofür | Pflicht? |
8888 | Hauptverbindung: Steuerung, Bildschirmbild, Dateien, Fernsteuerung | ja |
8889 | Sprachübertragung (eigener Kanal) | ja |
8890 | Browser-Viewer für Zuschauer ohne installierten Client | optional, lizenzpflichtig |
80 | Nur für die Ausstellung und Erneuerung von Let's-Encrypt-Zertifikaten | optional |
Das Linux-Paket ist eigenständig – eine systemweit
installierte .NET-Laufzeitumgebung ist nicht nötig. Verwenden Sie:
linux-x64 für Ubuntu Server, Debian und vergleichbare 64-Bit-Systeme auf Intel/AMD;
linux-arm64 für Raspberry Pi OS (64 Bit) und andere ARM64-Systeme.
2. Den frischen Linux-Server vorbereiten
Alle folgenden Befehle geben Sie in einem Terminal ein – entweder direkt
am Gerät oder per SSH. sudo bedeutet „mit
Verwaltungsrechten ausführen“; beim ersten Mal fragt Linux nach Ihrem
Passwort.
1
System aktualisieren
sudo apt update
sudo apt full-upgrade -y
sudo reboot
Nach dem Neustart melden Sie sich erneut an. Ein Server, der später
aus dem Internet erreichbar ist, sollte von Anfang an aktuell sein.
2
Benötigte Hilfsprogramme nachinstallieren
sudo apt install -y unzip openssl
unzip entpackt das Serverpaket, openssl
brauchen Sie später zum Prüfen und Erzeugen der PFX-Datei.
3
Uhrzeit und Zeitzone kontrollieren
Zertifikate und Lizenzen haben Gültigkeitszeiträume. Geht die
Serveruhr mehrere Minuten falsch, scheitern Verbindungen mit
scheinbar unerklärlichen Fehlern.
timedatectl
sudo timedatectl set-timezone Europe/Berlin
In der Ausgabe von timedatectl sollte
System clock synchronized: yes stehen.
4
Feste lokale IP-Adresse vergeben
Der Router muss die Ports später an eine gleichbleibende Adresse
weiterleiten. Am einfachsten richten Sie im Router eine feste
DHCP-Zuordnung ein („diesem Gerät immer dieselbe IPv4-Adresse
zuweisen“) – dann müssen Sie am Linux-System nichts ändern. Die
aktuellen Adressen sehen Sie mit:
ip -brief address show
5
Bei IPv6: den hinteren Adressteil festnageln
Eine IPv6-Adresse besteht aus zwei Hälften: dem Präfix, das
Ihr Anbieter vergibt, und der Interface-ID dahinter, die das
Gerät selbst wählt. Viele Systeme würfeln die Interface-ID bei jedem
Präfixwechsel neu aus – dann zeigt Ihr DNS-Eintrag ins Leere und die
Router-Freigabe greift nicht mehr. Mit NetworkManager (Standard auf
Raspberry Pi OS und aktuellen Ubuntu-Desktops) legen Sie die
Interface-ID fest:
nmcli connection show
sudo nmcli connection modify "Wired connection 1" \
ipv6.addr-gen-mode eui64 ipv6.token ::159
sudo nmcli connection up "Wired connection 1"
Der Name der Verbindung stammt aus der ersten Zeile;
::159 ist frei wählbar. Danach endet die IPv6-Adresse
des Servers immer auf ::159, egal wie das Präfix
lautet. Auf Servern mit systemd-networkd oder
netplan erreichen Sie dasselbe über den Parameter
Token= bzw. eine statisch konfigurierte Adresse.
3. Der Servername: DNS mit A- und AAAA-Record
3.1 Warum ein Name und keine IP-Adresse?
Clients verbinden sich immer über einen DNS-Namen, zum
Beispiel server.ihrefirma.de, niemals über eine
IP-Adresse. Dafür gibt es zwei zwingende Gründe: Das TLS-Zertifikat ist
auf einen Namen ausgestellt, und Ihre Lizenz ist an genau denselben
Namen gebunden.
Merksatz: Lizenzierter Hostname = Name im Zertifikat =
Name, den der Client einträgt. Diese drei müssen zeichengenau
übereinstimmen.
3.2 A-Record und AAAA-Record – was ist das?
Ein DNS-Eintrag übersetzt einen Namen in eine Adresse. Es gibt zwei
Sorten, weil es zwei Adressarten im Internet gibt:
| Eintrag | Zeigt auf | Beispiel |
A | eine IPv4-Adresse | 203.0.113.45 |
AAAA | eine IPv6-Adresse | 2a02:810d:7087:8800::159 |
Gesprochen wird AAAA als „Quad-A“. Beide dürfen für
denselben Namen gleichzeitig existieren. Wichtig: Der AAAA-Record zeigt
auf die IPv6-Adresse des Servers selbst, nicht auf die
des Routers – bei IPv6 hat jedes Gerät eine eigene, weltweit gültige
Adresse.
3.3 Ihre öffentlichen Adressen herausfinden
Auf dem Server ausführen:
# Öffentliche IPv4-Adresse des Anschlusses
curl -4 https://api.ipify.org; echo
# Öffentliche IPv6-Adresse dieses Servers
curl -6 https://api6.ipify.org; echo
Antwortet der erste Befehl, haben Sie öffentliches IPv4; antwortet der
zweite, haben Sie IPv6.
3.4 Sonderfall DS-Lite: kein öffentliches IPv4
Viele Kabel- und Glasfaseranschlüsse in Deutschland laufen mit
DS-Lite. Dabei bekommt Ihr Anschluss keine eigene
öffentliche IPv4-Adresse mehr, sondern teilt sich eine mit vielen
anderen Kunden. Die Folgen:
- Eine IPv4-Portweiterleitung bleibt wirkungslos. Sie können sie einrichten, sie wird nie erreicht.
- Nur IPv6 funktioniert. Der Name bekommt also ausschließlich einen AAAA-Record.
- Clients in reinen IPv4-Netzen kommen nicht heran – das betrifft manche Firmennetze und einzelne Mobilfunkzugänge.
So erkennen Sie DS-Lite: Der Router zeigt keine öffentliche IPv4-Adresse oder eine aus dem Bereich 100.64.x.x–100.127.x.x; der Aufruf von curl -4 https://api.ipify.org schlägt fehl, der mit -6 gelingt.
Bei vielen Anbietern lässt sich auf Anfrage kostenlos auf einen
Anschluss mit echter IPv4-Adresse umstellen. Wenn Ihre Clients aus
beliebigen Netzen kommen sollen, ist dieser Anruf die einfachste Lösung.
3.5 Wechselnde Adressen: Dynamic DNS
Privatanschlüsse bekommen meist keine feste Adresse: Bei IPv4 ändert
sich die öffentliche Adresse, bei IPv6 das Präfix. In beiden Fällen
zeigt Ihr DNS-Eintrag irgendwann ins Leere. Drei Wege:
- Feste Adresse beim Anbieter buchen – der sauberste Weg, meist gegen kleinen Aufpreis.
- Dynamic-DNS-Dienst (dynv6, deSEC, No-IP …), den Ihr Router bei jeder Änderung aktualisiert. Achten Sie darauf, dass der Dienst auch AAAA-Records aktualisiert – bei DS-Lite ist das die entscheidende Fähigkeit.
- Nur im lokalen Netz betreiben – dann brauchen Sie weder Dynamic DNS noch Portfreigaben (siehe 3.8).
3.6 Die Einträge beim DNS-Anbieter setzen
Legen Sie bei der Stelle, die Ihre Domain verwaltet, einen Eintrag für
den gewünschten Namen an – A mit der öffentlichen
IPv4-Adresse des Anschlusses und/oder AAAA mit der
IPv6-Adresse des Servers. Setzen Sie die TTL für die Testphase auf einen
kleinen Wert (z. B. 600 Sekunden) und erhöhen Sie sie erst,
wenn alles läuft.
3.7 Kontrollieren, ob der Name stimmt
getent hosts server.ihrefirma.de
# Ausführlicher, falls installiert (sonst: sudo apt install -y dnsutils)
dig +short A server.ihrefirma.de
dig +short AAAA server.ihrefirma.de
Stolperstein im eigenen Netz: Viele Router – unter
anderem die FRITZ!Box – filtern mit ihrem DNS-Rebind-Schutz
Antworten heraus, die auf das eigene Netz zeigen. Der Name löst dann
ausgerechnet im Heimnetz auf gar nichts auf, während er
von außen einwandfrei funktioniert. Abhilfe: den Hostnamen unter
Heimnetz → Netzwerk → Netzwerkeinstellungen →
DNS-Rebind-Schutz als Ausnahme eintragen. Danach unbedingt den
DNS-Zwischenspeicher der Testrechner leeren, sonst merken sie die
Änderung nicht.
3.8 Nur im lokalen Netz betreiben
Sitzen alle Teilnehmer im selben Netz, brauchen Sie weder öffentliches
DNS noch Portfreigaben. Der Name muss aber trotzdem existieren, weil
Zertifikat und Lizenz daran hängen: entweder über Ihr internes DNS oder
– nur für kleine Tests – über einen Eintrag in
/etc/hosts auf jedem Client:
192.168.1.50 server.ihrefirma.de
4. Router, Portfreigaben und Firewall
4.1 IPv4: Portweiterleitung
Bei IPv4 teilen sich alle Geräte eine öffentliche Adresse. Der Router
muss deshalb wissen, wohin er ankommende Verbindungen weiterreicht.
Legen Sie für 8888, 8889 und – falls genutzt –
8890 je eine TCP-Weiterleitung auf den Server an. In der
FRITZ!Box: Internet → Freigaben → Portfreigaben →
Gerät für Freigaben hinzufügen.
4.2 IPv6: Freigabe statt Weiterleitung
Bei IPv6 wird nichts umgeleitet – jedes Gerät ist bereits von außen
adressierbar. Der Router öffnet lediglich seine Firewall für dieses
Gerät und diesen Port. In der Oberfläche heißt das trotzdem meist
„Portfreigabe“, mit einer zusätzlichen Auswahl wie „Internetzugriff über
IPv6“.
Legen Sie die Freigabe am Gerät an, nicht an einer
eingetippten Adresse – nur dann übersteht sie einen Präfixwechsel. Bei
DS-Lite ist ausschließlich die IPv6-Freigabe wirksam.
4.3 Port 80 – nur für Let's Encrypt
Beziehen Sie Ihr Zertifikat über Let's Encrypt, muss die
Zertifizierungsstelle prüfen, dass Ihnen der Name gehört. Der einfachste
Weg läuft über Port 80, und zwar dauerhaft freigegeben, weil die
Erneuerung regelmäßig automatisch abläuft. Zwischen den Erneuerungen
lauscht auf Port 80 nichts – die Warnung, die Router an dieser Stelle
anzeigen, zielt auf einen dauerhaft laufenden Webserver.
4.4 Die Firewall auf dem Server selbst
Prüfen Sie zuerst, ob überhaupt eine Firewall aktiv ist:
sudo ufw status
Ist UFW aktiv, geben Sie die Ports frei:
sudo ufw allow 8888/tcp
sudo ufw allow 8889/tcp
sudo ufw allow 8890/tcp # nur bei Browser-Viewer
sudo ufw allow 80/tcp # nur bei Let's Encrypt
Vorsicht bei entfernten Servern: Aktivieren Sie eine
Firewall niemals, ohne vorher sudo ufw allow OpenSSH
freizugeben. Sonst sperren Sie sich selbst aus und kommen nur noch über
die Konsole des Anbieters wieder hinein.
5. Das TLS-Zertifikat (PFX-Datei) im Detail
5.1 Was ist eine PFX-Datei?
cert.pfx ist ein passwortgeschützter Behälter im Format
PKCS#12. Darin stecken das Serverzertifikat für Ihren
Servernamen, der zugehörige private Schlüssel und
meist die Zwischenzertifikate der ausstellenden Stelle.
FsRdpServer verschlüsselt damit alle Verbindungen. Ohne gültiges
Zertifikat startet der Dienst nicht.
Die PFX-Datei ist ein Geheimnis. Wer sie und ihr
Passwort besitzt, kann sich als Ihr Server ausgeben. Nicht per
unverschlüsselter E-Mail verschicken, nicht in ein Repository legen,
nicht für alle Benutzer lesbar machen.
Die Datei muss genau ein Zertifikat mit privatem
Schlüssel enthalten und den lizenzierten Servernamen als Subject
Alternative Name tragen – entweder direkt
(server.ihrefirma.de) oder über ein Wildcard-Zertifikat
(*.ihrefirma.de).
5.2 Weg A: Gekauftes Zertifikat in eine PFX-Datei bündeln
Anbieter liefern meist zwei bis drei Dateien: das Zertifikat, den
privaten Schlüssel und die Zwischenzertifikate. So machen Sie daraus
eine PFX-Datei:
openssl pkcs12 -export -out cert.pfx \
-inkey privkey.pem -in cert.pem -certfile chain.pem
OpenSSL fragt das Passwort interaktiv ab – schreiben Sie es nicht als
-password pass:... in die Befehlszeile, sonst steht es in
Ihrem Shell-Verlauf.
5.3 Weg B: Kostenlos über Let's Encrypt
Funktioniert, sobald Ihr Servername öffentlich im DNS steht und Port 80
von außen erreichbar ist. Es gibt zwei gängige Werkzeuge:
-
lego – ein einzelnes Programm, das die
PFX-Datei direkt erzeugen kann. Damit entfällt der
Umwandlungsschritt, deshalb wird es hier gezeigt.
-
certbot – der bekannteste Client. Er
erzeugt PEM-Dateien, die Sie anschließend wie in 5.2 bündeln müssen.
Beachten Sie: In Debian 13 („trixie“) und darauf aufbauenden
Raspberry-Pi-OS-Versionen ist certbot nicht mehr als
Paket enthalten.
1
lego installieren
sudo apt install -y lego
Findet apt das Paket nicht, ist es in Ihrer Version
eventuell nur über die Backports verfügbar
(sudo apt install -y -t stable-backports lego) oder Sie
laden das fertige Programm von go-acme.github.io/lego
herunter.
2
Erst mit der Testumgebung ausprobieren
Let's Encrypt begrenzt die Zahl der Fehlversuche. Prüfen Sie
deshalb zuerst gegen den Testserver, ob Ihre Portfreigabe wirklich
greift – das kostet kein Kontingent:
sudo lego --accept-tos --email ihre.adresse@example.com \
--domains server.ihrefirma.de \
--http --http.port :80 --path /etc/lego-staging \
--server https://acme-staging-v02.api.letsencrypt.org/directory run
3
Das echte Zertifikat als PFX abholen
Hat der Testlauf funktioniert, holen Sie das richtige Zertifikat.
Denken Sie sich ein Passwort für die PFX-Datei aus:
sudo lego --accept-tos --email ihre.adresse@example.com \
--domains server.ihrefirma.de \
--http --http.port :80 --path /etc/lego \
--pfx --pfx.format SHA256 --pfx.pass 'IhrPasswort' run
Die fertige Datei liegt danach unter
/etc/lego/certificates/server.ihrefirma.de.pfx.
5.4 Weg C: Zertifikat der eigenen Firmen-CA
Nur für rein interne Installationen sinnvoll: Jeder Client muss Ihrer
Firmen-CA ausdrücklich vertrauen, sonst schlägt jede Verbindung fehl.
Für den Browser-Viewer ist dieser Weg unbrauchbar, weil jeder Browser
eine Warnseite zeigen würde.
5.5 Die PFX-Datei vor der Installation prüfen
# Inhalt anzeigen (fragt nach dem Passwort)
openssl pkcs12 -info -in cert.pfx -nokeys
# Namen und Laufzeit des Zertifikats prüfen
openssl pkcs12 -in cert.pfx -clcerts -nokeys -passin pass: 2>/dev/null \
| openssl x509 -noout -subject -dates -ext subjectAltName
Achten Sie darauf, dass der lizenzierte Name in
subjectAltName auftaucht und das Datum in
notAfter in der Zukunft liegt.
6. Das Serverpaket installieren
1
Paket auf den Server kopieren und entpacken
unzip FsRdpServer-linux-x64.zip -d FsRdpServer
cd FsRdpServer
ls
Auf einem Raspberry Pi verwenden Sie stattdessen
FsRdpServer-linux-arm64.zip. Im Ordner müssen unter
anderem FsRdpServer, install.sh,
fsrdp-server.service und
README-LINUX.md liegen.
2
Installer ausführen
chmod +x FsRdpServer install.sh
sudo ./install.sh
Der Dienst bleibt bei der Erstinstallation absichtlich
gestoppt, bis Zertifikat und Lizenz eingerichtet
sind. Das ist kein Fehler.
Was dabei entsteht:
/opt/fsrdp-server/FsRdpServer | das Programm selbst |
/opt/fsrdp-server/data/ | Konfiguration, Zertifikat, Lizenz, Installations-ID, Protokolle |
/etc/fsrdp-server/fsrdp-server.env | Geheimnisse, nur für root lesbar |
/etc/systemd/system/fsrdp-server.service | die Dienstbeschreibung für systemd |
Benutzer fsrdp-server | eigenes, eingeschränktes Dienstkonto ohne Anmeldemöglichkeit |
Andere Ports als 8888/8889 stellen Sie in
/opt/fsrdp-server/data/appsettings.json ein. Setzen Sie
Eigentümer und Rechte anschließend zurück:
sudo chown fsrdp-server:fsrdp-server … und
sudo chmod 0640 ….
7. Installations-ID erzeugen und Lizenz anfordern
FsRdpServer startet ausschließlich mit einer gültigen, signierten
Lizenzdatei. Sie ist an Ihren Servernamen und an eine
dauerhafte Installations-ID gebunden. Anders als unter
Windows erzeugen Sie diese ID auf einem Linux-Server vor der
Lizenzanfrage selbst – genau einmal:
sudo -u fsrdp-server env \
FSRDP_DATA_DIR=/opt/fsrdp-server/data \
/opt/fsrdp-server/FsRdpServer --installation-id
Der Befehl gibt eine lange Zeichenkette aus und speichert sie in
/opt/fsrdp-server/data/server-instance-id.txt.
Teilen Sie mir für die Ausstellung mit:
- die ausgegebene Installations-ID;
- den exakten DNS-Namen, den die Clients verwenden werden;
- wie viele Räume gleichzeitig und wie viele Teilnehmer pro Raum;
- die gewünschte Laufzeit;
- ob Sie Browser-Viewer, Sitzungsaufnahme oder Live-Untertitel nutzen möchten – diese Funktionen müssen in der Lizenz freigeschaltet sein.
server-instance-id.txt darf niemals verloren
gehen – auch nicht bei einem Update oder einer Neuinstallation.
Ist die Datei weg, passt Ihre Lizenz nicht mehr und muss neu ausgestellt
werden.
8. Zertifikat, Lizenz und Passwort einspielen
1
Beide Dateien mit den richtigen Rechten ablegen
Wechseln Sie in den Ordner, in dem license.fsrdp und
cert.pfx liegen:
sudo install -o fsrdp-server -g fsrdp-server -m 0640 \
license.fsrdp /opt/fsrdp-server/data/license.fsrdp
sudo install -o fsrdp-server -g fsrdp-server -m 0640 \
cert.pfx /opt/fsrdp-server/data/cert.pfx
install kopiert die Datei und setzt Eigentümer und
Rechte in einem Zug – das Dienstkonto darf lesen, normale Benutzer
nicht.
2
Das PFX-Passwort hinterlegen
Das Passwort gehört nicht in die Konfigurationsdatei, sondern in die
nur für root lesbare Umgebungsdatei:
sudoedit /etc/fsrdp-server/fsrdp-server.env
Tragen Sie dort ein (bestehende Zeilen ersetzen):
FSRDP_CERT_PASSWORD=hier-das-echte-passwort
Danach die Rechte sicherstellen:
sudo chown root:root /etc/fsrdp-server/fsrdp-server.env
sudo chmod 0600 /etc/fsrdp-server/fsrdp-server.env
Enthält das Passwort Leerzeichen oder Sonderzeichen, setzen Sie es
nach der systemd-Syntax in Anführungszeichen. Am einfachsten
vermeiden Sie beides und verwenden ein langes Passwort aus
Buchstaben und Ziffern.
3
Die Dateirechte kontrollieren
sudo stat -c '%U:%G %a %n' \
/opt/fsrdp-server/FsRdpServer \
/opt/fsrdp-server/data \
/opt/fsrdp-server/data/cert.pfx \
/opt/fsrdp-server/data/license.fsrdp \
/etc/fsrdp-server/fsrdp-server.env \
/etc/systemd/system/fsrdp-server.service
Erwartet wird:
| Pfad | Eigentümer | Rechte |
/opt/fsrdp-server/FsRdpServer | root:root | 0755 |
/opt/fsrdp-server/data | fsrdp-server:fsrdp-server | 0750 |
/opt/fsrdp-server/data/cert.pfx | fsrdp-server:fsrdp-server | 0640 |
/opt/fsrdp-server/data/license.fsrdp | fsrdp-server:fsrdp-server | 0640 |
/etc/fsrdp-server/fsrdp-server.env | root:root | 0600 |
/etc/systemd/system/fsrdp-server.service | root:root | 0644 |
9. Validieren und den Dienst starten
9.1 Selbstprüfung vor dem ersten Start
Der folgende Befehl sieht sperrig aus, hat aber einen guten Grund: Er
lässt systemd die nur für root lesbare Passwortdatei laden
und führt die Prüfung trotzdem unter dem Dienstkonto aus. So muss das
PFX-Passwort nirgends in die Befehlszeile.
sudo systemd-run \
--quiet --wait --pipe --collect \
--property=User=fsrdp-server \
--property=Group=fsrdp-server \
--property=EnvironmentFile=/etc/fsrdp-server/fsrdp-server.env \
--property=Environment=FSRDP_DATA_DIR=/opt/fsrdp-server/data \
/opt/fsrdp-server/FsRdpServer --validate-installation
Eine erfolgreiche Ausgabe bestätigt, dass Lizenz, Installations-ID und
Zertifikat zusammenpassen. Eine DNS-Warnung ist nur
dann akzeptabel, wenn Sie den Namen bewusst über internes DNS oder
hosts-Dateien bereitstellen – die Clients müssen ihn trotzdem auflösen
können. Jeden echten Fehler beheben Sie vor dem Start.
9.2 Dienst starten
sudo systemctl start fsrdp-server.service
systemctl is-active fsrdp-server.service
systemctl is-enabled fsrdp-server.service
is-active muss active melden,
is-enabled muss enabled melden – Letzteres
sorgt dafür, dass der Dienst nach einem Stromausfall von selbst wieder
hochkommt.
9.3 Kontrollieren
# Lauschen die Ports?
sudo ss -lntp | grep -E ':(8888|8889|8890)\b'
# Was sagt das Protokoll?
sudo journalctl -u fsrdp-server.service -n 50 --no-pager
# Lizenzstatus im Klartext
sudo -u fsrdp-server env FSRDP_DATA_DIR=/opt/fsrdp-server/data \
/opt/fsrdp-server/FsRdpServer --license-status
Im Startprotokoll steht unter anderem, welches Zertifikat geladen wurde
und bis wann es gilt – ein guter erster Blick, wenn später etwas nicht
funktioniert.
10. Browser-Viewer auf Port 8890 mit eigenem Zertifikat
Der Browser-Viewer erlaubt Zuschauern, ohne installierten Client
teilzunehmen – sie öffnen einfach
https://server.ihrefirma.de:8890/. Die Funktion ist
standardmäßig aus und braucht zwei Schalter: die Freigabe
in der Lizenz und die Aktivierung
in der Konfiguration.
10.1 Warum ein zweites Zertifikat sinnvoll ist
Für die nativen Clients genügt jedes Zertifikat, dem die Clients
vertrauen – auch eines aus Ihrer eigenen Firmen-CA. Ein
Browser ist strenger: Er zeigt jedem Besucher eine
Warnseite, wenn das Zertifikat nicht von einer öffentlich anerkannten
Stelle stammt. Deshalb kann der Browser-Viewer ein eigenes Zertifikat
bekommen, ohne dass Sie das der nativen Kanäle anfassen müssen. Lassen
Sie die Einstellung leer, wird automatisch cert.pfx
mitverwendet.
10.2 Einrichten
1
Öffentlich vertrauenswürdiges Zertifikat holen
Mit lego wie in Abschnitt 5.3 beschrieben. Merken Sie
sich das vergebene PFX-Passwort.
2
Zertifikat ins Datenverzeichnis kopieren
sudo install -o fsrdp-server -g fsrdp-server -m 0640 \
/etc/lego/certificates/server.ihrefirma.de.pfx \
/opt/fsrdp-server/data/webgateway-cert.pfx
3
Passwort in der Umgebungsdatei ergänzen
sudoedit /etc/fsrdp-server/fsrdp-server.env
Zusätzlich zur bestehenden Zeile eintragen:
FSRDP_WEB_CERT_PASSWORD=das-passwort-der-webgateway-pfx
4
Konfiguration anpassen
sudoedit /opt/fsrdp-server/data/appsettings.json
Zwei Werte setzen bzw. ergänzen:
"WebGatewayEnabled": true,
"WebGatewayCertificatePath": "webgateway-cert.pfx",
Ein relativer Pfad bezieht sich auf das Datenverzeichnis. Danach die
Rechte wiederherstellen:
sudo chown fsrdp-server:fsrdp-server /opt/fsrdp-server/data/appsettings.json
und sudo chmod 0640 ….
5
Neu starten und prüfen
sudo systemctl restart fsrdp-server
sudo journalctl -u fsrdp-server -n 30 --no-pager | grep -i certificate
Im Protokoll müssen jetzt zwei Zertifikatszeilen
stehen – eine für die nativen Kanäle, eine für den Browser-Viewer.
Zum Abschluss prüfen Sie die Kette von außen:
echo | openssl s_client -connect server.ihrefirma.de:8890 \
-servername server.ihrefirma.de 2>&1 | grep -E 'Verify return code'
Verify return code: 0 (ok) heißt: Der Browser wird keine
Warnung zeigen.
10.3 Automatische Erneuerung einrichten
Der Server liest seine Zertifikate nur beim Start. Eine
Erneuerung wirkt erst nach einem Neustart des Dienstes – und der trennt
alle laufenden Sitzungen. Deshalb sollte das Erneuerungsskript den
Dienst nur dann neu starten, wenn sich das Zertifikat tatsächlich
geändert hat.
Legen Sie /usr/local/sbin/fsrdp-renew-webcert.sh an:
#!/bin/bash
set -euo pipefail
domain=server.ihrefirma.de
email=ihre.adresse@example.com
env_file=/etc/fsrdp-server/fsrdp-server.env
lego_pfx="/etc/lego/certificates/${domain}.pfx"
pfx_pass=$(sed -n 's/^FSRDP_WEB_CERT_PASSWORD=//p' "$env_file")
[ -n "$pfx_pass" ] || { echo "Passwort fehlt in $env_file" >&2; exit 1; }
before=$(sha256sum "$lego_pfx" 2>/dev/null | cut -d' ' -f1 || true)
lego --accept-tos --email "$email" --domains "$domain" \
--http --http.port :80 --path /etc/lego \
--pfx --pfx.format SHA256 --pfx.pass "$pfx_pass" \
renew --days 30
after=$(sha256sum "$lego_pfx" | cut -d' ' -f1)
[ "$before" != "$after" ] || { echo "Zertifikat unveraendert."; exit 0; }
install -o fsrdp-server -g fsrdp-server -m 0640 \
"$lego_pfx" /opt/fsrdp-server/data/webgateway-cert.pfx
systemctl restart fsrdp-server
echo "Neues Zertifikat eingespielt, Dienst neu gestartet."
Ausführbar machen und einen Zeitplan hinterlegen:
sudo chmod 0750 /usr/local/sbin/fsrdp-renew-webcert.sh
sudo systemctl edit --force --full fsrdp-webcert-renew.service
Inhalt der Dienstdatei:
[Unit]
Description=Zertifikat des FsRdp-Browser-Viewers erneuern
Wants=network-online.target
After=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/local/sbin/fsrdp-renew-webcert.sh
Und der zugehörige Zeitgeber:
sudo systemctl edit --force --full fsrdp-webcert-renew.timer
[Unit]
Description=Zweimal taeglich pruefen, ob das Zertifikat erneuert werden muss
[Timer]
OnCalendar=*-*-* 03,15:00:00
RandomizedDelaySec=1h
Persistent=true
[Install]
WantedBy=timers.target
Einschalten und einmal von Hand testen:
sudo systemctl enable --now fsrdp-webcert-renew.timer
sudo systemctl start fsrdp-webcert-renew.service
sudo journalctl -u fsrdp-webcert-renew.service -n 20 --no-pager
11. Der erste Verbindungstest
Testen Sie nicht vom Server selbst – damit übersehen
Sie jedes Router- und Firewall-Problem. Installieren Sie den Client auf
einem anderen Gerät (siehe
Client-Anleitung),
tragen Sie dort den lizenzierten Servernamen ein und verbinden Sie sich
mit zwei Geräten in denselben Raum. Erst mit zwei Teilnehmern zeigt
sich, ob Bild und Ton wirklich durchlaufen.
Testen Sie nicht mit telnet oder nc in
der Schleife. Wiederholte Verbindungsversuche ohne gültiges
Protokoll wertet der Server als Angriffsversuch und sperrt die
IP-Adresse des Testrechners vorübergehend.
12. Laufender Betrieb
Sicherung
Sichern Sie /opt/fsrdp-server/data und
/etc/fsrdp-server/fsrdp-server.env – aber an einen Ort mit
ebenso engen Zugriffsrechten, denn dort liegen PFX-Datei und Passwort.
Am wichtigsten ist server-instance-id.txt: Ohne sie ist
Ihre Lizenz für diese Installation wertlos.
Server aktualisieren
unzip FsRdpServer-linux-x64.zip -d FsRdpServer-neu
cd FsRdpServer-neu
chmod +x FsRdpServer install.sh
sudo ./install.sh
War der Dienst aktiv, stoppt der Installer ihn, tauscht Programm und
Dienstbeschreibung aus und startet ihn wieder. Zertifikat, Passwort,
Lizenz, Installations-ID, Raumreservierungen, Konfiguration und
Protokolle bleiben unverändert.
Eine Falle beim Ausrollen: Fehlt
/etc/fsrdp-server/fsrdp-server.env, legt der Installer sie
aus der Vorlage neu an – mit einem Platzhalter als Passwort. Und weil
die Umgebungsvariable Vorrang vor der Konfigurationsdatei hat, startet
der Dienst danach nicht mehr. Stellen Sie die Datei mit dem echten
Passwort her, bevor Sie ein Update einspielen; danach lässt der
Installer eine vorhandene Datei unangetastet.
Lizenz austauschen
sudo systemctl stop fsrdp-server.service
sudo install -o fsrdp-server -g fsrdp-server -m 0640 \
license.fsrdp /opt/fsrdp-server/data/license.fsrdp
# Danach die Selbstpruefung aus Abschnitt 9.1 wiederholen
sudo systemctl start fsrdp-server.service
Starten Sie den Dienst nicht, wenn die Prüfung fehlschlägt. Wurde die
Lizenz mit einer geänderten Supporter-Anzahl neu erzeugt, können sich
alle Supporter-Schlüssel geändert haben – verteilen Sie die neuen
Schlüssel dann zeitnah.
Zertifikat austauschen
sudo install -o fsrdp-server -g fsrdp-server -m 0640 \
cert.pfx /opt/fsrdp-server/data/cert.pfx
# Falls sich das Passwort geaendert hat: fsrdp-server.env anpassen
sudo systemctl restart fsrdp-server.service
13. Häufige Probleme
Der Dienst startet nicht
Sehen Sie zuerst in das Protokoll:
sudo journalctl -u fsrdp-server -n 50 --no-pager. Die
häufigsten Ursachen sind ein falsches PFX-Passwort, eine
Konfigurationsdatei mit Syntaxfehler (ein fehlendes Komma genügt) und
fehlende Leserechte des Dienstkontos.
Keine Berechtigung
Setzen Sie Eigentümer und Rechte aus Abschnitt 8 erneut. PFX-Datei und
Lizenz dürfen nicht für alle Benutzer lesbar sein, das Dienstkonto muss
sie aber lesen können.
Der Name im Zertifikat passt nicht
Client-Name, Zertifikatsname und lizenzierter Hostname sind
unterschiedlich. Prüfen Sie alle drei mit dem Befehl aus 5.5 und
verbinden Sie sich immer mit dem lizenzierten Namen.
Der Dienst läuft, aber kein Client verbindet sich
- Löst der Name beim Client zur richtigen Adresse auf?
- Greift der DNS-Rebind-Schutz des Routers (siehe 3.7)?
- Ist die Freigabe im Router aktiv – bei DS-Lite auch für IPv6?
- Lauscht der Server?
sudo ss -lntp | grep 8888
- Blockiert UFW?
sudo ufw status
Der Browser zeigt eine Zertifikatswarnung
Der Browser-Viewer verwendet noch das Zertifikat der nativen Kanäle.
Richten Sie ein öffentlich vertrauenswürdiges Zertifikat nach
Abschnitt 10 ein.
Alles lief, seit heute nicht mehr
Zwei Klassiker: Das Zertifikat ist abgelaufen, oder die öffentliche
Adresse Ihres Anschlusses hat sich geändert und der DNS-Eintrag zeigt
ins Leere. Bei IPv6 betrifft ein Präfixwechsel beides gleichzeitig –
den DNS-Eintrag und die Freigabe im Router.