mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-28 10:18:51 +00:00
eac2516e18
When `connlib` receives a UDP packet for one of its DNS resolver IPs and determines that it needs to be forwarded to another resolver through the tunnel, it mangles the destination IP + port to point to this new resolver. In order for the response to be correctly recognised by the application, the response packet needs its _source_ IP + port mangled. This information is currently stored in a `HashMap` together with an expiry timestamp. To be precise, the information that is captured is only the new destination socket, not the current one. The old socket is then later implied by the DNS mapping that we remember internally, i.e. which one of `connlib`'s DNS resolver IPs maps to which upstream DNS server. For the usecase of forwarding DNS queries of type SRV and TXT to the site that hosts the DNS resource in question, we want to send those DNS queries to a Gateway within that site. For UDP DNS queries, this requires the same data structure as we do for DNS queries that are tunneled to another DNS resolver _beyond_ the Gateway. In fact, from the perspective of the Client, there is no difference between a packet that is handled by the Gateway or by a resolver behind the Gateway. The only difference is in the new destination IP + port. In the case where the Gateway is targeted with the DNS query, we won't be able to resolve the original destination socket from the DNS mapping data structure because the Gateway's IP isn't explicitly configured as a DNS resolver. To handle both of these cases with the same data structure, we refactor this temporary mapping to simply store the original destination socket. To make the data structure less complicated to use, we introduce an `ExpiringMap` that automatically removes entries after a certain deadline. This is important for UDP DNS queries to ensure this map doesn't in an unbounded manner if for some reason, the configured DNS resolver never replies. Related: #8221
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.