Fritzbox als rustdesk-server?

[DerManfred]

Sehr gerne

Bedeutet für mich, daß die selbst-vergebene IP-Adresse der Fritzbox ausgelesen und automatisch übernommen wird.

AVM_RULES_IP=${AVM_RULES_IP:-$(grep "fritz.box" /etc/hosts | awk '{print $1}')}

 

[f-user]

Vollzitat gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ entfernt by stoney

Ja, habe ich gesehen. Da ich aber nicht programmieren kann (allenfalls bestehenden Code per trial & error modifizieren...), hätte ich den Code selbst natürlich nie schreiben können..

 

[NanoBot]

Hi,

aus der Diskussion auf github ergab sich, daß das Paket avm-rules nicht so verändert werden kann / sollte, daß eine andere Ziel-IP als 169.254.1.1 genutzt wird, weil es sonst größere Probleme geben könnte. Soweit ich es richtig verstanden habe ist der Grund, daß das Timing des Addons um den pcplisten Befehl alle 120s zu wiederholen nur dann problemlos funktionieren kann, wenn die Fritz!Box von sich aus keine Weiterleitungen auf die Ziel-IP nutzt. Dies ist bei der IP 192.168.x.x aber immer der Fall, weil der für die Telefonie genutzte Port 5060 immer auf diese IP der Box weiter geleitet werden muß. Somit bleibt im Moment nur die bisherige Methode, die von Rustdesk benötigten Ports mit einem Script, welches per crontab zu jeder zweiten vollen Minute aufgerufen, auf die 192.168.x.x weiter zu leiten.

Außerdem habe ich eine Vermutung, wieso der rustdesk-server nicht funktioniert, wenn man die Weiterleitung auf 169.254.1.1 nutzt. Aus diesem Thread auf github geht hervor, daß der Server Probleme damit hat, wenn er an zwei Interfaces mit verschiedenen IPs gebunden ist: https://github.com/rustdesk/rustdesk-server/issues/447
Dort kommen UDP Pakete über das zweite Interface und dessen IP rein. Die abgehenden UDP Pakete nutzen dagegen die IP des ersten Interfaces.

Nun haben wir auf der Fitz!Box ja eine ähnliche Situation: Das gleiche Interface, nämlich lan bzw. lan:0, hat zwei IP-Adressen. Und meine Vermutung ist, daß der rustdesk-server eingehende (UDP) Pakete unabhängig davon, ob diese an die 192.168.x.x oder die 169.254.1.1 gerichtet waren immer unter Verwendung der ersten IP (192.168.x.x) beantwortet. Wenn die Weiterleitung auf die erste IP erfolgt, funktioniert NAT-Traversal problemlos. Ist die Weiterleitung dagegen auf 169.254.1.1 gerichtet und der Server beantwortet die Pakete unter Nutzung der 192.168.x.x haut das NAT-Traversal nicht mehr hin, so daß der rustdesk-server nicht von "außen" erreichbar ist.

Um dieses von mir vermutete Problem zu verifizieren bräuchte es die Option die Komponenten des rustdesk-servers gezielt nur an eine bestimmte IP-Adresse zu binden, welche es derzeit aber nicht gibt. Sollte sich meine Vermutung bewahrheiten müßte der rustdesk-server dahingehend verändert werden, das auf eingehende (UDP) Pakete immer mit der gleichen IP geantwortet wird, auf welcher die Pakete reingekommen sind.

 

[f-user]

Die Dokumentation von rustdesk(-server) könnte auch besser sein... In den FAQ steht, daß man eine Konfigurationsdatei verwenden könne - spärlich beschrieben, statt konkretes Beispiel. Auch eine .env-Datei soll funktionieren. Bei meinen Tests leider nicht. Bei den docker-Versionen funktioniert das wohl, aber bei den normalen Binärdateien scheint es nicht zu funktionieren.
Immerhin kann man hbbs per Ausführungsbefehl im Skript eine IP-Adresse mitgeben. Bei hbbr geht das nicht. Ob hbbr sich dann einfach nach hbbs richtet und dessen IP verwendet? Wie auch immer - wenn man hbbs auf die 169.254.1.1 hinzielt, funktioniert es nicht. Wenn man die andere IP-Adresse oder keine vorgibt, funktioniert es.

Mir ist schleierhaft, warum rustdesk-server mit der einen IP-Adresse funktionieren sollte, mit der anderen aber nicht. Mir scheint das eher ein "Problem" der Fritzbox zu sein, die diese beiden IP-Adresse scheinbar unterschiedlich behandelt.

 

