Quantcast
Channel: Andy – Andy's Blog
Viewing all articles
Browse latest Browse all 2170

Fernwartung mit RustDesk (zum selber hosten)

$
0
0

Nicht erst seit dem Hack von AnyDesk oder ConnectWise ScreenConnect sowie neuen Lücken bei TeamViewer sind Alternativen zu bekannten und gängigen Fernwartungslösungen gefragt. Aus dem Open Source-Lager ist RustDesk schon länger bekannt, um das es in der freien Variante zum selber hosten nachfolgend geht.

Einstieg und Grundlagen

Nahezu alle Fernwartungslösungen haben gemeinsam das der Hilfesuchende und der Supporter über einen Relay-Server miteinander verbunden werden. Dies hat den Vorteil das sich beide Seiten hinter entsprechenden Firewalls, NAT-Routern, DS-Lite-Anschlüssen, usw. befinden können und nicht eigenes für die Fernwartung Ports geöffnet werden müssen.

Diese Relay-Server stellen nicht nur die Konnektivität sicher, sondern sind gleichzeitig leider die Achillesferse. Verwendet man öffentliche Server der Anbieter und diese werden kompromittiert hat dies gleich weitreichende Auswirkungen auf viele oder gar alle Kunden des Anbieters. Daher ist es geschickter den Relay-Server selbst zu betreiben, zum einen gerät man nicht so leicht ins Fadenkreuz, zum anderen kann man im Gegensatz zu öffentlich erreichbaren Servern weitere Schutz-Maßnahmen ergreifen.

Der RestDesk Server OSS ist der Einzige, der eine öffentlich erreichbare IP-Adresse und ggf. einen FQDN haben muss. Öffentlich erreichbar gilt natürlich nur, sofern man die Lösung über das Internet (und ohne VPN) nutzen möchte. Soll RustDesk nur im LAN oder eigenen Standort-Verbund genutzt werden, kann man hierauf verzichten.

Bekannte Gegebenheiten – Allgemein wie auch bei der OSS-Ausgabe

RustDesk bezeichnet sich selbst als “The open source alternative to TeamViewer”. Das stimmt in Sachen grundlegender Handhabung sowie der relativ ähnlichen Oberfläche. Wie das große Vorbild wird eine ID zur Identifizierung des Computers verwendet. Dies hat, wie bei TeamViewer auch, Vor- wie auch Nachteile. Dadurch das die ID automatisch generiert wird muss man sich selbst keine Gedanken machen, wie eine solche Kennung aussehen soll oder was man tun muss damit sie Einzigartig bleibt.

Ändert sich allerdings aus irgendeinem Grund diese ID ist der Computer nicht mehr erreichbar und wird zudem als Offline (beim Supporter, sofern hinterlegt) angezeigt. Gerade dieses (Fehl-)Verhalten haben wir zu unserer TeamViewer-Zeit einige Male erlebt, vor allem in Verbindung mit Computerneustarts, manchmal genügte schon ein Dienst-Neustart. Das sorgte dann immer für unnötigen Stress, da man mitunter Sorge hatte, das der Computer nun nicht mehr läuft, nicht mehr richtig startet und folglich weiteres Ungemacht drohte. In Wahrheit war allerdings alles in Ordnung, das erfuhr man mitunter erst am nächsten Tag (vom Kunden). Jedenfalls sollten solche Situationen nicht sein. Ob das auch bei RustDesk passieren kann ist mir nicht bekannt.

Zum jetzigen Zeitpunkt (Anfang März 2024, Version 1.2.3-1) fehlen RustDesk noch ein paar Dinge oder es gibt ein paar Punkte die man kennen sollte:

  • Unklare Eigentumsverhältnisse: Laut GitHub Purslane Ltd. – Singapore.
  • Es gibt zwar eine Prüfung auf neue Versionen, aber keine automatische Aktualisierung. Diese soll kommen, solange muss man auf entsprechende Deployment-Tools zurückgreifen.
  • RustDesk nutzt hohe Ports (21115-21119/tcp, 21116/udp) und nicht 443/tcp (https), dies kann in entsprechend reglementierten Netzen ein Problem sein.
  • Ein Web-Interface gibt es nur bei der Pro-Ausgabe.
  • Es gibt noch keine WTS/RDSH-Unterstützung (direktes Verbinden zu einer Benutzersitzung), diese soll noch kommen.
  • Eine zentrale-automatische Konfiguration des RustDesk-Clients gibt es nur in der Pro-Ausgabe.
  • 2FA gibt es nur in der Pro-Ausgabe.

