Fritzbox als rustdesk-server?

[f-user]

Da die Fritzbox offenbar auch als Server "mißbraucht" werden kann und ich letztens auf RuskDesk umgestiegen bin, würde mich interessieren, ob die Fritzbox (7490) auch als RustDesk-Server "mißbraucht" werden kann?

Da @PeterPawn sich nicht nur mit Fritzboxen scheinbar auskennt wie (kaum) (k)ein zweiter, Fritzbox mods auf seiner Github-Präsenz hat und interessanterweise ebenso eine RustDesk-Kopie, dachte ich mir, daß hier zu fragen vermutlich beste Aussichten hat, eine kompetente Einschätzung zu meiner Frage / Idee zu bekommen.

Vielen Dank schon mal im Voraus!


Hintergrund:

1. Der offizielle RuskDesk-Server scheint nicht verschlüsselt zu arbeiten und es wird angeraten, einen eigenen RustDesk-Server zu betreiben.
2. Wenn man von verschiedenen Endgeräten aus anderen per RuskDesk helfen möchte, müßte man entweder jedes Mal die Server-Einstellungen beim Gegenüber ändern oder die Port-Weiterleitung-Einstellungen auf der Fritzbox an das Endgerät (auf dem dann der RustDesk-Server-Dienst gestartet wird) anpassen.
3. Als Nicht-ITler habe ich nicht nur keinen Zugriff auf einen (externen) Server, sondern auch nicht die Angewohnheit, einen Rechner 24/7 (oder überhaupt "einfach so", d.h. "als Server") laufen zu lassen.
4. Die Fritzbox muß sowieso laufen, wenn ich RustDesk benutzen möchte, also wäre das das Gerät, das bei mir am ehesten die "Online-Präsenz" eines Servers erfüllt.

Da bei RustDesk schon mal nach mips-kompatiblen Binärdateien angefragt wurde, bin ich wohl nicht allein mit diesem Vorhaben - wobei es bei mir ja noch im Stadium des "geht das überhaupt"-Fragens ist.

 

[PeterPawn]

Das habe ich noch nie versucht. Für einige Modelle könnte man vermutlich die angebotenen Binaries verwenden (z.B. die Puma7-Modelle mit der i386-Version, wobei auch das Probleme bereiten kann, denn es gibt Differenzen zwischen dem ATOM-Befehlssatz und anderen Kern-Architekturen), aber für die 7490 als MIPS-basierte Box gibt es keine Binaries.

Auch ein "cross compile" für MIPS ist nicht aus dem Ärmel geschüttelt, da es eben ein Rust-Projekt ist und man damit erst mal die ganze Umgebung (Compiler und die verwendeten Libraries) für so eine Aktion "vorbereiten" muß.

Das lohnt sich m.E. nicht wirklich im Angesicht dessen, daß ein einfacher RasPi (o.ä.) fast keinen Energieverbrauch hat, weitere Aufgaben übernehmen kann und dafür auch Binaries angeboten werden. Will sagen, ich denke da auch nicht drüber nach … sorry.

 

[NanoBot]

Also die Möglichkeit einen eigenen Rendevous- und Relay-Server direkt auf der FB laufen zu lassen, wäre auch für mich interessant.

Derzeit habe ich einen eigenen Server als Test auf einer Streamingbox mit einem AMLogic S905X3 Soc unter CoreElec laufen, und das funktioniert problemlos. Dazu muß dieses Gerät aber eingeschaltet bleiben, was trotz des geringen Stromverbauches suboptimal ist. Daher finde ich die Idee, einen Rustdesk Server direkt auf der FB ( in meinem Falle einer 7530 ) laufen zu lassen verlockend.

Für mich stellt sich dann allerdings die Frage, ob es in Zukunft Probleme mit dem Portforwarding direkt auf die Box selbst geben könnte; ich hatte so nebenbei etwas davon gelesen. Denn für den Rustdesk Server müssten die Ports 21115 - 21119 TCP sowie 21116 UDP per NAT direkt auf die interne IP der FB geleitet werden.

 

[PeterPawn]

einen eigenen Rendevous- und Relay-Server direkt auf der FB laufen zu lassen

