mirror of https://github.com/outbackdingo/firezone.git synced 2026-01-27 18:18:55 +00:00

Files

Jamil ff1c0b950a Add make version command to set version in components (#2215 )

Fixes #2213 

This will allow us to fetch the actual Firezone version that's in use
from within the language runtimes themselves without resorting to an
external mechanism to do so. This is useful in connlib for example when
selecting the Portal API to use with `X-Firezone-API-Version`, and
useful in log printing.

Since platforms enforce semantic version, I propose the convention:

`1.20231001.34` where MAJOR is `1` for Firezone 1.0, MINOR is our API
version, and PATCH is the release of that API version that is published
on the repo.

Given this system, publishing a release would consist of:

1. Edit `Makefile` to set the patch and minor versions appropriately
depending on whether there are breaking portal API changes.
2. `make version`
3. `git add .; git commit; git push` -- this opens a PR with the new
version numbers. In this PR we can discuss whether to stop-ship or go.
4. PR merged, release is drafted and deployed to staging with the new
tag and version numbers
5. build artifacts are uploaded to drafted release, everything is tagged
and versioned appropriately without having to introduce another commit
6. If all looks good, publish release

2023-10-03 15:22:02 +11:00

examples

fix(relay): wait for channel binding in smoke test script (#1853 )

2023-08-04 03:17:20 +00:00

proptest-regressions/server

feat(relay): add smoke test script (#1834 )

2023-07-31 20:13:27 +00:00

src

refactor(portal): Don't pin session token to user_agent or remote_ip (#2195 )

2023-09-30 07:40:57 -07:00

tests

refactor(portal): Don't pin session token to user_agent or remote_ip (#2195 )

2023-09-30 07:40:57 -07:00

Cargo.toml

Add make version command to set version in components (#2215 )

2023-10-03 15:22:02 +11:00

README.md

docs(relay): bring README.md up to date (#1718 )

2023-07-04 21:01:32 +00:00

run_smoke_test.sh

feat(relay): remove LISTEN_IPX_ADDR parameters (#1922 )

2023-08-18 09:44:41 +00:00

README.md

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.