Files
firezone/rust/relay
Andrew Dryga a211f96109 feat(portal): Broadcast state changes to connected clients and gateways (#2240)
# Gateways
- [x] When Gateway Group is deleted all gateways should be disconnected
- [x] When Gateway Group is updated (eg. routing) broadcast to all
affected gateway to disconnect all the clients
- [x] When Gateway is deleted it should be disconnected
- [x] When Gateway Token is revoked all gateways that use it should be
disconnected

# Relays
- [x] When Relay Group is deleted all relays should be disconnected
- [x] When Relay is deleted it should be disconnected
- [x] When Relay Token is revoked all gateways that use it should be
disconnected

# Clients
- [x] Remove Delete Client button, show clients using the token on the
Actors page (#2669)
- [x] When client is deleted disconnect it
- [ ] ~When Gateway is offline broadcast to the Clients connected to it
it's status~
- [x] Persist `last_used_token_id` in Clients and show it in tokens UI

# Resources
- [x] When Resource is deleted it should be removed from all gateways
and clients
- [x] When Resource connection is removed it should be deleted from
removed gateway groups
- [x] When Resource is updated (eg. traffic filters) all it's
authorizations should removed

# Authentication
- [x] When Token is deleted related sessions are terminated
- [x] When an Actor is deleted or disabled it should be disconnected
from browser and client
- [x] When Identity is deleted it's sessions should be disconnected from
browser and client
- [x] ^ Ensure the same happens for identities during IdP sync
- [x] When IdP is disabled act like all actors for it are disabled?
- [x] When IdP is deleted act like all actors for it are deleted?

# Authorization
- [x] When Policy is created clients that gain access to a resource
should get an update
- [x] When Policy is deleted we need to all authorizations it's made
- [x] When Policy is disabled we need to all authorizations it's made
- [x] When Actor Group adds or removes a user, related policies should
be re-evaluated
- [x] ^ Ensure the same happens for identities during IdP sync

# Settings
- [x] Re-send init message to Client when DNS settings change

# Code
- [x] Crear way to see all available topics and messages, do not use
binary topics any more

---------

Co-authored-by: conectado <gabrielalejandro7@gmail.com>
2024-02-01 11:02:13 -06: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 relay using: cargo build --release --bin firezone-relay

You should then find a binary in target/release/firezone-relay.

Running

The Firezone Relay supports Linux only. To run the Relay binary on your Linux host:

  1. Generate a new Relay token from the "Relays" section of the admin portal and save it in your secrets manager.
  2. Ensure the FIREZONE_TOKEN=<relay_token> environment variable is set securely in your Relay's shell environment. The Relay expects this variable at startup.
  3. Now, you can start the Firezone Relay with:
firezone-relay

To view more advanced configuration options pass the --help flag:

firezone-relay --help

Ports

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 token, the relay will connect to the Firezone portal 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.