mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 10:18:54 +00:00
At the moment, the mapping of proxy IPs to the resolved IPs of a DNS resource happens at the same time as the "authorisation" that the client is allowed to talk to that resource. This is somewhat convoluted because: - Mapping proxy IPs to resolved IPs only needs to happen for DNS resources, yet it is called for all resources (and internally skipped). - Wildcard DNS resources only need to be authorised once, after which the client is allowed to communicate with any domain matching the wildcard address. - The code that models resources within `ClientOnGateway` doesn't differentiate between resource types at all. With #6461, the authorisation of a resource will be completely decoupled from the domain resolution for a particular domain of a DNS resource. To make that easier to implement, we re-model the internals of `ClientOnGateway` to differentiate the various resource types. Instead of holding a single vec of addresses, the IPs are now indexed by the respective domain. For CIDR resources, we only hold a single address anyway and for the Internet Resource, the IP networks are static. This new model now implies that allowing a resource that has already been allowed essentially implies an update and the filters get re-calculated.
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_IDto 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.