Verbesserungsvorschlag Paket avm-rules, bitte die Ziel-IP der Weiterleitung per GUI konfigurierbar machen

[MatrixUser]

Erstmal vielen Dank für dieses Paket. Bisher habe ich solche Portweiterleitungen mit einem Script, welches pcplisten nutzt und per crontab aufgerufen wird, durchgeführt. Für Nutzer, welche sich nicht so gut auskennen ist dieses Paket aber eine echte Erleichterung.

Ich habe die folgende Bitte bezüglich des Paketes avm-rules:

Wie man aus dem Sourcefile https://github.com/Freetz-NG/freetz-ng/blob/5ceefaacf58b665ef26ba2643767258471bf5c3c/make/pkgs/avm-rules/files/root/usr/bin/avm-rules ersehen kann, werden die gewünschten Ports auf die fest vorgegebene IP 169.254.1.1, also auf die Notfall-IP der Fritz-Box (Schnittstelle "lan:0"), weiter geleitet. Nun betreibe ich auf meiner Fritz!Box 7690 einen Rustdesk-Server, welcher aber nur auf der "offiziellen" internen IP (Schnitstelle "lan"), der Fritz!Box lauscht. Er reagiert weder auf 169.254.1.1 (lan:0) noch auf 127.0.0.1 (lo).

Durch eine manuelle Änderung der Ziel-IP in der oben genannten Datei kann man erreichen, daß pcplisten die "echte" interne IP (also die 192.168.x.x) als Ziel benutzt, wodurch der Rustdesk-Server dann problemlos arbeitet.

Mein Wunsch / Vorschlag: Das Paket avm-rules sollte dahin gehend erweitert werden, daß man die gewünschte Ziel-IP für die Portweiterleitun(en) manuell ändern kann. Ideal wäre es, wenn das Paket beim Start die interne IP (Schnittstelle "lan") der Fritz!Box ausliest und als default-Wert vorgibt. Dann könnten auch Programme, welche wie der Rustdesk-Server nur auf der "offiziellen" internen IP-Adresse lauschen von diesem Paket profitieren. Leider kann ich nicht selber programmieren, so daß ich keinen fertigen Patch einreichen kann.

C.U. MatrixUser

[manfred-mueller]

Hallo MatrixUser,
im Anhang das patch.
Die IP ist konfigurierbar und ein paar kleine Lokalisierungen sind auch noch dabei ;-)

LG Manfred

avm-rules_ip.zip

[MatrixUser]

Hi Manfred,

zuerst einmal vielen Dank für die sehr schnelle Reaktion. Ich habe den Patch bei mir selbst bisher noch nicht getestet, weil ich meine Fritz!Box immer nur neu flashen kann/darf, wenn niemand im Haushalt ins Internet will. Ich habe aber einem Interessierten im IP-Phone Forum den Link auf diese Diskussion und zum Patch genannt und bei ihm funktioniert er wie gewünscht:
https://www.ip-phone-forum.de/threads/fritzbox-als-rustdesk-server.318700 die letzten Posts in diesem Thread.
Optimal wäre jetzt noch, wenn das Paket die interne IP der FB auslesen würde und als default Wert vorgibt, aber dies ist auch nur ein "Luxusproblem".

C.U. MatrixUser / Nanobot

[manfred-mueller]

Hi MatrixUser,

here you go ;-)

avm-rules_ip_hosts.zip

LG Manfred

[pfichtner]

Wäre die Änderung/Erweiterung nicht generell, also für alle interessant oder warum ein gezipte Patchfiles statt einem Fork/Branch/Pull-Request?

[manfred-mueller]

... warum ein gezipte Patchfiles statt einem Fork/Branch/Pull-Request?

wegen

...Leider kann ich nicht selber programmieren, so daß ich keinen fertigen Patch einreichen kann.

Hilfe zur Selbsthilfe - Außerdem ist die erste Variante als pull request eingereicht ;-)

Edit: Das erste ist geschlossen und eine neues pull request erstellt...

LG Manfred

[fda77]

@manfred-mueller zuerst mal danke für die PR!

• ich würde im Script keine Sprache unterscheiden, währen man es programmiert kopiert man es oft auf die Box, und dann nerven die "keine Sprache" Fehler nur herum ;-)
• Ansonsten funktioniert das Script nicht mit beliebigen IPs! zb die Lan-IP wird von AVM verwendet. So ist IMMER 1 Weiterleitung offen. dh es wird die Wartezeit nicht korrekt berechnet. Auch kann es zu dedlocks kommen wenn es mehrere Weiterleitungen von AVM gibt ("wasting")

Aber vielleicht solltet ist vorne anfange und mal überlegen wie sinnvoll es ist Port im "internen" (lan) Interface freizugeben!
Normal startet man einen Daemon auf "allen" (::) oder speziellen IPs. Für Dinge im Internet nimmt man normal "alles" - und so geht die vorgegebene IP des Scripter.
Am "internen" Interface lauschen Dinge die man nicht im Internet nutzen können soll. Damit werft ihr mit diese Änderung dieses übliche Vorgehen übern den Haufen. Das wird auch Folgefehler nach sich ziehen auf die wieder viel Zeit geht.

Daher würde ich dem Administrator einfach sagen er soll diesen rust-server richtig konfigurieren

[fda77]

Für den Admin:
https://www.bestrusthosting.com/guides/how-to-configure-your-rust-server-all-options-explained/

[MatrixUser]

Nur um einem Irrtum vorzubeugen: Es geht nicht um den verlinkten "rust server", sondern um den Relay- und Rendezvousserver für die remote Desktop Software "rustdesk", siehe hier: https://github.com/rustdesk/rustdesk-server

Und dieser lauscht eben leider nur auf der IP eines Interfaces, was aber durch den Patch kein Problem mehr ist.

[fda77]

Okay, 1 minute verschwndet:

von : https://rustdesk.com/docs/en/self-host/rustdesk-server-oss/install/#set-up-your-own-server-instance-manually

wget https://raw.githubusercontent.com/techahold/rustdeskinstall/master/install.sh
chmod +x install.sh
./install.sh

./docker/rootfs/etc/s6-overlay/s6-rc.d/user/contents.d/hbbs
./docker/rootfs/etc/s6-overlay/s6-rc.d/user/contents.d/hbbr

sudo netstat -anp|grep hbb
tcp6       0      0 :::21115                :::*                    LISTEN      3239/hbbs
tcp6       0      0 :::21117                :::*                    LISTEN      3424/hbbr
tcp6       0      0 :::21116                :::*                    LISTEN      3239/hbbs
tcp6       0      0 :::21119                :::*                    LISTEN      3424/hbbr
tcp6       0      0 :::21118                :::*                    LISTEN      3239/hbbs
udp6       0      0 :::51308                :::*                                3239/hbbs
udp6       0      0 :::21116                :::*                                3239/hbbs
unix  3      [ ]         STREAM     VERBUNDEN     29418    3424/hbbr
unix  3      [ ]         STREAM     VERBUNDEN     27975    3239/hbbs
unix  3      [ ]         STREAM     VERBUNDEN     29417    3424/hbbr
unix  3      [ ]         STREAM     VERBUNDEN     27974    3239/hbbs

Dass dieser andere rust Server mit nur 1 und speziellen privaten IPs klarkommt stimmt also nicht

[MatrixUser]

Auf der Fritz!Box wird mir mit netstat das gleiche angezeigt; der rustdesk-server sollte also eigentlich auf den IPs aller Interfaces erreichbar sein. Soweit so gut, aber die Praxis zeigt eben ein anderes Verhalten.

Aufgrund der Postings im oben verlinkten Thread aus dem IP-Phone Foum habe ich folgendes ausprobiert:

Derzeit mache ich die Portweiterleitungen auf meiner eigenen FB7690 noch mit einem Script, welches ist per cron aufrufe. Wenn ich die Ports per pcplisten auf die 192.168.1.254 (das ist die interne IP meiner FB) weiterleite, ist der Server sowohl aus dem LAN als auch aus dem Internet per dyndns-Adresse erreichbar. Leite ich dagegen auf 169.254.1.1 oder 127.0.0.1 weiter, ist der Server nicht erreichbar. In der Theorie sollte die IP der Weiterleitung also egal sein, in der Praxis ist sie es aber nicht.

Ungeachtet führt der Patch dadurch, daß die Ziel-IP jetzt konfigurierbar ist ja jetzt zum Ziel, so daß die Frage, wieso sich der rustdesk-server so "komisch" verhält, nicht mehr weiter erörtert werden braucht.

[fda77]

Ich hab oben schon ausgeführt welche Probleme es durch diese Erweiterung von avm-rules geben wird und es keine gute Idee ist.

[MatrixUser]

Ok, ich kann die Einwände innerhalb gewisser Grenzen nachvollziehen. Dann bleibe ich bei der Methode mit dem crond und dem Script, denn dies funktioniert seit mehreren Monaten problemlos.

Eine Merkwürdigkeit ist mir aber eben noch aufgefallen:

