-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Comments
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
|
You're supposing an HTTP connection (where URLs and SSL applies), which is not the case. |
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. |
Agreed, would be preferable to customise ports that make sense in our environment.
|
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. |
There is a post which shows the use behind a Traefik reverse proxy in Docker: |
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. 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:
For hbbr, ports are defined like this:
Do you have control on the school's network? |
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. |
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
The text was updated successfully, but these errors were encountered: