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

Files

Thomas Eizinger 932f6791fb fix(phoenix-channel): lazily create backoff timer (#7414 )

Our `phoenix-channel` component is responsible for maintaining a
WebSocket connection to the portal. In case that connection fails, we
want to reconnect to it using an exponential backoff, eventually giving
up after a certain amount of time.

Unfortunately, the code we have today doesn't quite do that. An
`ExponentialBackoff` has a setting for the `max_elapsed_time`.
Regardless of how many and how often we retry something, we won't ever
wait longer than this amount of time. For the Relay, this is set to
15min. For other components its indefinite (Gateway, headless-client),
or very long (30 days for Android, 1 day for Apple).

The point in time from which this duration is counted is when the
`ExponentialBackoff` is **constructed** which translates to when we
**first** connected to the portal. As a result, our backoff would
immediately fail on the first error if it has been longer than
`max_elapsed_time` since we first connected. For most components, this
codepath is not relevant because the `max_elapsed_time` is so long. For
the Relay however, that is only 15 minutes so chances are, the Relay
would immediately fail (and get rebooted) on the first connection error
with the portal.

To fix this, we now lazily create the `ExponentialBackoff` on the first
error.

This bug has some interesting consequences: When a relay reboots, it
looses all its state, i.e. allocations, channel bindings, available
nonces etc, stamp-secret. Thus, all credentials and state that got
distributed to Clients and Gateways get invalidated, causing disconnects
from the Relay. We have observed these alerts in Sentry for a while and
couldn't explain them. Most likely, this is the root cause for those
because whilst a Relay disconnects, the portal also cannot detect its
presence and pro-actively inform Clients and Gateways to no longer use
this Relay.

2024-11-29 20:19:11 +00:00

src

fix(phoenix-channel): lazily create backoff timer (#7414 )

2024-11-29 20:19:11 +00:00

Cargo.toml

ci: lint Rust dependencies using cargo deny (#7390 )

2024-11-22 00:17:28 +00:00

README.md

Allow data plane configuration at runtime (#2477 )

2023-10-30 23:46:53 -07:00

README.md

gateway

This crate houses the Firezone gateway.

Building

You can build the gateway using: cargo build --release --bin firezone-gateway

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

Running

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

Generate a new Gateway token from the "Gateways" section of the admin portal and save it in your secrets manager.
Ensure the FIREZONE_TOKEN=<gateway_token> environment variable is set securely in your Gateway's shell environment. The Gateway requires this variable at startup.
Set FIREZONE_ID to a unique string to identify this gateway in the portal, e.g. export FIREZONE_ID=$(uuidgen). The Gateway requires this variable at startup.
Now, you can start the Gateway with:

firezone-gateway

If you're running as a non-root user, you'll need the CAP_NET_ADMIN capability to open /dev/net/tun. You can add this to the gateway binary with:

sudo setcap 'cap_net_admin+eip' /path/to/firezone-gateway

Ports

The gateway requires no open ports. Connections automatically traverse NAT with STUN/TURN via the relay.