Rustdesk S6 Installation - Problem

[mj084]

Servus,

ich klinke mich mal hier mit ein

Habe zwar kein Installationsproblem mit dem S6 Image, jedoch gibt es Probleme bei der Benutzung.

Ich habe Rustdesk via Aufgabenplaner installieren lassen:

docker run -d --name rustdesk \
-v /volume1/docker/rustdesk/data:/data \
-p 21115:21115 -p 21116:21116 \
-p 21116:21116/udp -p 21117:21117 \
-p 21118:21118 -p 21119:21119 \
-e RELAY=aaa.bbb \
-e ENCRYPTED_ONLY=1 \
--restart always \
rustdesk/rustdesk-server-s6:latest

Zusätzlich habe ich im Router und der Synology Firewall die entsprechenden Regeln gesetzt.

Im Rustdesk-Client habe ich dann auch den ID-Server und den Key eingetragen und ich bekomme den grünen Punkt, nur wenn ich mich mit einem Client (der als online erkannt wird) verbinden möchte, kommt die Verbindung nicht zustande - die Passwortabfrage erscheint einfach nicht.

Mit der 2-Containerinstallation von https://mariushosting.com/how-to-install-rustdesk-on-your-synology-nas/

klappt es dagegen problemlos.

Ist es eigentlich normal, dass hier der Ordner "rustdeskhbbr" komplett leer bleibt?

Freue mich auf eure Antworten

 

[plang.pl]

Willkommen hier im Forum!
Funktioniert es intern über die IP? Steht was im Container-Log?

 

[mj084]

@plang.pl

Danke

Ob es über die interne IP funktioniert hätte kann ich nicht mehr sagen, da ich momentan die andere Variante installiert habe...

Ist das denn mit dem leeren rustdeskhbbr Ordern normal?

 

[plang.pl]

Von dem Ordner ist nirgends die Rede. Welchen meinst du genau? Der Ordner, der auf "/data" gemountet wird, sollte auf dem Host auf jeden Fall nicht leer sein

 

[mj084]

@plang.pl

Ich habe wie gesagt die 2-Containerinstallation von https://mariushosting.com/how-to-install-rustdesk-on-your-synology-nas/ aktuell am Laufen, dort gibt es diesen Ordner, und dieser ist jedoch leer...

Habe jetzt nochmal die S6-Variante installiert, im Router nichts geändert, in der Syno-Firewall die IP's und Apps angepasst und mein Client zeigt bereit an und erkennt auch die entfernten Clients als online.

Im Containerlog ist dann auch der Zugriffsversuch zu sehen:

[2024-02-17 15:20:41.813602 +00:00] INFO [src/relay_server.rs:441] New relay request 423384ba-073e-4ba5-a040-9f7743233dd9 from [::ffff:172.31.0.1]:48815

Ist doch irgendwie verhext...

EDIT:

Es liegt am Paramater "ENCRYPTED_ONLY=1" - setze ich die Variable auf 0, dann kommt die Verbindung zustande:

[2024-02-17 15:34:03.954365 +00:00] INFO [src/relay_server.rs:425] Relayrequest 3e988101-a91b-40a0-8367-919a109b0ff5 from [::ffff:172.31.0.1]:48922 got paired

EDIT2:

Blockade im Kopf gefunden: Wenn ENCRYPTED_ONLY=1 gesetzt ist, muss ich natürlich den PublicKey auch wieder beim entfernten Client angeben

"Problem" solved

 

[plang.pl]

Genau so ist es. Das hatten wir hier schonmal. Das ist tatsächlich bei der 2 Contianer-Version in der Form nicht der Fall. Hätte ich auch gleich drauf kommen müssen, dass schon wieder dieser Parameter das Problem ist. Aber schön, dass es nun gelöst ist und danke für die Rückmeldung.

 

[mj084]

Gerne

Dann muss dort die Übertragung unverschlüsselt ablaufen wenn man den PublicKey im entfernten Client nicht hinterlegt - da ich ja so eben an die Maschine rankam und fix den Key eintragen konnte

 

[plang.pl]

Ich hab den Key bei mir überall eingetragen.
Wenn die Verbindung über VPN oder Reverse Proxy mit SSL läuft, dann braucht man den Key nicht und die Verbindung ist dennoch verschlüsselt.

 

[mj084]

@plang.pl

Was meinst du genau mit Reverse Proxy mit SSL?
Müsste man dann eine Subdomain auf den Container zeigen lassen?

 

[plang.pl]

Ja, so mache ich das. Subdomain löst auf den Reverse Proxy auf, der Anfragen via https auf 443 annimmt und an den Container weitergibt

 

[mj084]

Da man ja bei Synology nur einen Port für den ReverseProxy angeben kann, welcher muss da genommen werden?

Einen Vorteil bringt es jedoch nicht, wenn man die Übertragung eh schon verschlüsselt hat, die Ports müssen ja trotzdem im Router offen bleiben, korrekt?

 

[plang.pl]

Ja klar, die Ports müssen offen. Aber mit dem Reverse Proxy hast du nen Vorteil: Es muss nur ein Port offen sein. Da nimmt man normal den 443. Dann muss man in der URL nämlich den Port nicht mit angeben

 

[mj084]

Moment, im Router muss nur 443 offen sein?

Könntest du dein Config mal als Beispiel hier anhängen?

 

[alexhell]

Wenn du alles über den Reverse Proxy laufen lässt dann ja

 

[mj084]

Wenn du alles über den Reverse Proxy laufen lässt dann ja

Dann würde es Sinn machen

Eine Beispielkonfiguration, gerade in Verbindung mit den Portfreigaben einer Fritz!Box würden mich wirklich interessieren

Edit: Damit meinte ich natürlich @plang.pl

 

[plang.pl]

Du machst nur 443 im Router auf. Der Reverse Proxy entscheidet dann je nach Subdomain, wo die Anfrage intern weitergegeben wird.

 

[mj084]

Dies ist schon klar, bloß auf welchen Port des Containers zeigt der ReverseProxy für Rustdesk dann intern?

Port 443 TCP ist im Router extern offen und zeigt auf Port 443 vom NAS...

Dort ist ein Eintrag im Reverseproxy mit der Subdomain für Rustdesk - nur funktioniert es so nicht.

Die Subdomain ist nur ein CNAME Eintrag beim DNS-Provider, welche auf den DNS-Namen zeigt...

 

[plang.pl]

https://rustdesk.com/docs/en/self-host/rustdesk-server-oss/docker/
So wie ich das sehe, ist es 21117 für den Relay-Server.

 

[mj084]

Klappt jedoch auch nicht :/

Wie schaut denn deine funktionierende Config aus - laut Signatur hast du ja auch eine Fritz!Box

 

[plang.pl]

Ich hab nochmal nachgelesen. Anscheinend geht das nicht über einen Reverse Proxy. Bzw. schon aber nur mit einem "Stream". Das kann der RP der DS aber nicht. Ich hatte das so mal am Laufen. Vielleicht bekomme ich es nochmal hin. Moment ich teste...