Soviel dazu was RustDesk noch nicht kann. Kommen wir nun zu dem was es kann:

  • Fernwartung, d.h. Bildschirm-, Tastatur- und Mausübertratung
  • Nutzung der Zwischenablage
  • Dateiübertragung
  • TCP-Ports weiterleiten. Hier kommt es darauf an, wie RustDesk genutzt wird, dazu ein andermal mehr.
  • Verbinden via RDP. Auch hier kommt es darauf an, wie RustDesk genutzt wird, dazu ein andermal mehr.
  • Sitzungsaufzeichnung
  • Chat und Sprach-Anruf
  • Für verschiedene Plattformen verfügbar: Windows, macOS, Linux, iOS, Android, Web

Installation des RustDesk Server OSS

In der Dokumentation sind alle relevanten Schritte für Linux, Windows, Docker und sogar Synology beschrieben, allerdings scheint diese nicht unbedingt aktuell zu sein.

Linux

Die Installation gemäß Dokumentation oder anderer Anleitungen habe ich unter Linux noch nicht getestet. Laut Aussagen mehrerer Kollegen scheint dies auch nicht ganz so trivial zu sein wie beschrieben. Ferner gibt es wohl zudem Schwierigkeiten bei der Aktualisierung. Womöglich ein Aktualitäts- oder Abhängigkeitsproblem, hierzu ist weiteres Feedback gerne willkommen.

Mein Kollege Jan empfiehlt (aufgrund dessen) die Nutzung von Docker wie er erst kürzlich in seinem Blog beschrieben hat:

TECH-SUPPORT.KOELN – Blog – RustDesk als Alternative für AnyDesk und TeamViewer

Windows

Die Installation unter Windows ist sehr einfach:

Die folgenden beiden Dienste werden eingerichtet:

hbbr
hbbs

Ferner wird die Windows-Firewall automatisch konfiguriert. Unter

C:\Program Files\RustDeskServer

finden sich nicht nur die Binär-Dateien, sondern im “bin”-Ordner der bei der Installation erzeugte private wie auch öffentliche Schlüssel, zudem sind im “log”-Ordner Protokolle zu finden.

Unter

C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\RustDesk

finden sich weitere Protokolle und vor allem die Datenbank, die vermutlich die erzeugten IDs enthält. Beide genannten Pfade sollten in eine Datensicherung einbezogen werden.

Im Info-Bereich erscheint ein Symbol über das man sowohl den Dienst (eigentlich die Dienste) steuern kann, vor allem allerdings die Protokolle einfach einsehbar sind.

Bemerkung: Die Ansicht aktualisiert sich nicht von selbst, am einfachsten unter “Logs” zwischen den Protokollen hin- und herspringen um die Ansicht zu aktualisieren.

Wichtige Dienst-/Daemon-Konfiguration

Man sollte (imho) unbedingt den Parameter “-k _” der Dienst- bzw. Daemon-Konfiguration anhängen, denn dieser sorgt dafür das keine unverschlüsselten Verbindungen zugelassen werden!

Unter Windows nutzt der RustDesk Server OSS das Tool NSSM (dieses wird mit installiert), daher lassen sich die beiden Dienste leicht ändern:

cd "C:\Program Files\RustDeskServer\service"
nssm edit hbbr
nssm edit hbbs

Jeweils im Feld “Arguments” “-k _” eintragen und mit einem Klick auf “Edit service” bestätigen.

RustDesk mit eigenem Server verwenden

Im Gegensatz zum Vorbild gibt es bei RustDesk keine verschiedenen Clients oder Installationspakete. Man lädt das für sein Betriebssystem aktuelle Release herunter und führt es aus. Unter Windows wäre dies zum jetzigen Zeitpunkt

rustdesk-1.2.3-1-x86_64.exe

Man kann die ausführbare Datei portable nutzen oder RustDesk installieren, aber Achtung: So direkt ausgeführt werden die öffentlichen Server verwendet!

Damit man seinen eigenen Relay- bzw. RustDesk OSS-Server angeben kann gibt es gleich mehrere Möglichkeiten:

Den Server samt öffentlichen Schlüssel (zu diesem) via Dateinamen mitgeben (gilt nur für Windows):

rustdesk-host=<IP-oder-FQDN>,key=<Öffentlicher-Schlüssel-des-Servers>.exe

Tipp: Vor “.exe” noch ein Komma einfügen. Dies verhindert wenn mehrmals ein so vorbereitetes RustDesk heruntergeladen wird (und dann mit “(1)”, “(2)”, usw. erweitert wird) der Schlüssel nicht mehr gelesen werden kann. Vielen Dank an Jan für diesen Tipp.

Dies ist zwar die einfachste Variante, hat allerdings den (imho massiven) Nachteil das man so sehr leicht den Server samt öffentlichen Schlüssel exponiert (z.B. wenn man das so zum Download auf der Homepage anbietet).

Besser ist es RustDesk mit den notwendigen Angaben selbst zu kompilieren oder (noch nicht getestet) die *.exe-Datei samt notwendiger Daten in ein selbst-extrahierendes Archiv zu packen.

In den Einstellungen von RustDesk kann man unter “Netzwerk” die Angaben manuell vornehmen:

Hier sind mindestens die Felder “Relay-Server” und “Key”, besser zusätzlich noch “ID-Server”, auszufüllen. Diese Variante kommt wohl nur für feste Installationen in Frage.

Eine weitere Option ist das Importieren einer zuvor exportierten Serverkonfiguration. Beides, Ex- wie Import, geht in den Einstellungen unter “Netzwerk”. Zusätzlich kann man eine so exportierte Konfiguration ebenfalls via Dateinamen oder als Parameter übergeben:

rustdesk--<String>--.exe
rustdesk.exe --config <String>

Beides funktionierte allerdings im Test leider nicht. RustDesk startet zwar mitunter, aber übernimmt die Einstellungen nicht. Im schlechtesten Fall startet die Anwendung noch nicht einmal. Unklar ist, ob dies ein aktueller Bug oder eine Einschränkung der OSS-Ausgabe ist.

Was ggf. einem schnellen Test nach ebenfalls möglich ist wäre das Kopieren der “RustDesk2.toml” um diese quasi als Vorlage oder Basis-Konfiguration nutzen zu können. Die besagte Datei findet sich unter

C:\Users\%username%\AppData\Roaming\RustDesk\config

Man sollte die Zeile “local-ip-addr =” vor der weiteren Verwendung aus der Datei entfernen.

Zu weiteren  Konfigurationsmöglichkeiten von RustDesk wird es demnächst einen oder mehr Beiträge geben.

Woran kann man erkennen, das RustDesk den eigenen Server verwendet?

Das kommt darauf an, wie die Einstellungen übergeben wurden. Bei der manuellen Einrichtung oder dem Import findet man die Daten unter

Einstellungen - Netzwerk

Wurde der Server samt Key über den Dateinamen übergeben, dann sieht man dies unter

Einstellungen - Über

(Der erste) Verbindungsaufbau

Auf beiden Seiten, gemeint ist beim Hilfsuchenden und dem Supporter, muss RustDesk ausgeführt werden und beide müssen mit dem gleichen Server verbunden sein. Der Supporter gibt die im mitgeteilte ID samt Kennwort (sofern kein festes konfiguriert wurde) ein und sieht daraufhin den Desktop bzw. die Konsole:

Was man von hier aus dann tun kann hängt davon ab, welche Berechtigung der Hilfesuchende einem erteilt hat oder fest konfiguriert ist:

Was gibt es noch?

Einiges, was den Rahmen dieses Beitrags sprengen würde, daher ist mindestens ein weiterer Beitrag geplant.

Leider sei angemerkt, das RustDesk (portable genutzt) nach der Beendigung ein paar Reste hinterlässt:

So finden sich unter

%LocalAppData%\RustDesk

die ausführbare Datei samt Bibliotheken. Unter

%AppData%\RustDesk

findet man wiederum die Konfiguration sowie Protokolldateien.

Eine Sitzung kann zwar einfach getrennt, dabei aber nur per (Vor-)Einstellung dann gesperrt werden. Hier wäre eine entsprechende Schaltfläche wünschenswert, man kommt allerdings auch so klar.

Fazit

RustDesk ist einfach nutzbar wie viele andere Lösungen auch. Das Einrichten eines eigenen Servers ist zudem je nach Betriebssystem oder Umgebung recht simple. Manche Macken oder Unzulänglichkeiten gibt es noch, aber man ist ja auch erst bei Version 1.2.3-1, es gibt also noch Luft nach oben.

Für wen ist RustDesk in der jetzigen Form zu gebrauchen?

Nun, für einige. Schon allein die Option zum Selber-Hosten (auch ohne Internet) kann viel zur Verfügbarkeit, Sicherheit und Performance beitragen. Weiter ist RustDesk recht einfach in ein Deployment sowie in Management-Lösungen integrierbar. Möchte man automatisch allerdings Dinge wie z.B. die Sitzungsdauer (für Dokumentation- oder Abrechnungszwecke) erfassen so fehlt es bislang an entsprechenden Journal-Möglichkeiten. Im Moment bekommt man nicht mal irgendwo die Sitzungsdauer angezeigt. Dennoch macht RustDesk Spaß und erfüllt seinen Zweck sowohl für den spontanen Support als auch feste Installationen.

Wer eine bestehende Fernwartungslösung hat kann RustDesk als Plan B, falls es doch mal eine größere oder längere Störung beim Bestand gibt, verwenden.


Viewing all articles
Browse latest Browse all 2170