mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 10:18:54 +00:00
58fe527b0e
From the perspective of any application, Firezone is a layer-3 network and will thus use the host's networking stack to form IP packets for whichever application protocol is in use (UDP, TCP, etc). These packets then get encapsulated into UDP packets by Firezone and sent to a Gateway. As a result of this design, the IP header seen by the networking stacks of the Client and the receiving service are not visible to any intermediary along the network path of the Client and Gateway. In case this network path is congested and middleboxes such as routers need to drop packets, they will look at the ECN bits in the IP header (of the UDP packet generated by a Client or Gateway) and flip a bit in case the previous value indicated support for ECN (`0x01` or `0x10`). When received by a network stack that supports ECN, seeing `0x11` means that the network path is congested and that it must reduce its send/receive windows (or otherwise throttle the connection). At present, this doesn't work with Firezone because of the aforementioned encapsulation of IP packets. To support ECN, we need to therefore: - Copy ECN bits from a received IP packet to the datagram that encapsulates it: This ensures that if the Client's network stack support ECN, we mirror that support on the wire. - Copy ECN bits from a received datagram to the IP packet the is sent to the TUN device: This ensures that if the "Congestion Experienced" bit get set along the network path between Client and Gateway, we reflect that accordingly on the IP packet emitted by the TUN device. Resolves: #3758 --------- Signed-off-by: Thomas Eizinger <thomas@eizinger.io> Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
Rust development guide
Firezone uses Rust for all data plane components. This directory contains the Linux and Windows clients, and low-level networking implementations related to STUN/TURN.
We target the last stable release of Rust using rust-toolchain.toml.
If you are using rustup, that is automatically handled for you.
Otherwise, ensure you have the latest stable version of Rust installed.
Reading Client logs
The Client logs are written as JSONL for machine-readability.
To make them more human-friendly, pipe them through jq like this:
cd path/to/logs # e.g. `$HOME/.cache/dev.firezone.client/data/logs` on Linux
cat *.log | jq -r '"\(.time) \(.severity) \(.message)"'
Resulting in, e.g.
2024-04-01T18:25:47.237661392Z INFO started log
2024-04-01T18:25:47.238193266Z INFO GIT_VERSION = 1.0.0-pre.11-35-gcc0d43531
2024-04-01T18:25:48.295243016Z INFO No token / actor_name on disk, starting in signed-out state
2024-04-01T18:25:48.295360641Z INFO null
Benchmarking on Linux
The recommended way for benchmarking any of the Rust components is Linux' perf utility.
For example, to attach to a running application, do:
- Ensure the binary you are profiling is compiled with the
releaseprofile. sudo perf record -g --freq 10000 --pid $(pgrep <your-binary>).- Run the speed test or whatever load-inducing task you want to measure.
sudo perf script > profile.perf- Open profiler.firefox.com and load
profile.perf
Instead of attaching to a process with --pid, you can also specify the path to executable directly.
That is useful if you want to capture perf data for a test or a micro-benchmark.