Dem sollte ja wenig entgegenstehen, solange es sich eben nicht gerade um eine MIPS-basierte Box handelt.

Und eine 7530ax ist nun mal KEINE MIPS-Box, sondern hat 3 Cortex-A9-Kerne … verwendet also eine ARM-Archtektur.

Das heißt dann wieder, daß die Binaries für armv7 laufen KÖNNTEN - falls irgendwelche Pfade nicht passen, muß man halt etwas mit bind-Mounts oder besser gleich mit einem overlayfs jonglieren, um die Umgebung notfalls passend zu machen. Mit einem (persistenten) Overlay kann man dann auch gleich die passenden Einstellungen zusammen mit den Binaries speichern.

Der Anfang von allem ist halt erst einmal die Modifikation der Firmware, damit man überhaupt eigene Software starten (lassen) kann. Ohne Shell-Zugriff wird's garantiert schwer mit entsprechenden Versuchen …

Schwieriger sehe auch ich da allerdings die Freischaltung von Ports - bei AVM müssen die auch für lokal (also auf der Box) laufende Services per PCP "angemeldet" werden und es gibt bei PCP KEINE Garantien, einen gewünschten Port auch 1:1 gemappt zu bekommen (hatten wir letztens erst irgendwo als Thema).

Es gibt/gab zwar auch Möglichkeiten, per ar7.cfg permanente Freigaben für lokale Daemons einzurichten, aber das wird vermutlich künftig anderen Neuerungen zum Opfer fallen (oder ist es bereits in den Inhouse-/Labor-Versionen) und dann braucht man für Software auf den Boxen noch zusätzliche Software, um solche Portfreigaben "normgerecht" beim pcpd anzumelden.

Für den FTP-Server und die bei passiven Transfers dann notwendige dynamische Portfreigabe gibt (oder gab) es ein Binary von AVM in der Firmware - nur müßte man dieses in einem weiteren Prozess dann regelmäßig aufrufen, denn die TTL so einer Freigabe liegt (iirc) bei AVM nur bei 120 Sekunden.

EDIT:
PS: Auch der RAM-Bedarf könnte noch zum Problem werden - die Box hat nur 512 MB und ohne (größeres) Swap-File wird es schnell zur OOM-Panic kommen, zumal AVM praktisch alle Treiber als "non-swappable" behandelt. Das sollte man also - neben der reinen Frage, ob die Software kompatibel ist - auch noch im Auge behalten.

 

[f-user]

Schönen Dank für die Einschätzung(en)!

Als reiner Nutzer und Nicht-Programmierer kann ich schlecht abschätzen, ob die Hardware das kann und ob für MIPS-Prozessoren standardmäßig kompiliert werden kann (d.h., ob "normale" Kompiler die im Standard-Sortiment haben). Daher haben mir die "Bedenken" schon weitergeholfen.

Auf Github meinte zwar einer, daß man zum Erstellen einer MIPS-Binärdatei einfach die Einstellungen ändern kann, aber zumindest bei mir kommt da genau dieselbe Dateigröße heraus wie mit den Standard-Einstellungen. Von daher habe ich so meine Zweifel, daß es (für Anfänger wie mich) gar so einfach ist. Und selbst dann müßte ich ja die Binärdatei erst einmal auf einer modifizierten 7490 zum Laufen bekommen.

Was den RAM-Bedarf (auf einem Rechner) anbelangt, muß ich mal beobachten, wie der sich so bei Nutzung verhält. Im "Leerlauf" hält er sich in Grenzen, aber das ist ja irrelevant für den angestrebten Zweck.

Vorerst bleibt das daher wohl eher ein Wunschtraum als ein realisierbares Vorhaben.

 

[NanoBot]

Was den RAM-Bedarf betrifft kann ich eine grobe Einschätzung liefern:

Auf dem S905X3 SOC ( das ist die Architektur arm64v8 ) belegt der Rustdesk Server laut dem Feld "VIRT" unter top im Leerlauf 20788 kB für hbbs und 15712 kB für hbbr. Mit einem angemeldeten Client sind es dann 20836 kB für hbbs, hbbr bleibt gleich.

