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

Files

Thomas Eizinger a4a8221b8b refactor(connlib): explicitly initialise Tun (#5839 )

Connlib's routing logic and networking code is entirely platform
agnostic. The only platform-specific bit is how we interact with the TUN
device. From connlib's perspective though, all it needs is an interface
for reading and writing. How the device gets initialised and updated is
client-business.

For the most part, this is the same on all platforms: We call callbacks
and the client updates the state accordingly. The only annoying bit here
is that Android recreates the TUN interface on every update and thus our
old file descriptor is invalid. The current design works around this by
returning the new file descriptor on Android. This is a problematic
design for several reasons:

- It forces the callback handler to finish synchronously, and halting
connlib until this is complete.
- The synchronous nature also means we cannot replace the callbacks with
events as events don't have a return value.

To fix this, we introduce a new `set_tun` method on `Tunnel`. This moves
the business of how the `Tun` device is created up to the client. The
clients are already platform-specific so this makes sense. In a future
iteration, we can move all the various `Tun` implementations all the way
up to the client-specific crates, thus co-locating the platform-specific
code.

Initialising `Tun` from the outside surfaces another issue: The routes
are still set via the `Tun` handle on Windows. To fix this, we introduce
a `make_tun` function on `TunDeviceManager` in order for it to remember
the interface index on Windows and being able to move the setting of
routes to `TunDeviceManager`.

This simplifies several of connlib's APIs which are now infallible.

Resolves: #4473.

---------

Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: conectado <gabrielalejandro7@gmail.com>

2024-07-12 23:54:15 +00:00

src

refactor(connlib): explicitly initialise Tun (#5839 )

2024-07-12 23:54:15 +00:00

Cargo.toml

chore(rust): format Cargo.toml using cargo-sort (#5851 )

2024-07-12 04:57:22 +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.