[NanoBot]

So wie ich das sehe ist es nicht der rustdesk-server allein, sondern das Zusammenspiel zwischen dem Server und der FB, welches das Problem verursacht:

Ein Rustdesk-Client außerhalb meines eigenen LANs mit der fiktiven Adresse "rustdeskclient.foo.com" schickt ein UDP-Paket an meine fiktive kanonische Adresse "rustdeskserver.fooo.com" Port 21116. Dieses Paket wird je nach Konfiguration entweder an die 192.168.x.x oder an die 169.254.1.1 weiter geleitet indem die Ziel-IP umgeschrieben und ein Eintrag in der NAT-Tabelle gemacht wird.
Der Server will auf diesen Paket antworten. Aufgrund eines in dem oben genannten Ticket vermuteten Bugs nutzt er hierzu aber nicht explizit das Interface und dessen IP-Adresse, auf welchem er das Paket empfangen hat (wie es richtig wäre), sondern sagt lediglich "Sende ein UDP-Paket an die Ziel-Adresse "rustdeskclient.foo.com" und überlässt es dem OS der Fritz!Box die Wahl des Interfaces und somit der Quell-IP. Die Fritz!Box nutzt vermutlich, wenn man es ihr nicht ausdrücklich anders sagt immer das Interface "lan", also die IP-Adresse 192.168.x.x

Wenn das eingehende Paket auf 192.168.x.x forwardet wurde stimmen die Ziel-IP des "genatteten" eingehenden Paketes und die Quell-IP des ausgehenden Paketes überein, wodurch das sogenannte "NAT Traversal" funktioniert. Forwardet man dagegen auf die Ziel-IP 169.254.1.1 und der Server antwortet aber mit der 192.168.x.x als Quell-IP kann der Eintrag in der NAT-Tabelle nicht greifen. Diese vermutete Problematik kann nur bei bei UDP-Paketen auftreten weil UDP ja "stateless" ist. Bei TCP-Verbindungen würde dagegen zuvor ein Socket aufgebaut. Nun steht in den Docs "21116/UDP is used for the ID registration". Der Client sagt dem Server also in regelmäßigen Abständen per UDP-Paket "Ich bin online" und der Server sagt dem Client ebenfalls per UDP Paket "Ok, habe ich verstanden". Kommen diese UDP-Pakete aufgrund des vermuteten NAT-Problems nicht an, kann sich der Client nicht am Server registrieren.

Wenn man den Komponenten des rustdesk-servers ausdrücklich sagen könnte, daß sie sich ausschließlich an eines der beiden interfaces "lan" bzw. "lan:0" bzw. die IP-Adressen 192.168.x.x bzw. 168.254.1.1 binden sollen, könnte man die vermutete Ursache entweder verifizieren oder falsifizieren. Sollte die Vermutung sich bestätigen so müßten die Serverkomponenten so umgeschrieben werden, daß für ausgehende UDP-Pakete immer das gleiche Interface genutzt wird, über welches die Pakete zuvor reingekommen sind. Leider reichen meine Programmierkenntnisse bei weitem nicht aus um in den Sourcen des rustdesk-servers nachzuvollziehen zu können, ob das vermutete Verhalten tatsächlich gegebenen ist, Die maßgebliche Zeile im Code ist gemäß dem Ticket dazu diese hier:
https://github.com/rustdesk/rustdes...6b26344707207cb/src/rendezvous_server.rs#L330

Dieses Verhalten ist nur eine Vermutung meinerseits, weil ich es bisher nicht schaffe aus dem WAN weitergeleitete UDP-Pakete mit tcpdump zu loggen. Da muß ich mich einerseits erstmal einarbeiten. Andererseits funkt mir dort möglichwerweise die "Paketbeschleunigung" der Fritz!Box dazwischen, weshalb ich gestern schon einmal probiert habe diese testweise abzuschalten. Dies hat aber irgendwie nicht funktioniert, nach einem reboot war die Paketbeschleunigung wieder an, obwohl ich sie eigentlich abgeschaltet hatte. Nun kann/will ich aber nicht zu oft neu booten, weil ich das Risiko ASSIA/DLM zu triggern nicht eigehen will.

C.U. Nanobot

 

[PeterPawn]

Das Abschalten der PA gilt - afaik - immer nur bis zum nächsten Reboot oder bis zum Wiedereinschalten, je nachdem, was zuerst kommt.