Ich vermute mal daß die 7530 ( bei mir nicht ax ) mit der armv7l Architektur ( 32bit ? ) mit etwas weniger RAM auskommen würde ? Trotzdem könnte das knapp werden, denn auf der FB7530 sind laut "free" im Moment 84788 kB frei.

 

[PeterPawn]

Auch die 7530 "ohne AX" sollte eine ARM-Architektur verwenden (sogar 4 Cores, aber niedriger getaktet), hat aber m.W. nur halb so viel Arbeitsspeicher. Wenn ich so eine besitzen würde, würde ich es halt einfach mal versuchen mit den armv7-Binaries. Bei reinem LAN-Zugriff sollte man dann auch den Ressourcenbedarf bei aktiver Verbindung einschätzen können, bevor man sich der PCP-Problematik widmet.

 

[f-user]

Mittlerweile konnte ich den RAM-Bedarf bei Fern-Nutzung nachschauen: hbbs: 21,5 MB, hbbr: 16 MB (jeweils virtuelle Bytes)
Von der Seite her sollte es wohl funktionieren.
Aber die anderen Baustellen sind schwierig genug, so daß ich warten muß, bis andere das erfolgreich getestet haben - inkl. Erstellen von MIPS-Binärdateien...

Vielleicht habe ich ja Glück und AVM baut mal eine "router-/modemfremde Funktion" ins nächste Update ein, die ich auch brauchen kann...

 

[NanoBot]

So, ich hatte gerade etwas Zeit und habe die arm7 binaries für den rustdesk server auf einen an der 7530 angeschlossenen USB-Stick kopiert. Da diese binaries im Original unter /opt/rustdesk liegen habe ich den Stick mit "mount --bind /var/media/ftp/FRITZ-1/opt/ /opt" eingebunden. Das funktioniert auch soweit, die Dateien werden mit "ls /opt" angezeigt.

Der Befehl "/opt/rustdesk/hbbr -k _" wird jedoch mit "/opt/rustdesk/hbbs: Permission denied" abgelehnt. Ich erinnere mich dunkel daß AVM das Starten von binaries auf einem externen Datenträger aus Sicherheitsgründen blockiert und man dies erst durch einen speziellen Befehl wieder erlauben muß, kann mir da jemand auf die Sprünge helfen ?

 

[PeterPawn]

mount -o remount,exec /var/media/ftp/FRITZ-1

 

[NanoBot]

Danke für den Tipp, der rustdesk-server läuft auf der 7530 zumindestens intern im LAN bisher problemlos. Merkwürdigerweise ändert sich an der Belegung des RAMs nahezu nichts.

Jetzt muß ich einerseits noch herausfinden, wie ich auf der 7530 rustdesk beim reboot automatisch mit starten lassen kann. Da ich sowieso freetz auf der Box habe sollte sich die rc.custom dafür anbieten. Und zum anderen bliebe dann ja noch das Problem mit der "AVM-konformen" Portweiterleitung auf die IP der Box selbst.

 

[NanoBot]

So, das Problem mit dem noexec auf dem USB-Datenträger konnte ich durch ein neu erzeugtes freetz-ng mit gesetzter Option "Drop noexec on external storages" lösen. Das "übermounten" des Verzeichnisses /opt durch /var/ftp/FRITZ-1/opt erfolgt jetzt korrekt und die rustdesk binaries lassen sich, inkl. Umleitung von stdout und stderr in entsprechende Logdateien als Hintergrundprozess starten. Der Rustdesk-Server funktioniert wie er soll, aber die Portweiterleitung auf die interne IP der Box will nicht so wie sie sollte.

Ich habe die folgenden Einträge erfolgreich zur ar7.cfg hinzugefügt, welche jedoch ohne Wirkung bleiben:

voip_forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",
                    "tcp 0.0.0.0:5060 0.0.0.0:5060",
                    "udp 0.0.0.0:7078+20 0.0.0.0:7078",
                    "tcp 0.0.0.0:21115 0.0.0.0:21115 #Rustdesk",
                    "tcp 0.0.0.0:21116 0.0.0.0:21116 #Rustdesk",
                    "tcp 0.0.0.0:21117 0.0.0.0:21117 #Rustdesk",
                    "udp 0.0.0.0:21116 0.0.0.0:21116 #Rustdesk";

