From Reachability to Trust: Reading One RustDesk Session

RustDesk's connection design becomes useful when it is read as one chain rather than as separate networking and cryptography features. This checkpoint connects the session's four decisive questions: was the intended peer discovered, did a direct or relayed route carry the stream, was the stream bound to the intended identity, and were its bytes protected? The reader should be able to use that chain to interpret a failed connection without confusing a missing route with a failed authentication—and to see why a secure channel still stops short of permission to control the endpoint.

One session, four questions

Start with a controller selecting a peer ID. That action does not yet locate a machine in the ordinary Internet sense. The controlled endpoint must be registered with rendezvous, and the coordinator must be able to return enough information for the controller to try a route. If the ID does not exist or the peer is offline, the session has not reached the transport stage. It is a discovery or availability problem, not evidence that the cryptographic handshake rejected a valid peer.

If a peer is available, rendezvous turns the request into candidates. A local address may serve two devices on the same intranet. UDP or TCP punching may work through compatible address translation. IPv6 may provide another direct possibility. WebRTC ICE may discover a direct pair or a TURN-relayed pair. A proxy or WebSocket policy may force the classic path through a RustDesk relay while still allowing WebRTC's separate ICE machinery to attempt direct connectivity. The route is a choice shaped by topology and policy, not a permanent property of the peer.

Only after one of those candidates produces a stream does it make sense to ask how the bytes arrived. A direct TCP, UDP, IPv6, or WebRTC result says that the endpoints found a peer-to-peer path under the current conditions. A relay result says that the endpoints found a reachable bridge. The distinction matters for latency, dependence, and diagnosis, but neither result alone says that the other endpoint is the intended machine or that the user has permission to control it.

The next question belongs to identity. RustDesk can verify a signed rendezvous exchange against a configured public key, then verify peer identity material associated with the requested RustDesk ID. For ordinary framed transports, the endpoints establish a symmetric session key and protect subsequent frames. For WebRTC, DTLS already encrypts the data channel, but RustDesk additionally binds the DTLS fingerprint to the signed peer identity when a trusted identity is available. The sequence connects the route to a named endpoint instead of treating any encrypted responder as acceptable.

The full diagnostic path can be summarized like this:

flowchart LR A["Peer ID lookup"] --> B{"Peer discovered?"} B -- "no" --> F1["Discovery or availability failure"] B -- "yes" --> C["Candidate routes"] C --> D{"Direct or relay stream?"} D -- "direct" --> E["Peer-to-peer transport"] D -- "relay" --> L["Relayed transport"] E --> V{"Identity verified?"} L --> V V -- "no" --> F2["Identity or handshake failure"] V -- "yes" --> S["Encrypted, peer-bound channel"] S --> P["Authorization still pending"]

The arrows carry a useful distinction.