Im Rustdesk-Client in meinem eigenen Lan kann ich sowohl meine dyndns-Adresse, die 192.168.1.254 oder 169.254.1.1 als IP des Rendezvousservers angeben. In allen drei Fällen kann der Client die Verbindung zum Server aufgebaut und alles funktioniert. Wenn ich die Ports auf die IP 169.254.1.1 weiterleite, zeigt mir ein online Portscanner an, daß diese Ports offen sind. Ungeachtet dessen kann ein Rustdesk-Client aus dem Internet den Server dann unter meiner dyndns Adresse nicht erreichen, während es bei der Weiterleitung auf 192.168.1.254 problemlos klappt. Da ist also eventuell im Rustdesk-Server selber noch irgendwo der Wurm drin.

[fda77]

Bei AVM kann es Probleme geben wenn man seine eigene externe (öffentliche) IP von einem Client aus dem Lan heraus verwendet.
Das liegt daran dass AVM nicht wie ein normaler Routet routet sondern dies duch diese komischen closed-source Daemons macht.
Daher von extern einen dyndns verwenden, und lokal die lokale ip. Dazu muss man den Server aber so konfiguirert haben dass es auf allen IPs/Interfaces hört. Dass rust dies kann siehst du oben an netstat.
169.254.1.1 sollst du im Lan NICHT verwenden. Diese IP wird INTERN von avm-rules verwendet. AVM routet die nicht unbedingt...

[aus-sua]

Lt. meinem Verständnis ist es doch immer noch möglich (auch mit F-OS 08.x), auf der FRITZ!Box
intern (für diese FRITZ!Box) eine zusätzliche IP-Adresse zu erzeugen.
z.B. ip addr add $ipAddr/24 brd + dev lan label $nameIF

Wenn man jetzt z.B. bei IP-Bereich 192.168.1.1/24 und FRITZ!Box IP: 192.168.1.1 einfach einmal
z.B. die 192.168.1.251 (auf und als FRITZ!Box intern) zusätzlich erstellt, danach mit avm-rules (mit dem o.g. IP-Patch...)
für genau die neue/zusätzliche 192.168.1.251 für Rustdesk-Server mit hbbs und hbbr anwendet/freigibt
und dann den Rustdesk-Server mit hbbs und hbbr startet, funktionieren dann
die ID-Server (hbbs) und Relay-Server (hbbr)?
Ich könnte mir vorstellen, die 169.254.1.1 ist ev. das Problem für den Rustdesk-Server mit/durch hbbs/hbbr?

[MatrixUser]

Habe ich eben mal getestet, aber dieses Vorgehen hilft aber leider auch nicht. Ich habe der Schnittstelle "lan" zusätzlich die IP 192.168.1.252 zugewiesen ( wurde laut ip address show auch korrekt ausgeführt ) und auf diese IP weitergeleitet.

PSPing64 zeigt auf dem remote Rechner an, daß die Ports 21115-21117 erreichbar sind, aber der Rustdesk-Client auf dem Remote Rechner kann trotzdem nicht connecten. Sobald ich wieder auf die erste IP der Schnittstelle "lan", also die 192.168.1.254 weiterleite, klappt es sofort wieder. Aber trotzdem Danke für den Vorschlag, denn so ist zumindestens ausgeschlossen, daß der Rustdesk-Server sich an der APIPA Adresse stört.

Wenn ich noch Zeit und Lust dazu habe werde ich mal probieren was passiert, wenn ich den Rustdesk-Server zur Probe mal auf dem PC laufen lasse und dort der Netzwerkkarte zwei IPs zuweise. Denn dort kann ich ja per Wireshark besser nachvollziehen, ob die Connectversuche von außen ankommen oder nicht.

[fda77]

Wie gesagt, AVM hat das grosse Problem dass nicht wie bei einem normalen Linux geroutet wird!. Es muss jeder Kleinigkeit ein die closed-source Daemons nachgebaucht werden statt renomierte open source Software zu verwenden. Daher wird es wohl auch ni Vlan geben.
Im speziellen neue IPs fürs lan-interface: Die werden von Zeit zu Zeit von AVM gelöscht! Zb bei einem Reconnect der Internetverbindung. Daher würde ich das lassen...

[MatrixUser]

Ich habe mir eben mal ein Image mit dem Paket tcpdump erzeugt. Damit sollte ich ja feststellen können, ob die Connect-Versuche des Clients von "außen" überhaupt auf der IP 169.254.1.1 ankommen, wenn eine solche Weiterleitung eingerichtet wurde. Sollte dies der Fall sein und der rustdesk-server nicht darauf reagieren wäre klar gestellt, daß beim rustdesk-server selbst irgend etwas "falsch" läuft.

[fda77]

Wenns bei anderen geht, warum sollte es bei dir anders sein?
Mach doch lieber mal ein normales, compilierbares rust Package für freetz, dann könnte ich das auch andere ausprobieren.

Davon abgesehn, mit AVMs PacketAccelerator werden Daten am Kernel vorbei geleitet und du siehst sie nicht

