Files
firezone/rust/relay
Gabi e216a9e69f relay: fix stale nonce error code (#1942)
In the gateway/client we were looking at an error that looked like:

```
firezone-client-1  | 2023-08-23T20:58:50.456400Z ERROR turn::client::relay_conn: fail to refresh permissions: CreatePermission error response (error 401: Unauthorized)    
firezone-client-1  | 2023-08-23T20:58:50.456413Z  WARN turn::client::relay_conn: refresh permissions failed    
```

This was due to a slightly non-compliant behavior on the relay part
where it was responding with a 401 instead of a 438 when a nonce was
stale which is the behavior described by [RFC
5389](https://datatracker.ietf.org/doc/html/rfc5389#section-10.2.2)

This PR should fix this and we should no longer see that refresh
permissions error.
2023-08-24 16:50:54 +00:00
..

relay

This crate houses a minimalistic STUN & TURN server.

Features

We aim to support the following feature set:

  • STUN binding requests
  • TURN allocate requests
  • TURN refresh requests
  • TURN channel bind requests
  • TURN channel data requests

Relaying of data through other means such as DATA frames is not supported.

Building

You can build the server using: cargo build --release --bin relay

Running

For an up-to-date documentation on the available configurations options and a detailed help text, run cargo run --bin relay -- --help. All command-line options can be overridden using environment variables. Those variables are listed in the --help output at the bottom of each command.

The relay listens on port 3478. This is the standard port for STUN/TURN and not configurable. Additionally, the relay needs to have access to the port range 49152 - 65535 for the allocations.

Portal connection

When given a portal endpoint, the relay will connect to it and wait for an init message before commencing relay operations.

Design

The relay is designed in a sans-IO fashion, meaning the core components do not cause side effects but operate as pure, synchronous state machines. They take in data and emit commands: wake me at this point in time, send these bytes to this peer, etc.

This allows us to very easily unit-test all kinds of scenarios because all inputs are simple values.

The main server runs in a single task and spawns one additional task for each allocation. Incoming data that needs to be relayed is forwarded to the main task where it gets authenticated and relayed on success.