Unter Diagnose -> Sicherheit werden die zusätzlichen Ports nicht angezeigt, dort erscheinen nur die Einträge

5060 TCP, IPv4, UDP Telefonie (SIP)
51398 TCP, IPv4, IPv6 Anbieter-Dienste (TR-069)

Kann es sein, daß AVM mit der 7.57 die Möglichkeit zusätzlicher Einträge unter voip_forwardrules blockiert hat ?

P.S.:

Wenn ich die nötigen Ports per pcplisten weiterleite, dann erscheinen sie auch unter Diagnose -> Sicherheit. Aber alle 120s erneut die Ports weiterleiten, echt jetzt, AVM ?

 

[PeterPawn]

Aber alle 120s erneut die Ports weiterleiten, echt jetzt, AVM ?

Das ist nun mal so bei PCP. Zumal es ja nun keine wirkliche Kunst ist, solange die rustdesk-Daemons laufen, regelmäßig die Portfreigaben zu erneuern. Das ist ein (relativ) simples Shell-Skript, wenn man auf das pcplisten von AVM (das wird auch - wie weiter oben schon erwähnt - vom FTP-Server verwendet für dynamische Freigabe des Data-Channels) zurückgreift …

Und wenn AVM inzwischen keine statischen Freigaben auf die Box selbst mehr unterstützt, ergibt das durchaus Sinn - die eigenen Daemons verwenden passende Libraries, mit denen die notwendigen Freigaben eingerichtet werden können (und die Daemons "wissen" dann auch selbst am besten, welche - ggf. dynamisch belegten - Portnummern freizugeben wären) und Freigaben auf andere Geräte im LAN werden dort verwaltet, wo solche Geräte auch ansonsten definiert sind - nur stehen die dort eben im direkten Zusammenhang mit den Adressen dieser Geräte und können nicht "intern" verwendet werden.

Das dürfte m.E. also nur am Rande mit "abschaffen" zu tun haben - eher ist es die Konzentration auf das Wesentliche und auf das, was im FRITZ!OS selbst an Funktion benötigt wird. Nicht zu vergessen die immer noch benötigte "packet acceleration", die für höheren Durchsatz erforderlich ist und ein permanentes Umleiten von Paketen über die CPU praktisch verbietet.

Vielleicht findet sich ja auch mal jemand, der mit dem pcplisten ein passendes Framework implementiert, bei dem dann auch Prozesse auf der Box selbst nur noch ihre Wünsche "anmelden", ohne sich selbst um die Einrichtung und die regelmäßige Erneuerung kümmern zu müssen. Das ist ja eigentlich keine "rocket science" … oder man untersucht die AVM-Libraries für PCP-Freigaben genauer und nutzt die dort enthaltenen Funktionen nach, anstatt sich auf das pcplisten zu verlassen, das ja ebenfalls keine "zugesicherte Eigenschaft" bei AVM (und vermutlich weniger "stabil" als die Libraries) ist.

 

[f-user]

Kann man hbbs nicht per "/hbbs -r [externe IP der FB]:21117 -k _" zwingen, auf der externen FB-IP zu lauschen und die Portweiterleitung dann über die Oberfläche einrichten?

 

[PeterPawn]

auf der externen FB-IP zu lauschen

Du hast doch sicherlich eine eigene Box mit Shell-Zugriff. Siehst Du da irgendwo ein Netzwerk-Interface mit dieser "externen Adresse"? Vermutlich nicht, denn das läuft bei AVM (praktisch schon immer) deutlich anders - damit ist dieses Vorhaben (jedenfalls so "simpel", wie Du es Dir oben vorstellst) zum Scheitern verurteilt.

Da ist die Frage, wie genau man eine Weiterleitung von der externen Adresse AUF die externe Adresse (wie vorgeschlagen: im GUI) realisieren soll, noch gar nicht berücksichtigt - eigentlich wäre ja GAR KEINE Weiterleitung erforderlich, wenn man den Service wie gezeigt an die externe Adresse binden könnte. Auf einem "normalen" System müßte man dann nur noch den Port in der Firewall für eingehende Verbindungen öffnen - aber bei AVM ist das eben alles anders.