[MatrixUser]

Leider kenne ich mich nicht gut genug in Programmierung aus, sonst hätte ich schon probiert ein solches Paket zu machen. Zudem können die Compiler von freetz-ng afaik nicht mit der Programmiersprache Rust umgehen.

Hinzu kommt, daß die fertigen Binaries nur für arm7 CPUs zur Verfügung stehen und zudem die FB7690 die einzige arm Box ist, welche genug internen Speicher hat, um den rustdesk-server laufen zu lassen. Für eine 7530 mußte ich damals tricksen und die Binaries auf einen USB-Stick auslagern, damit ich den Server überhaupt nutzen konnte.

[manfred-mueller]

Aus den von fda77 genannten, nachvollziehbaren, Gründen habe ich das pr geschlossen.
...es gab einen Grund dafür, dass es ursprünglich nur ein patch und kein pr gab ;-)

[manfred-mueller]

...ich werde mal in den Tiefen meiner Repo-Sicherungen nach den Skripten für ultravncrepeater suchen, welchen ich seinerzeit in FluxFlux benutzt habe. Der ist klein und sollte auch auf einer Fritze laufen.

[MatrixUser]

Bevor ich angefangen habe Rustdesk zu verwenden habe ich auch oft UltraVNC genutzt. Das Problem dabei ist aber, daß man dazu normalerweise bei demjenigen, den man per Fernwartung unterstützen will vorab einen dyndns-Account sowie ein Portforwarding anlegen muß, so daß UltraVNC für die "schnelle Hilfe" nicht so optimal ist. Desweiteren scheint mir subjektiv betrachtet Rustdesk deutlich performanter zu sein als UltraVNC.

Zum anderen ist der rustdesk-server ja sowohl ein Rendevous-, als auch ein Relayserver. Wenn ich das richtig verstehe, vermittelt der Rendevous-Server wenn möglich eine direkte Verbindung zwischen zwei Klienten und leitet den Traffic nur dann über den Relayserver, wenn eine Direktverbindung wegen NAT-Problemen nicht möglich ist. Im Gegensatz dazu scheint mir der UltraVNC Repeater immer als Relayserver zu fungieren, oder habe ich da etwas falsch verstanden ?

[manfred-mueller]

Ich habe die Kombination ultravncrepeater/ultravnc-client jahrelang beruflich genutzt, befor ich auf teamviewer gewechselt bin.
Es sollte einwandfrei funktionieren, die myfritz-Adresse der Fritzbox, auf der der repeater läuft, im quicksupport-client einzutragen.
Da ist auf kein Portforwarding (mehr) oder andere Konfiguration erforderlich. Genau für diesen Zweck ist der repeater.
Auf der Fritze müssen dann nur ports 5900 und ggf. 5500 geöffnet werden.

[MatrixUser]

Der Repeater würde bei mir gegebenenfalls auf der FB laufen und ich habe ja eine dyndns-adresse. Aber auf den zu betreuenden PCs müßte dann der UltraVNC erst so konfiguriert werden, daß meine Box als Repeater genutzt werden soll. Und dies übersteigt die IT-Fähigkeiten dieser Personen dann teilweise schon, während es (unter Windows) recht einfach ist, diesen Personen einen vorkonfigurierten Rustdesk-Clienten zukommen zu lassen. Desweiteren würde bei Einsatz des UVNC-Repeaters der gesamte Traffic immer über meinen Internetanschluß laufen, weil soweit ich es richtig verstehe keine Direktverbindung vermittelt werden kann. Dafür gab es früher mal ein "Nat 2 Nat" Plugin für den UVNC, welches aber eingestellt wurde. Daher werde ich erstmal bei Rustdesk bleiben.

Ich überlege allerdings, dem Programmierer des Rustdesk-Servers den Vorschlag zu machen, die binaries des Servers optional an eine feste IP-Adresse zu binden statt auf allen verfügbaren Interfaces zu lauschen. Damit könnte ich dann testen ob der Server einwandfrei läuft, wenn er nur an die 169.254.1.1 gebunden wird.

[manfred-mueller]

Siehe #1103

[manfred-mueller]

...auf den zu betreuenden PCs müßte dann der UltraVNC erst so konfiguriert werden, daß meine Box als Repeater genutzt werden soll

Eben nicht. Deswegen hatte ich Quicksupport-Client geschrieben. Der ist vorkonfiguriert mit der Repeater-IP und braucht nur vom Benutzer des zu betreuenden PCs heruntergeladen und/oder gestartet zu werden.

...während es (unter Windows) recht einfach ist, diesen Personen einen vorkonfigurierten Rustdesk-Clienten zukommen zu lassen.

Genau das macht der Quicksupport-Client für UVNC ;-)