Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ports configurable and possibility to reverse proxy #191

Open
sebastianschauenburg opened this issue Feb 14, 2023 · 9 comments
Open

Ports configurable and possibility to reverse proxy #191

sebastianschauenburg opened this issue Feb 14, 2023 · 9 comments
Labels
enhancement New feature or request

Comments

@sebastianschauenburg
Copy link

Connecting to a selfhosted RustDesk server is not possible, when behind certain network routers / firewalls. Probably all ports are blocked for outgoing traffic, except for a couple of 'well known' ports (usually 53/80/443 and the such). This affects multiple environments (example: guest wifi at several establishments)
Bonus: If you have a network firewall which does Deep Packet Inspection additional challenges will probably pop up.

Currently the TCP (21115-21119) and UDP port (21116) seem to be hardcoded. It would be great to make them configurable.
Bonus: it would be excellent if everything would have the option to be put behind a reverse proxy on port 443 (e.g. as yet another virtual host on an apache server) . This would probably solve the issue above as well, but seems like a lot more work (to be honest, I currently still do not really understand how rustdesk works internally, but that is my own shortcoming)

Of course I can edit the source code, change the port numbers and compile everything myself. That might work and get it working for now, but is not the 'best' solution, so I wanted to file a proper feature request.

Some github issues which are a tiny bit similar, but less actionable (imho) from a software project standpoint. But I wanted to reference them for completeness: 185 , 80 and 46.

P.S. thank you very much for creating/maintaining/developing this excellent project

@sebastianschauenburg sebastianschauenburg added the enhancement New feature or request label Feb 14, 2023
@sebastianschauenburg
Copy link
Author

Have been pondering about this (with my limited knowledge), but maybe it would be possible for the TCP connections to use a URL with a certain suffix ( /api /hbbs etc.). This can then perhaps enable reverse proxying and also enable SSL, because that can be handled by the webserver.

Docs from the most popular webservers about reverse proxy:

Found the port explanation in src/utils.rs:

doctor_tcp(server_ip_address, "21114", "API");
doctor_tcp(server_ip_address, "21115", "hbbs extra port for nat test");
doctor_tcp(server_ip_address, "21116", "hbbs");
doctor_tcp(server_ip_address, "21117", "hbbr tcp");
doctor_tcp(server_ip_address, "21118", "hbbs websocket");
doctor_tcp(server_ip_address, "21119", "hbbr websocket");

@paspo
Copy link
Contributor

paspo commented Feb 22, 2023

You're supposing an HTTP connection (where URLs and SSL applies), which is not the case.

@NBonfattiMW
Copy link

NBonfattiMW commented May 5, 2023

i think you'd want to use a subdomain instead of a suffix, and then use a load balancer that can handle TCP connections. For example, Traefik ingress on kubernetes has custom IngressRouteTCP resource that you can match routes via the subdomain. But i'm not sure how you'd handle the multiple mapped ports in that case, ive only ever used it for single port connections 🤔. And UDP can't match against the host SNI, so you can only have one route per entrypoint for the UDP connection.

@lonix1
Copy link

lonix1 commented Jul 16, 2023

Agreed, would be preferable to customise ports that make sense in our environment.

The user-facing hardcoding is here. Easiest fix is to set the ports via environment variables in the compose file. UPDATE: actually they can be changed in docker using 31115:21115, etc. The problem is the clients use the hardcoded ports.

@h3x4d3c1m4l
Copy link

My selfhosting setup uses Traefik for HTTP and TCP termination. However I have no clue which the ports need termination and whether this is supported using the Docker example. Any clues? Happy to help out with some documentation if I can get it to run using this setup.

@MichaelUray
Copy link

There is a post which shows the use behind a Traefik reverse proxy in Docker:
rustdesk/rustdesk#3177 (comment)

@SoniaMalki
Copy link

Following. For the same concern, some school network close access to the port needed to run the server. A reverse proxy could be a solution

@paspo
Copy link
Contributor

paspo commented Feb 13, 2024

Following. For the same concern, some school network close access to the port needed to run the server. A reverse proxy could be a solution

If the school closed access to every port except the usual (80 http, 443 https, 53 dns), your options are very limited.

hbbs needs 3 different ports: 21115, 21116, 21118.
hbbr needs 2 different ports: 21117, 21119.

Even if you set different dns for hbbr and hbbs (say relay.mydomain.com and rustdesk.mydomain.com) you can still forward only one port from port 443, but then comes the bad news.

For hbbs ports are defined like this:

  • the default port is 21116, you can override that via the PORT environment variable or the --port command line argument
  • NAT test port is the default port -1
  • websocket port is the default port +2

For hbbr, ports are defined like this:

  • the default port is 21117, you can override that via the PORT environment variable or the --port command line argument
  • websocket port is the default port +2

Do you have control on the school's network?

@fanthos
Copy link

fanthos commented Jan 17, 2025

It would be great if I can access all services using one TCP port over http(websockets) so I can make all services behind reverse proxy and share port. If UDP not working, I can access all services using same TCP port and it could share with other service.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

8 participants