FsRdpServer unter Linux installieren

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:

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.

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.

sudo apt update
sudo apt full-upgrade -y
sudo reboot

sudo apt install -y unzip openssl

timedatectl
sudo timedatectl set-timezone Europe/Berlin

ip -brief address show

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"

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.

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:

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

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.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“.

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

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 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.

sudo apt install -y lego

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

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

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.

unzip FsRdpServer-linux-x64.zip -d FsRdpServer
cd FsRdpServer
ls

chmod +x FsRdpServer install.sh
sudo ./install.sh

Was dabei entsteht:

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 ….

Die ersten 30 Tage brauchen keine Lizenz

Finden Sie keine Lizenzdatei im Datenverzeichnis, startet der Server trotzdem und läuft 30 Tage als Testinstallation. Dafür ist nichts einzuschalten: Paket installieren, Zertifikat und PFX-Passwort hinterlegen (Abschnitt 8), Dienst starten. Die Testphase ist in Zeit und Menge begrenzt, nicht im Funktionsumfang:

„Alle Funktionen" heißt wörtlich: Bildschirmfreigabe, Fernsteuerung, Kamera, Sprache, Chat, Dateiübertragung, Sitzungsaufnahme, Live-Untertitel und der Browser-Viewer. Deren technische Voraussetzungen gelten weiter – Untertitel brauchen einen eigenen API-Schlüssel, der Browser-Viewer seinen Port und ein Zertifikat (Abschnitt 10).

Alle Teilnehmer sehen während der Testphase ein Wasserzeichen über dem geteilten Bild. Das ist Absicht: Ein unlizenzierter Server soll als solcher erkennbar sein.

Was in der Testphase fehlt, sind die Supporter-Schlüssel – und damit die Funktionen, die an einem solchen Schlüssel hängen: reservierte Raumnamen und das Raum-Passwort, mit dem ein Kunde seinen Dauerraum im Browser selbst eröffnet. Das ist keine Sperre; ein Server ohne Lizenz gibt schlicht keine Schlüssel aus.

Nach 30 Tagen läuft der Dienst weiter und lauscht weiter, beantwortet aber jede Verbindung mit der Bitte um eine Lizenz – er verweigert nicht den Start. Eine Lizenzdatei können Sie jederzeit nachträglich einspielen (Abschnitt 12).

Die Lizenz anfordern

Für den Dauerbetrieb ist die signierte Lizenzdatei nötig. 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.

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

In der Testphase steht dort statt der Kundendaten:

License state:         trial
Trial state file:      /opt/fsrdp-server/data/trial-state.json
Trial period:          2026-09-11 through 2026-10-11 (30 day(s) left)
Trial room:            123456789

Die 30 Tage hängen am ersten Start dieser Installation, festgehalten in trial-state.json. Sie werden gegen den höchsten jemals gesehenen Zeitpunkt gerechnet – die Systemuhr zurückzustellen verlängert sie also nicht.

Im Startprotokoll steht unter anderem, welches Zertifikat geladen wurde und bis wann es gilt – ein guter erster Blick, wenn später etwas nicht funktioniert.

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

sudo install -o fsrdp-server -g fsrdp-server -m 0640 \
  /etc/lego/certificates/server.ihrefirma.de.pfx \
  /opt/fsrdp-server/data/webgateway-cert.pfx

sudoedit /etc/fsrdp-server/fsrdp-server.env

FSRDP_WEB_CERT_PASSWORD=das-passwort-der-webgateway-pfx

sudoedit /opt/fsrdp-server/data/appsettings.json

"WebGatewayEnabled": true,
"WebGatewayCertificatePath": "webgateway-cert.pfx",

sudo systemctl restart fsrdp-server
sudo journalctl -u fsrdp-server -n 30 --no-pager | grep -i certificate

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

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

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.

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.

Lizenz einspielen oder austauschen

Derselbe Weg für die erste Lizenz nach der Testphase wie für eine erneuerte. Den Dienst-Neustart braucht es nicht für die Lizenz selbst (die liest der Dienst von allein neu ein), wohl aber für die Funktionsschalter Browser-Viewer, Untertitel und Demo-Modus, die beim Start einmal gelesen werden.

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

Den Pi nur ans Netz nehmen, wenn er gebraucht wird

Ein Server, der nur gelegentlich zum Einsatz kommt – ein Vorführgerät, ein Ersatzgerät, ein Pi für eine Fernwartung pro Woche –, muss die übrige Zeit nicht am Netz hängen. Stöpseln Sie ihn erst etwa zwei Minuten vorher an; das genügt zum Hochfahren, der Dienst startet von selbst. Was nicht erreichbar ist, kann nicht durchsucht oder angegriffen werden, und die Portfreigaben für 8888, 8889 und 8890 machen den Pi dem gesamten Internet zugänglich, solange er am Kabel hängt.

Entscheidend ist dabei das Ausschalten: über den Knopf, nicht über den Stecker. Ein Raspberry Pi 5 hat einen Knopf auf der Platine – ein kurzer Druck fährt sauber herunter, ein Druck auf den gestoppten Pi startet ihn wieder. Ältere Modelle bekommen dasselbe Verhalten mit dtoverlay=gpio-shutdown in der config.txt und einem Taster zwischen Pin 5 (GPIO3) und Pin 6 (GND). Über SSH tut sudo poweroff dasselbe. Erst wenn die Aktivitäts-LED ruhig ist, den Stecker ziehen.

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.

Jeder Client meldet „Testphase abgelaufen"

Die 30 Tage sind vorbei. Der Dienst läuft weiter, nimmt aber keine Verbindung mehr an, bis eine Lizenz installiert ist (Abschnitt 12). --license-status zeigt in diesem Fall trial-expired samt Enddatum.

Der Server läuft in der Testphase, obwohl eine Lizenz installiert ist

Dann wurde die Lizenzdatei nicht gefunden oder nicht akzeptiert. Das Startbanner im Journal nennt beides nebeneinander: den erwarteten Pfad und den Grund. Typische Ursachen sind ein falscher LicensePath, fehlende Leserechte des Dienstkontos auf license.fsrdp, eine Lizenz für eine andere Installations-ID oder eine von Hand bearbeitete und dadurch ungültige Datei.

Der Dienst läuft, aber kein Client verbindet sich

1. Löst der Name beim Client zur richtigen Adresse auf?
2. Greift der DNS-Rebind-Schutz des Routers (siehe 3.7)?
3. Ist die Freigabe im Router aktiv – bei DS-Lite auch für IPv6?
4. Lauscht der Server? sudo ss -lntp | grep 8888
5. 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.