rustdesk-server
rustdesk-server copied to clipboard
Unconnectability of multiple IPv6 addresses.
Describe the bug When the self-host server is in possession of multiple IPv6 addresses, the server seems to only accept requests to access its specific addresses from the Internet.
Describe the environment Self-host server version: binary release of 1.1.11-1 (both Linux and Windows) Client version: both 1.2.7 and 1.3.0 OS versions: Windows 10 1909 and Ubuntu 22.04.3
How to Reproduce the bug
- When the IPv6 Privacy Extension Protocol is turned on, there will be two IPv6 addresses, and neither the Windows server nor the Linux server will be able to access their primary (non-temporary) IPv6 address from the extranet (meaning the non-LAN for IPv6), and TCP ZeroWindow, RST, Retransmission, Dup ACK, Out-Of-Order packets will appear , followed by: ‘Not ready, please check network connection’. On LAN access there are no ZeroWindow packets, there are a few other packets, but they do not affect the connection. ~~Under Windows, even when accessing the temporary IPv6 address from the extranet, it seems to be less stable; Linux also has some problems, but it looks like Linux is more stable than Windows.~~ After retesting, if all devices are connected to the temporary IPv6 address, there is no problem.
- After turning off the IPv6 Privacy Extension Protocol, all devices can connect normally with full functionality when accessing the server's primary IPv6 address.
- Afterwards, I manually assigned an additional IPv6 address and found that only requests sent to the primary address are received by the server, and the other manual address is not accessible. However the manually assigned address is not a temporary address and is also accessible and can be received by the client.
- The client will receive requests from any address to any host IP address (enabling direct IP access). The client seems to be listening on the specified port of any IP address and processing it at the same time, which may not be the case on the server side.
- Whether client or server, any address on the LAN will be processed. It's just not feasible for an external network to access the server's ‘non-primary IPv6 address’ (the temporary IPv6 address seems to be treated as the primary address when Privacy Extension is enabled).
- Both Windows and Linux have this problem and I have to enable ALWAYS_USE_RELAY=Y to ensure a successful connection between the clients, otherwise it seems to try to punch holes in IPv4?
Expected behavior All of the host's IPv6 addresses should be available for extranet access to the server, because it's not like it's an IPv6 protocol issue. The client can do it, and the server should do it too.
Additional context Also, the appearance of ‘Not ready, please check network connection’ is not completely unusable, it just can't be controlled, but it is possible to control devices that don't have this problem (e.g. devices that are on the LAN).
The same applies if there are several different network adapters, each with an IPv6 address. Note: In some cases it seems to be possible to connect successfully to a ‘non-primary IPv6 address’ a few times. It may not work (it just says ‘ready’, but can't actually be connected), or it may work, but may not work the next to try to connect.
The previous Issues were not the same as my problem, so I created a new one, which I think is a server bug and not a problem with the IPv6 protocol or a problem with my operation. If there is a problem with my operation, please point it out.
Please don't close the question if you need more information, I will reply if I have time.