EDIT:
Und wenn man keinen Shell-Zugriff hat, findet man die Angaben zu den Interfaces auch in den Support-Daten.

 

[f-user]

Stimmt - wenn die "äußere IP-Adresse" zugänglich wäre, bräuchte man keine Portweiterleitung mehr... Den Teil der "dummen Frage" nehme ich mal zurück...

Ich hatte erwartet / befürchtet, daß man nicht so einfach mal auf die "äußere IP-Adresse" zugreifen kann...

Folglich ist dann eine Portweiterleitung (GUI) auf die "innere IP-Adresse" wohl auch nicht möglich...

Allerdings sehe ich den Support-Daten folgendes:

Active Internet connections (servers and established)
...
udp 0 0 [äußere IP-Adresse]:39963 0.0.0.0:* 2465/ctlmgr
...
udp 0 0 [äußere IP-Adresse]:1900 0.0.0.0:* 2465/ctlmgr
udp 0 0 [äußere IP-Adresse]:1900 0.0.0.0:* 2488/upnpd


Mit etwas Können und Wissen sollte doch auch ein

tcp 0 0 [äußere IP-Adresse]:11117 0.0.0.0:* [pid]/hbbs
udp 0 0 [äußere IP-Adresse]:11116 0.0.0.0:* [pid]/hbbr

im log "verursachbar" sein, d.h. eine solche Weiterleitung herbeihacken...?


[Bin von "externe" und "interne" IP auf "äußere" und "innere" IP gewechselt, weil ja das, was ich mit "äußere" IP-Adresse meine, eigentlich die interne/lokale IP-Adresse ist im Zusammenhang mit dem Netzwerk, und und die externe IP-Adresse die vom Internet-Anbieter zugewiesene. Das macht es zwar nicht unbedingt besser, aber immerhin werden so die Begriffe intern und extern nicht vom mir umdefiniert.]

 

[PeterPawn]

eine solche Weiterleitung herbeihacken

Nichts anderes macht so ein pcplisten - aber eben nur für eine (sehr) begrenzte Zeit und wie lange so ein Eintrag (noch) lebt, sollte auch irgendwo in der Nähe stehen.

Das mit "äußere" und "innere" Adresse blicke ich nicht - ja, daß da eine Weiterleitung für Port 1900 von der "äußeren" Adresse existieren soll, verwirrt mich vollends. Entweder der Kontext ist total daneben oder diese "Freigaben" erfolgen für das LAN-seitige Interface (wo sie wieder normal erscheinen würden) und dann verstehe ich erst recht nicht, was hier die "äußere" Adresse sein soll. Vielleicht wäre es doch praktischer, wenn man da die "echten" Angaben verwendet und notfalls nur das letzte (meinetwegen noch das davor) Tupel einer (EDIT: öffentlich erreichbaren) IP(v4)-Adresse abändert.

 

[f-user]

Sorry. Hier nochmal mit einer dezidierten IP-Adresse statt Platzhalterformulierung:

Allerdings sehe ich den Support-Daten folgendes:

Active Internet connections (servers and established)
...
udp 0 0 192.168.178.2:39963 0.0.0.0:* 2465/ctlmgr
...
udp 0 0 192.168.178.2:1900 0.0.0.0:* 2465/ctlmgr
udp 0 0 192.168.178.2:1900 0.0.0.0:* 2488/upnpd


Mit etwas Können und Wissen sollte doch auch ein

tcp 0 0 192.168.178.2:11117 0.0.0.0:* [pid]/hbbs
udp 0 0 192.168.178.2:11116 0.0.0.0:* [pid]/hbbr

im log "verursachbar" sein, d.h. eine solche Weiterleitung herbeihacken...?

 

[NanoBot]

Da die Methode mit den "voip_forwardrules" in der ar7.cfg offenbar nicht mehr funktioniert habe ich die Portweiterleitung jetzt mit Hilfe eines Scriptes gelöst, welches per crontab ( hierzu ist freetz erforderlich ) jede Minute einmal aufgerufen wird. Vorab sei daran erinnert, daß der Pfad "/opt" in Wirklichkeit der Pfad "/ftp/FRITZ-1/opt/" ist. Es handelt sich also um ein Verzeichnis auf dem USB-Stick, welches mit Hilfe von "mount --rebind" als "/opt" gemountet wurde. Der Pfad /opt befindet sich nämlich normalerweise im SquashFS und ist somit ReadOnly. Da meine Box eine 7530 ist, verwende ich die rustdesk-server binaries für die ARMv7 Architekur. Da der Stick FAT32 formatiert ist, braucht ich mich um die Zugriffsrechte der Dateien auf dem Stick nicht zu kümmern.

