mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 10:18:54 +00:00
b11adfcfe4
In Firezone, a Client requests an "access authorization" for a Resource on the fly when it sees the first packet for said Resource going through the tunnel. If we don't have a connection to the Gateway yet, this is also where we will establish a connection and create the WireGuard tunnel. In order for this to work, the access authorization state between the Client and the Gateway MUST NOT get out of sync. If the Client thinks it has access to a Resource, it will just route the traffic to the Gateway. If the access authorization on the Gateway has expired or vanished otherwise, the packets will be black-holed. Starting with #9816, the Gateway sends ICMP errors back to the application whenever it filters a packet. This can happen either because the access authorization is gone or because the traffic wasn't allowed by the specific filter rules on the Resource. With this patch, the Client will attempt to create a new flow (i.e. re-authorize) traffic for this resource whenever it sees such an ICMP error, therefore acting as a way of synchronizing the view of the world between Client and Gateway should they ever run out of sync. Testing turned out to be a bit tricky. If we let the authorization on the Gateway lapse naturally, we portal will also toggle the Resource off and on on the Client, resulting in "flushing" the current authorizations. Additionally, it the Client had only access to one Resource, then the Gateway will gracefully close the connection, also resulting in the Client creating a new flow for the next packet. To actually trigger this new behaviour we need to: - Access at least two resources via the same Gateway - Directly send `reject_access` to the Gateway for this particular resource To achieve this, we dynamically eval some code on the API node and instruct the Gateway channel to send `reject_access`. The connection stays intact because there is still another active access authorization but packets for the other resource are answered with ICMP errors. To achieve a safe roll-out, the new behaviour is feature-flagged. In order to still test it, we now also allow feature flags to be set via env variables. Resolves: #10074 --------- Co-authored-by: Mariusz Klochowicz <mariusz@klochowicz.com>
Firezone shell scripts
This directory contains various shell scripts used for development, testing, and deployment of the Firezone product.
Developer Setup
We lint shell scripts in CI. To get your PR to pass, you'll want to ensure your local development environment is set up to lint shell scripts:
- Install
shfmt:brew install shfmton macOS- Install shfmt from https://github.com/mvdan/sh/releases for other platforms
- Install
shellcheck:brew install shellcheckon macOSsudo apt-get install shellcheckon Ubuntu
Then just lint and format your shell scripts before you commit:
shfmt -i 4 **/*.sh
shellcheck --severity=warning **/*.sh
You can achieve this more easily by using pre-commit. See
CONTRIBUTING.
Editor setup
- Vim (here's an example using ALE)
- VSCode
Scripting tips
- Use
#!/usr/bin/env bashalong withset -euox pipefailin general for dev and test scripts. - In Docker images and other minimal envs, stick to
#!/bin/shand simplyset -eu.