Files
firezone/rust/relay
Gabi 8967b53170 Feat/connlib full flow (#1722)
With this PR the full control-plane message flow is working.

Meaning that if you do:

```
docker compose up -d
docker compose exec -it client "ping 172.20.0.2" # will fix this IP later
```

Messages start flowing to gateway. The gateway still not correctly
forwards the messages to the resource since masquerading is still not
working, although I suspect there might be an additional problem. Will
fix this in my next PR along with a README on how to test this whole
flow.

This PR also fixes how we sent the stamp secret to the gateway from the
relay, but I still see some warnings in the webrtc that I'm sure that
are due to a mismatch between how webrtc-rs and the relay handle
messages (The most important being `bind() failed: unexpected response
type`), I will take a look at that and a way to test that the flow works
when:
1. hole-punching is available
2. through relay when it's not
Since the flow right now works without hole-punching or relay since the
gateway is in the same network in the docker compose.
2023-07-03 19:25:37 +00:00
..
2023-07-03 19:25:37 +00:00
2023-06-15 19:59:53 +02: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 a detailed help text and available configuration options, run cargo run --bin relay -- --help.

Docker

There is a docker image one directory up from this README: Dockerfile. The Rust binary itself does not include any signal handling, thus you need to run the container with --init if you want to be able to CTRL+C the running container.

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.