Die Datei "/opt/rustdesk/OpenRustdeskPorts.sh" öffnet die erforderlichen Ports um den rustdesk-server aus dem Internet erreichen zu können:

#!/bin/bash
date
pcplisten tcp 192.168.1.254 21115 59 Rustdesk-Server
pcplisten tcp 192.168.1.254 21116 59 Rustdesk-Server
pcplisten tcp 192.168.1.254 21117 59 Rustdesk-Server
pcplisten udp 192.168.1.254 21116 59 Rustdesk-Server

Der TCP Port 21114 wird nur bei der "PRO" Version des rustdesk-servers benötigt und daher nicht berücksichtigt. Die TCP Ports 21118 und 21119 werden ebenfalls nicht benötigt weil der rustdesk-server für die Architektur ARMv7 kein Webinterface hat. Der "date" Befehl dient lediglich dazu, die regelmäßige Ausführung des Scriptes bei Bedarf in einem Logfile zu dokumentieren.

Das obige Script wird mit dem folgenden crontab Eintrag einmal pro Minute ausgeführt:

* * * * * /opt/rustdesk/OpenRustdeskPorts.sh >> /dev/null

Anstelle der Umleitung nach /dev/null kann man hier für Diagnosezwecke eine Umleitung zum Beispiel nach /opt/rustdesk/log/openports.log verwenden, in welchen dann jeweils die Uhrzeit ersichtlich wird, zu der OpenRustdeskPorts.sh ausgeführt wurde. Dies sollte normalerweise zu jeder vollen Minute der Fall sein.


Mit diesem Befehl kann man per telnet/ssh auf der Box nachprüfen, ob die Portweiterleitungen funktionieren und regelmäßig eneuert werden:

root@fritz:/opt/rustdesk# cat /proc/kdsld/dsliface/internet/ipmasq/pcp44 | egrep '21115|21116|21117'
MAP  UDP [192.168.1.254]:21116 [94.134.52.180]:21116 use 1, lifetime 59 secs, expire in 19 secs
MAP  TCP [192.168.1.254]:21115 [94.134.52.180]:21115 use 1, lifetime 59 secs, expire in 19 secs
MAP  TCP [192.168.1.254]:21117 [94.134.52.180]:21117 use 1, lifetime 59 secs, expire in 19 secs
MAP  TCP [192.168.1.254]:21116 [94.134.52.180]:21116 use 1, lifetime 59 secs, expire in 19 secs
root@fritz:/opt/rustdesk#

Stattdessen kann man auch auf dem Webinterface der Fritz!Box unter Diagnose -> Sicherheit sehen, ob die Ports wie gewünscht auf die LAN-IP der Fritz!Box weiter geleitet werden.

Der Befehl pcplisten legt einem noch einen weiteren Stein in den Weg: Wenn man in benutzt, während die lifetime der Portweiterleitung noch nicht abgelaufen ist, wird die lifetime der Weiterleitung NICHT erneuert oder verlängert. Stattdessen wird der Befehl ignoriert. Das ist auch der Grund dafür, wieso ich eine lifetime von 59s gewählt habe und diese alle 60s per cron erneuern lasse. Meine Tests haben ergeben, daß nur so sicher gestellt ist, daß die Ports (nahezu) dauerhaft weiter geleitet werden. An der "Lücke" von 1s bei der Weiterleitung stören sich die rustdesk-clients, welche den Server nutzen sollen zum Glück nicht.

 

[NanoBot]

Hier noch ein Hinweis für @f-user:
https://github.com/rustdesk/rustdesk-server/issues/401

An einer Version für mips wird also gearbeitet, aber ob und wann sie irgendwann einmal "ready for production use" sein wird, bleibt abzuwarten.