mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-28 02:18:50 +00:00
main
141 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Thomas Eizinger
|
b7dc897eea |
refactor(rust): introduce libs/ directory (#10964)
The current Rust workspace isn't as consistent as it could be. To make navigation a bit easier, we move a few crates around. Generally, we follow the idea that entry-points should be at the top-level. `rust/` now looks like this (directories only): ``` . ├── cli # Firezone CLI ├── client-ffi # Entry point for Apple & Android ├── gateway # Gateway ├── gui-client # GUI client ├── headless-client # Headless client ├── libs # Library crates ├── relay # Relay ├── target # Compile artifacts ├── tests # Crates for testing └── tools # Local tools ``` To further enforce this structure, we also drop the `firezone-` prefix from all crates that are not top-level binary crates. |
||
|
Thomas Eizinger
|
199766ccf9 |
ci(rust): improve proptest coverage checks (#10918)
The current coverage checks for paths that we hit during our proptests fail as soon as one of them is not satisfied. When iterating on the proptests, it is useful to see in one go, which paths are currently not hit to generate the missing regression seeds. Hence, we refactor the script to perform all checks and fail if any of them are not hit, outputting all missing ones. |
||
|
Jamil
|
54e6f8bc0f |
chore(ci): replace macos-13 runners with macos-26 (#10753)
https://github.com/actions/runner-images/issues/13046 Co-authored-by: Thomas Eizinger <thomas@eizinger.io> |
||
|
Thomas Eizinger
|
4e95dd1cb6 |
ci: fail fast inside the merge queue (#10746)
Setting `fail-fast: false` unsurprisingly makes our CI fail pretty slowly. This is especially noticable in the merge queue where a long-running job could still hold up the entire queue even though a different job has failed already and the PR is never going to make it in anyway. To avoid this scenario, we set `fail-fast: true` whenever we are in the merge queue. |
||
|
Thomas Eizinger
|
ed2bc0bd25 |
feat(gateway): revise handling of DNS resolution errors (#10623)
Even prior to #10373, failures in resolving a name on the Gateway for a DNS resource resulted in a failure of setting up the DNS resource NAT. Without the DNS resource NAT, packets for that resource bounced on the Gateway because we didn't have any traffic filters. A non-existent filter is being treated as a "traffic not allowed" error and we respond with an ICMP permission denied error. For domains where both the A and AAAA query result in NXDOMAIN, that isn't necessarily appropriate. Instead, I am proposing that for such cases, we want to return a regular "address/host unreachable" ICMP error instead of the more specific "permission denied" variant. To achieve that, we refactor the Gateway's peer state to be able to hold an `Option<IpAddr>` inside the `TranslationState`. This allows us to always insert an entry for each proxy IP, even if we did not resolve any IPs for it. Then, when receiving traffic for a proxy IP where the resolved IP is `None`, we reply with the appropriate ICMP error. As part of this, we also simplify the assignment of the proxy IPs. With the NAT64 module removed, there is no more reason to cross-assign IPv4 and IPv6 addresses. We can simply leave the mappings for e.g. IPv6 proxy addresses empty if the AAAA query didn't resolve anything. From the Client's perspective, not much changes. The DNS resource NAT setup will now succeed, even for domains that don't resolve to anything. This doesn't change any behaviour though as we are currently already passing packets through for failed DNS resource NAT setups. The main change is that we now send back a different ICMP error. Most importantly, the "address/host unreachable variant" does not trigger #10462. |
||
|
Thomas Eizinger
|
928d8a2512 |
fix(connlib): handle resources changing site (#10604)
Similar to how resources can be edited to change their address, IP stack or other properties, they can also be moved between different sites. Currently, `connlib` requires the portal to explicitly remove the resource and then re-add it for this to work. Our system gets more robust if we also detect that the sites of a resource have changed and handle it like other addressability changes. To ensure that this works correctly, we also extend the proptests to simulate addressability changes of resources. Resolves: #9881 Related: #10593 |
||
|
Thomas Eizinger
|
4ef827b611 |
ci: revise Rust caching configuration (#10512)
We primarily rely on sccache for speeding up our Rust builds. The `setup-rust-toolchain` action configures `rust-cache` in addition but tries to set it up for the root of the repository which doesn't work in our scenario. It is also unnecessary to set up additional caching for the `target` directory because we use `sccache` anyway. sccache only caches compile artifacts but it can also be beneficial to cache the downloaded Rust sources. Those aren't very big so we use the `rust-cache` action for that but disable the `target` cache. This config option isn't forwarded by `setup-rust-toolchain` so we disable its cache integration and use `rust-cache` directly. |
||
|
dependabot[bot]
|
40aba05742 |
build(deps): bump actions/checkout from 4 to 5 (#10440)
Bumps [actions/checkout](https://github.com/actions/checkout) from 4 to 5. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/actions/checkout/releases">actions/checkout's releases</a>.</em></p> <blockquote> <h2>v5.0.0</h2> <h2>What's Changed</h2> <ul> <li>Update actions checkout to use node 24 by <a href="https://github.com/salmanmkc"><code>@salmanmkc</code></a> in <a href="https://redirect.github.com/actions/checkout/pull/2226">actions/checkout#2226</a></li> <li>Prepare v5.0.0 release by <a href="https://github.com/salmanmkc"><code>@salmanmkc</code></a> in <a href="https://redirect.github.com/actions/checkout/pull/2238">actions/checkout#2238</a></li> </ul> <h2>⚠️ Minimum Compatible Runner Version</h2> <p><strong>v2.327.1</strong><br /> <a href="https://github.com/actions/runner/releases/tag/v2.327.1">Release Notes</a></p> <p>Make sure your runner is updated to this version or newer to use this release.</p> <p><strong>Full Changelog</strong>: <a href="https://github.com/actions/checkout/compare/v4...v5.0.0">https://github.com/actions/checkout/compare/v4...v5.0.0</a></p> <h2>v4.3.0</h2> <h2>What's Changed</h2> <ul> <li>docs: update README.md by <a href="https://github.com/motss"><code>@motss</code></a> in <a href="https://redirect.github.com/actions/checkout/pull/1971">actions/checkout#1971</a></li> <li>Add internal repos for checking out multiple repositories by <a href="https://github.com/mouismail"><code>@mouismail</code></a> in <a href="https://redirect.github.com/actions/checkout/pull/1977">actions/checkout#1977</a></li> <li>Documentation update - add recommended permissions to Readme by <a href="https://github.com/benwells"><code>@benwells</code></a> in <a href="https://redirect.github.com/actions/checkout/pull/2043">actions/checkout#2043</a></li> <li>Adjust positioning of user email note and permissions heading by <a href="https://github.com/joshmgross"><code>@joshmgross</code></a> in <a href="https://redirect.github.com/actions/checkout/pull/2044">actions/checkout#2044</a></li> <li>Update README.md by <a href="https://github.com/nebuk89"><code>@nebuk89</code></a> in <a href="https://redirect.github.com/actions/checkout/pull/2194">actions/checkout#2194</a></li> <li>Update CODEOWNERS for actions by <a href="https://github.com/TingluoHuang"><code>@TingluoHuang</code></a> in <a href="https://redirect.github.com/actions/checkout/pull/2224">actions/checkout#2224</a></li> <li>Update package dependencies by <a href="https://github.com/salmanmkc"><code>@salmanmkc</code></a> in <a href="https://redirect.github.com/actions/checkout/pull/2236">actions/checkout#2236</a></li> <li>Prepare release v4.3.0 by <a href="https://github.com/salmanmkc"><code>@salmanmkc</code></a> in <a href="https://redirect.github.com/actions/checkout/pull/2237">actions/checkout#2237</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/motss"><code>@motss</code></a> made their first contribution in <a href="https://redirect.github.com/actions/checkout/pull/1971">actions/checkout#1971</a></li> <li><a href="https://github.com/mouismail"><code>@mouismail</code></a> made their first contribution in <a href="https://redirect.github.com/actions/checkout/pull/1977">actions/checkout#1977</a></li> <li><a href="https://github.com/benwells"><code>@benwells</code></a> made their first contribution in <a href="https://redirect.github.com/actions/checkout/pull/2043">actions/checkout#2043</a></li> <li><a href="https://github.com/nebuk89"><code>@nebuk89</code></a> made their first contribution in <a href="https://redirect.github.com/actions/checkout/pull/2194">actions/checkout#2194</a></li> <li><a href="https://github.com/salmanmkc"><code>@salmanmkc</code></a> made their first contribution in <a href="https://redirect.github.com/actions/checkout/pull/2236">actions/checkout#2236</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/actions/checkout/compare/v4...v4.3.0">https://github.com/actions/checkout/compare/v4...v4.3.0</a></p> <h2>v4.2.2</h2> <h2>What's Changed</h2> <ul> <li><code>url-helper.ts</code> now leverages well-known environment variables by <a href="https://github.com/jww3"><code>@jww3</code></a> in <a href="https://redirect.github.com/actions/checkout/pull/1941">actions/checkout#1941</a></li> <li>Expand unit test coverage for <code>isGhes</code> by <a href="https://github.com/jww3"><code>@jww3</code></a> in <a href="https://redirect.github.com/actions/checkout/pull/1946">actions/checkout#1946</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/actions/checkout/compare/v4.2.1...v4.2.2">https://github.com/actions/checkout/compare/v4.2.1...v4.2.2</a></p> <h2>v4.2.1</h2> <h2>What's Changed</h2> <ul> <li>Check out other refs/* by commit if provided, fall back to ref by <a href="https://github.com/orhantoy"><code>@orhantoy</code></a> in <a href="https://redirect.github.com/actions/checkout/pull/1924">actions/checkout#1924</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/Jcambass"><code>@Jcambass</code></a> made their first contribution in <a href="https://redirect.github.com/actions/checkout/pull/1919">actions/checkout#1919</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/actions/checkout/compare/v4.2.0...v4.2.1">https://github.com/actions/checkout/compare/v4.2.0...v4.2.1</a></p> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
eeadde0c86 |
ci: bump Ubuntu runners to 24.04 (#10288)
Ubuntu 22.04 is over 3 years old and therefore ships with quite an old kernel. Our production VMs (for relays) all run Ubuntu 24.04 so it makes sense to build and test them on the same kernel / OS release. For consistency reasons, we therefore bump all runners to 24.04. |
||
|
Jamil
|
1a251406c9 |
fix(ci): bump tauri setup timeout to 15m (#10280)
These occasionally take just a bit more time to complete. Related: https://github.com/firezone/firezone/actions/runs/17403822300/job/49402974171 |
||
|
Thomas Eizinger
|
0c2e54f54c |
feat(connlib): persistent DNS resource records across sessions (#10104)
When we receive a DNS query for a DNS resource in Firezone, we take the next available 4 IPs from the CG-NAT range and assign them to the domain name. For example, if `example.com` is a DNS resource and it is the first resource being queried in a Firezone session, we will assigned the IPs `100.96.0.1` - `100.96.0.4` to it. If the user now restarts Firezone or signs out and back in, this state is lost and we assign those same IPs to the next DNS query coming in. This creates a problem for applications that do not re-query DNS very often or never. They expect these IPs to not change. Restarting software or signing out and back in is a common approach to fixing software problems, yet in this specific case, doing so may create even more problems for the user. To mitigate this, `ClientState` introduce a new event `DnsRecordsChanged` that gets emitted to the event-loop every time we assign new records. The event-loop then caches this in memory and reuses it in case a new session is initiated. The records are only stored in-memory and not on disk. Most likely, the tunnel process will be alive for the entire OS session. To verify this behaviour, we add a new `RestartClient` transition to our proptests. In the proptests, we already keep a mapping of all DNS names we ever resolved, including DNS resources. When generating IP traffic, we sample from this list of IPs and then expect the packet to be routed. By replacing the `ClientState` as part of this transition and re-seeding it with the previously exported DNS records, we can verify that packets to IPs resolved from a previous session still get successfully routed to the resource. Related: #5498 |
||
|
Jamil
|
8eb738e66a |
chore(ci): downgrade runners to free tier (#10248)
To avoid burning Azure credits, we move the runners back down to the free tier. Now that caching is properly set up, this should incur only a minor increase in CI time. |
||
|
Jamil
|
3c55ddcd1e |
fix(ci): move rust cache to Azure; docker on main (#10169)
We are _very much_ over our GHA cache limit of 10 GB so in an effort to keep evictions to a minimum, we update the Rust SCCACHE to only write on `main` and the Docker elixir and data plane image build steps to do the same. Fixes #10145 |
||
|
dependabot[bot]
|
0b2fcbd16f |
build(deps): bump taiki-e/install-action from 2.55.3 to 2.57.5 (#10091)
Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.55.3 to 2.57.5. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's releases</a>.</em></p> <blockquote> <h2>2.57.5</h2> <ul> <li>Update <code>vacuum@latest</code> to 0.17.7.</li> </ul> <h2>2.57.4</h2> <ul> <li>Update <code>trivy@latest</code> to 0.65.0.</li> </ul> <h2>2.57.3</h2> <ul> <li>Update <code>syft@latest</code> to 1.29.1.</li> </ul> <h2>2.57.2</h2> <ul> <li> <p>Update <code>grcov@latest</code> to 0.10.3.</p> </li> <li> <p>Update <code>cargo-shear@latest</code> to 1.4.1.</p> </li> </ul> <h2>2.57.1</h2> <ul> <li> <p>Update <code>git-cliff@latest</code> to 2.10.0.</p> </li> <li> <p>Update <code>cargo-binstall@latest</code> to 1.14.2.</p> </li> </ul> <h2>2.57.0</h2> <ul> <li>Support <code>mdbook-alerts</code>. (<a href="https://redirect.github.com/taiki-e/install-action/pull/1060">#1060</a>, thanks <a href="https://github.com/CommanderStorm"><code>@CommanderStorm</code></a>)</li> </ul> <h2>2.56.24</h2> <ul> <li>Update <code>just@latest</code> to 1.42.4.</li> </ul> <h2>2.56.23</h2> <ul> <li>Update <code>release-plz@latest</code> to 0.3.139.</li> </ul> <h2>2.56.22</h2> <ul> <li>Update <code>wasmtime@latest</code> to 35.0.0.</li> </ul> <h2>2.56.21</h2> <ul> <li>Improve error message for unsupported host architectures.</li> </ul> <h2>2.56.20</h2> <ul> <li>Update <code>syft@latest</code> to 1.29.0.</li> </ul> <h2>2.56.19</h2> <ul> <li>Update <code>cargo-llvm-cov@latest</code> to 0.6.18.</li> </ul> <h2>2.56.18</h2> <ul> <li>Update <code>just@latest</code> to 1.42.3.</li> </ul> <h2>2.56.17</h2> <ul> <li>Update <code>wasmtime@latest</code> to 34.0.2.</li> </ul> <h2>2.56.16</h2> <ul> <li> <p>Update <code>cargo-zigbuild@latest</code> to 0.20.1.</p> </li> <li> <p>Update <code>cargo-lambda@latest</code> to 1.8.6.</p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's changelog</a>.</em></p> <blockquote> <h1>Changelog</h1> <p>All notable changes to this project will be documented in this file.</p> <p>This project adheres to <a href="https://semver.org">Semantic Versioning</a>.</p> <!-- raw HTML omitted --> <h2>[Unreleased]</h2> <h2>[2.57.5] - 2025-08-01</h2> <ul> <li>Update <code>vacuum@latest</code> to 0.17.7.</li> </ul> <h2>[2.57.4] - 2025-07-31</h2> <ul> <li>Update <code>trivy@latest</code> to 0.65.0.</li> </ul> <h2>[2.57.3] - 2025-07-31</h2> <ul> <li>Update <code>syft@latest</code> to 1.29.1.</li> </ul> <h2>[2.57.2] - 2025-07-29</h2> <ul> <li> <p>Update <code>grcov@latest</code> to 0.10.3.</p> </li> <li> <p>Update <code>cargo-shear@latest</code> to 1.4.1.</p> </li> </ul> <h2>[2.57.1] - 2025-07-27</h2> <ul> <li> <p>Update <code>git-cliff@latest</code> to 2.10.0.</p> </li> <li> <p>Update <code>cargo-binstall@latest</code> to 1.14.2.</p> </li> </ul> <h2>[2.57.0] - 2025-07-26</h2> <ul> <li>Support <code>mdbook-alerts</code>. (<a href="https://redirect.github.com/taiki-e/install-action/pull/1060">#1060</a>, thanks <a href="https://github.com/CommanderStorm"><code>@CommanderStorm</code></a>)</li> </ul> <h2>[2.56.24] - 2025-07-25</h2> <ul> <li>Update <code>just@latest</code> to 1.42.4.</li> </ul> <h2>[2.56.23] - 2025-07-24</h2> <ul> <li>Update <code>release-plz@latest</code> to 0.3.139.</li> </ul> <h2>[2.56.22] - 2025-07-24</h2> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
69f9a03ee8 |
refactor(connlib): simplify IpPacket struct (#9795)
With the removal of the NAT64/46 modules, we can now simplify the internals of our `IpPacket` struct. The requirements for our `IpPacket` struct are somewhat delicate. On the one hand, we don't want to be overly restrictive in our parsing / validation code because there is a lot of broken software out there that doesn't necessarily follow RFCs. Hence, we want to be as lenient as possible in what we accept. On the other hand, we do need to verify certain aspects of the packet, like the payload lengths. At the moment, we are somewhat too lenient there which causes errors on the Gateway where we have to NAT or otherwise manipulate the packets. See #9567 or #9552 for example. To fix this, we make the parsing in the `IpPacket` constructor more restrictive. If it is a UDP, TCP or ICMP packet, we attempt to fully parse its headers and validate the payload lengths. This parsing allows us to then rely on the integrity of the packet as part of the implementation. This does create several code paths that can in theory panic but in practice, should be impossible to hit. To ensure that this does in fact not happen, we also tackle an issue that is long overdue: Fuzzing. Resolves: #6667 Resolves: #9567 Resolves: #9552 |
||
|
Thomas Eizinger
|
d244a99c58 |
feat(connlib): always use all candidates (#9979)
In #6876, we added functionality that would only make use of new remote candidates whilst we haven't nominated a socket yet with the remote. The reason for that was because in the described edge-case where relays reboot or get replaced whilst the client is partitioned from the portal (or we experience a connection hiccup), only one of the two peers, i.e. Client or Gateway would migrate to the new relay, leaving the other one in an inconsistent state. Looking at recent customer logs, I've been seeing a lot of these messages: > Unknown connection or socket has already been nominated For this particular customer, these are then very quickly followed by ICE timeouts, leaving the connection unusable. Considering that, I no longer think that the above change was a good idea and we should instead always make use of all candidates that we are given. What we are seeing is that in deployment scenarios where the latency link between Client and Gateway is very short (5-10ms) yet the latency to the portal is longer (~30-50ms), we trigger a race condition where we are temporarily nominating a _peer-reflexive_ candidate pair instead of a regular one. This happens because with such a short latency link, Client and Gateway are _faster_ in sending back and forth several STUN bindings than the control plane is in delivering all the candidates. Due to the functionality added in #6876, this then results in us not accepting the candidates. It further appears that a nominated peer-reflexive candidate does not provide a stable connection which is why we then run into an ICE timeout, requiring Firezone to establish a new connection only to have the same thing happen again. This is very disruptive for the user experience as the connection only works for a few moments at a time. With #9793, we have actually added a feature that is also at play here. Now that we don't immediately act on an ICE timeout, it is actually possible for both Client and Gateway to migrate a connection to a different relay, should the one that they are using get disconnected. In #9793, we added a timeout of 2s for this. To make this fully work, we need to patch str0m to transition to `Checking` early. Presently, str0m would directly transition from `Disconnected` to `Connected` in this case which in some of the high-latency scenarios that we are testing in CI is not enough to recover the connection within 2s. By transitioning to `Checking` early, we abort this timer. Related: https://github.com/algesten/str0m/pull/676 |
||
|
dependabot[bot]
|
4c0c605c72 |
build(deps): bump taiki-e/install-action from 2.55.3 to 2.56.19 (#9918)
Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.55.3 to 2.56.19. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's releases</a>.</em></p> <blockquote> <h2>2.56.19</h2> <ul> <li>Update <code>cargo-llvm-cov@latest</code> to 0.6.18.</li> </ul> <h2>2.56.18</h2> <ul> <li>Update <code>just@latest</code> to 1.42.3.</li> </ul> <h2>2.56.17</h2> <ul> <li>Update <code>wasmtime@latest</code> to 34.0.2.</li> </ul> <h2>2.56.16</h2> <ul> <li> <p>Update <code>cargo-zigbuild@latest</code> to 0.20.1.</p> </li> <li> <p>Update <code>cargo-lambda@latest</code> to 1.8.6.</p> </li> <li> <p>Update <code>vacuum@latest</code> to 0.17.6.</p> </li> <li> <p>Update <code>earthly@latest</code> to 0.8.16.</p> </li> </ul> <h2>2.56.15</h2> <ul> <li> <p>Fix <code>cargo-valgrind</code> installation error due to their tag rename.</p> </li> <li> <p>Update <code>cargo-valgrind@latest</code> to 2.3.2.</p> </li> <li> <p>Update <code>just@latest</code> to 1.42.2.</p> </li> </ul> <h2>2.56.14</h2> <ul> <li> <p>Update <code>zola@latest</code> to 0.21.0.</p> </li> <li> <p>Update <code>wait-for-them@latest</code> to 0.5.1.</p> </li> <li> <p>Update <code>mdbook@latest</code> to 0.4.52.</p> </li> <li> <p>Update <code>just@latest</code> to 1.42.1.</p> </li> <li> <p>Update <code>cargo-shear@latest</code> to 1.4.0.</p> </li> <li> <p>Update <code>cyclonedx@latest</code> to 0.29.0.</p> </li> </ul> <h2>2.56.13</h2> <ul> <li>Update <code>cargo-nextest@latest</code> to 0.9.101.</li> </ul> <h2>2.56.12</h2> <ul> <li>Update <code>cargo-hack@latest</code> to 0.6.37.</li> </ul> <h2>2.56.11</h2> <ul> <li> <p>Update <code>osv-scanner@latest</code> to 2.1.0.</p> </li> <li> <p>Update <code>cargo-no-dev-deps@latest</code> to 0.2.16.</p> </li> <li> <p>Update <code>cargo-minimal-versions@latest</code> to 0.1.31.</p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's changelog</a>.</em></p> <blockquote> <h1>Changelog</h1> <p>All notable changes to this project will be documented in this file.</p> <p>This project adheres to <a href="https://semver.org">Semantic Versioning</a>.</p> <!-- raw HTML omitted --> <h2>[Unreleased]</h2> <h2>[2.56.19] - 2025-07-19</h2> <ul> <li>Update <code>cargo-llvm-cov@latest</code> to 0.6.18.</li> </ul> <h2>[2.56.18] - 2025-07-19</h2> <ul> <li>Update <code>just@latest</code> to 1.42.3.</li> </ul> <h2>[2.56.17] - 2025-07-18</h2> <ul> <li>Update <code>wasmtime@latest</code> to 34.0.2.</li> </ul> <h2>[2.56.16] - 2025-07-18</h2> <ul> <li> <p>Update <code>cargo-zigbuild@latest</code> to 0.20.1.</p> </li> <li> <p>Update <code>cargo-lambda@latest</code> to 1.8.6.</p> </li> <li> <p>Update <code>vacuum@latest</code> to 0.17.6.</p> </li> <li> <p>Update <code>earthly@latest</code> to 0.8.16.</p> </li> </ul> <h2>[2.56.15] - 2025-07-16</h2> <ul> <li> <p>Fix <code>cargo-valgrind</code> installation error due to their tag rename.</p> </li> <li> <p>Update <code>cargo-valgrind@latest</code> to 2.3.2.</p> </li> <li> <p>Update <code>just@latest</code> to 1.42.2.</p> </li> </ul> <h2>[2.56.14] - 2025-07-15</h2> <ul> <li> <p>Update <code>zola@latest</code> to 0.21.0.</p> </li> <li> <p>Update <code>wait-for-them@latest</code> to 0.5.1.</p> </li> <li> <p>Update <code>mdbook@latest</code> to 0.4.52.</p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
3e71a91667 |
feat(gateway): revoke unlisted authorizations upon init (#9896)
When receiving an `init` message from the portal, we will now revoke all authorizations not listed in the `authorizations` list of the `init` message. We (partly) test this by introducing a new transition in our proptests that de-authorizes a certain resource whilst the Gateway is simulated to be partitioned. It is difficult to test that we cannot make a connection once that has happened because we would have to simulate a malicious client that knows about resources / connections or ignores the "remove resource" message. Testing this is deferred to a dedicated task. We do test that we hit the code path of revoking the resource authorization and because the other resources keep working, we also test that we are at least not revoking the wrong ones. Resolves: #9892 |
||
|
Thomas Eizinger
|
66455ab0ef |
feat(gateway): translate TimeExceeded ICMP messages (#9812)
In the DNS resource NAT table, we track parts of the layer 4 protocol of
the connection in order to map packets back to the correct proxy IP in
case multiple DNS names resolve to the same real IP. The involvement of
layer 4 means we need to perform some packet inspection in case we
receive ICMP errors from an upstream router.
Presently, the only ICMP error we handle here is destination
unreachable. Those are generated e.g. when we are trying to contact an
IPv6 address but we don't have an IPv6 egress interface. An additional
error that we want to handle here is "time exceeded":
Time exceeded is sent when the TTL of a packet reaches 0. Typically,
TTLs are set high enough such that the packet makes it to its
destination. When using tools such as `tracepath` however, the TTL is
specifically only incremented one-by-one in order to resolve the exact
hops a packet is taking to a destination. Without handling the time
exceeded ICMP error, using `tracepath` through Firezone is broken
because the packets get dropped at the DNS resource NAT.
With this PR, we generalise the functionality of detecting destination
unreachable ICMP errors to also handle time-exceeded errors, allowing
tools such as `tracepath` to somewhat work:
```
❯ sudo docker compose exec --env RUST_LOG=info -it client /bin/sh -c 'tracepath -b example.com'
1?: [LOCALHOST] pmtu 1280
1: 100.82.110.64 (100.82.110.64) 0.795ms
1: 100.82.110.64 (100.82.110.64) 0.593ms
2: example.com (100.96.0.1) 0.696ms asymm 45
3: example.com (100.96.0.1) 5.788ms asymm 45
4: example.com (100.96.0.1) 7.787ms asymm 45
5: example.com (100.96.0.1) 8.412ms asymm 45
6: example.com (100.96.0.1) 9.545ms asymm 45
7: example.com (100.96.0.1) 7.312ms asymm 45
8: example.com (100.96.0.1) 8.779ms asymm 45
9: example.com (100.96.0.1) 9.455ms asymm 45
10: example.com (100.96.0.1) 14.410ms asymm 45
11: example.com (100.96.0.1) 24.244ms asymm 45
12: example.com (100.96.0.1) 31.286ms asymm 45
13: no reply
14: example.com (100.96.0.1) 303.860ms asymm 45
15: no reply
16: example.com (100.96.0.1) 135.616ms (This broken router returned corrupted payload) asymm 45
17: no reply
18: example.com (100.96.0.1) 161.647ms asymm 45
19: no reply
20: no reply
21: no reply
22: example.com (100.96.0.1) 238.066ms reached
Resume: pmtu 1280 hops 22 back 45
```
We say "somewhat work" because due to the NAT that is in place for DNS
resources, the output does not disclose the intermediary hops beyond the
Gateway.
Co-authored-by: Antoine Labarussias <antoinelabarussias@gmail.com>
---------
Co-authored-by: Antoine Labarussias <antoinelabarussias@gmail.com>
|
||
|
Thomas Eizinger
|
55eaa7cdc7 |
test(connlib): establish real TCP connections in proptests (#9814)
With this patch, we sample a list of DNS resources on each test run and create a "TCP service" for each of their addresses. Using this list of resources, we then change the `SendTcpPayload` transition to `ConnectTcp` and establish TCP connections using `smoltcp` to these services. For now, we don't send any data on these connections but we do set the keep-alive interval to 5s, meaning `smoltcp` itself will keep these connections alive. We also set the timeout to 30s and after each transition in a test-run, we assert that all TCP sockets are still in their expected state: - `ESTABLISHED` for most of them. - `CLOSED` for all sockets where we ended up sampling an IPv4 address but the DNS resource only supports IPv6 addresses (or vice-versa). In these cases, we use the ICMP error to sent by the Gateway to assert that the socket is `CLOSED`. Unfortunately, `smoltcp` currently does not handle ICMP messages for its sockets, so we have to call `abort` ourselves. Overall, this should assert that regardless of whether we roam networks, switch relays or do other kind of stuff with the underlying connection, the tunneled TCP connection stays alive. In order to make this work, I had to tweak the timeouts when we are on-demand refreshing allocations. This only happens in one particular case: When we are being given new relays by the portal, we refresh all _other_ relays to make sure they are still present. In other words, all relays that we didn't remove and didn't just add but still had in-memory are refreshed. This is important for cases where we are network-partitioned from the portal whilst relays are deployed or reset their state otherwise. Instead of the previous 8s max elapsed time of the exponential backoff like we have it for other requests, we now only use a single message with a 1s timeout there. With the increased ICE timeout of 15s, a TCP connection with a 30s timeout would otherwise not survive such an event. This is because it takes the above mentioned 8s for us to remove a non-functioning relay, all whilst trying to establish a new connection (which also incurs its own ICE timeout then). With the reduced timeout on the on-demand refresh of 1s, we detect the disappeared relay much quicker and can immediately establish a new connection via one of the new ones. As always with reduced timeouts, this can create false-positives if the relay doesn't reply within 1s for some reason. Resolves: #9531 |
||
|
dependabot[bot]
|
b8b255c79f |
build(deps): bump taiki-e/install-action from 2.52.6 to 2.55.3 (#9749)
Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.52.6 to 2.55.3. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's releases</a>.</em></p> <blockquote> <h2>2.55.3</h2> <ul> <li>Update <code>dprint@latest</code> to 0.50.1.</li> </ul> <h2>2.55.2</h2> <ul> <li> <p>Update <code>zizmor@latest</code> to 1.11.0.</p> </li> <li> <p>Update <code>cargo-dinghy@latest</code> to 0.8.1.</p> </li> </ul> <h2>2.55.1</h2> <ul> <li> <p>Update <code>vacuum@latest</code> to 0.17.1.</p> </li> <li> <p>Update <code>typos@latest</code> to 1.34.0.</p> </li> </ul> <h2>2.55.0</h2> <ul> <li> <p>Support <code>vacuum</code>. (<a href="https://redirect.github.com/taiki-e/install-action/pull/1016">#1016</a>, thanks <a href="https://github.com/jayvdb"><code>@jayvdb</code></a>)</p> </li> <li> <p>Update <code>cargo-shear@latest</code> to 1.3.2.</p> </li> </ul> <h2>2.54.3</h2> <ul> <li>Update <code>cargo-careful@latest</code> to 0.4.8.</li> </ul> <h2>2.54.2</h2> <ul> <li> <p>Update <code>rclone@latest</code> to 1.70.2.</p> </li> <li> <p>Update <code>zizmor@latest</code> to 1.10.0.</p> </li> </ul> <h2>2.54.1</h2> <ul> <li> <p>Update <code>wasmtime@latest</code> to 34.0.1.</p> </li> <li> <p>Update <code>cargo-tarpaulin@latest</code> to 0.32.8.</p> </li> <li> <p>Update <code>knope@latest</code> to 0.21.0.</p> </li> </ul> <h2>2.54.0</h2> <ul> <li> <p>Add <code>cyclonedx</code> (<a href="https://redirect.github.com/taiki-e/install-action/pull/1000">#1000</a>, thanks <a href="https://github.com/jayvdb"><code>@jayvdb</code></a>)</p> </li> <li> <p>Update <code>wasmtime@latest</code> to 34.0.0.</p> </li> <li> <p>Update <code>rclone@latest</code> to 1.70.1.</p> </li> <li> <p>Update <code>cargo-binstall@latest</code> to 1.14.1.</p> </li> <li> <p>Update <code>release-plz@latest</code> to 0.3.136.</p> </li> </ul> <h2>2.53.2</h2> <ul> <li> <p>Fix <code>cargo-nextest</code> installation failure on Ubuntu 24.04 due to HTTP 403 error on requests to crates.io. (<a href="https://redirect.github.com/taiki-e/install-action/pull/1007">#1007</a>)</p> </li> <li> <p>Update <code>rclone@latest</code> to 1.70.0.</p> </li> </ul> <h2>2.53.1</h2> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's changelog</a>.</em></p> <blockquote> <h1>Changelog</h1> <p>All notable changes to this project will be documented in this file.</p> <p>This project adheres to <a href="https://semver.org">Semantic Versioning</a>.</p> <!-- raw HTML omitted --> <h2>[Unreleased]</h2> <ul> <li> <p>Update <code>trivy@latest</code> to 0.64.0.</p> </li> <li> <p>Update <code>just@latest</code> to 1.41.0.</p> </li> </ul> <h2>[2.55.3] - 2025-06-30</h2> <ul> <li>Update <code>dprint@latest</code> to 0.50.1.</li> </ul> <h2>[2.55.2] - 2025-06-30</h2> <ul> <li> <p>Update <code>zizmor@latest</code> to 1.11.0.</p> </li> <li> <p>Update <code>cargo-dinghy@latest</code> to 0.8.1.</p> </li> </ul> <h2>[2.55.1] - 2025-06-30</h2> <ul> <li> <p>Update <code>vacuum@latest</code> to 0.17.1.</p> </li> <li> <p>Update <code>typos@latest</code> to 1.34.0.</p> </li> </ul> <h2>[2.55.0] - 2025-06-30</h2> <ul> <li> <p>Support <code>vacuum</code>. (<a href="https://redirect.github.com/taiki-e/install-action/pull/1016">#1016</a>, thanks <a href="https://github.com/jayvdb"><code>@jayvdb</code></a>)</p> </li> <li> <p>Update <code>cargo-shear@latest</code> to 1.3.2.</p> </li> </ul> <h2>[2.54.3] - 2025-06-28</h2> <ul> <li>Update <code>cargo-careful@latest</code> to 0.4.8.</li> </ul> <h2>[2.54.2] - 2025-06-27</h2> <ul> <li> <p>Update <code>rclone@latest</code> to 1.70.2.</p> </li> <li> <p>Update <code>zizmor@latest</code> to 1.10.0.</p> </li> </ul> <h2>[2.54.1] - 2025-06-25</h2> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
40f0609d90 |
ci: lint GitHub workflows with actionlint (#9590)
[`actionlint`](https://github.com/rhysd/actionlint) is a static analysis tool for GitHub workflows and actions. It detects various issues ahead of time and runs shellcheck on all `run` blocks. It is worth noting that this does **not** lint the contents of composite actions so we still need to be vigilant when working with those. |
||
|
Thomas Eizinger
|
1bd3d2a382 |
chore(gateway): remove NAT64/46 module (#9626)
This has been disabled for several releases now and is not causing any problems in production. We can therefore safely remove it. It is about time we do this because our tests are actually still testing the variant without the feature flag and therefore deviate from what we do in production. We therefore have to convert the tests as well. Doing so uncovered a minor problem in our ICMP error parsing code: We attempted to parse the payload of an ICMP error as a fully-valid layer 4 header (e.g. TCP header or UDP header). However, per the RFC a node only needs to embed the first 8 bytes of the original packet in an ICMPv4 error. That is not enough to parse a valid TCP header as those are at least 20 bytes. I don't expect this to be a huge problem in production right now though. We only use this code to parse ICMP errors arriving on the Gateway and I _think_ most devices actually include more than 8 bytes. This only surfaced because we are very strict with only embedding exactly 8 bytes when we generate an ICMP error. Additionally, we change our ICMP errors to be sent from the resource IP rather than the Gateway's TUN device. Given that we perform NAT on these IPs anyway, I think this can still be argued to be RFC conform. The _proxy_ IP which we are trying to contact can be reached but it cannot be routed further. Therefore the destination is unreachable, yet the source of this error is the proxy IP itself. I think this is actually more correct than sending the packets from the Gateway's TUN device because the TUN device itself is not a routing hop per-se: its IP won't ever show up in the routing path. |
||
|
Jamil
|
ec5c433f5b |
feat(ci): use larger runners for all jobs (#9646)
Append `-xlarge` to the previous runner labels to match new larger runners. |
||
|
Thomas Eizinger
|
692b61d159 | ci: move GUI smoke tests to tauri workflow (#9627) | ||
|
dependabot[bot]
|
2af7132db1 |
build(deps): bump taiki-e/install-action from 2.52.4 to 2.52.6 (#9424)
Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.52.4 to 2.52.6. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's releases</a>.</em></p> <blockquote> <h2>2.52.6</h2> <ul> <li> <p>Update <code>cargo-udeps@latest</code> to 0.1.56.</p> </li> <li> <p>Update <code>git-cliff@latest</code> to 2.9.1.</p> </li> </ul> <h2>2.52.5</h2> <ul> <li> <p>Update <code>typos@latest</code> to 1.33.1.</p> </li> <li> <p>Update <code>git-cliff@latest</code> to 2.9.0.</p> </li> <li> <p>Update <code>cargo-shear@latest</code> to 1.3.1.</p> </li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's changelog</a>.</em></p> <blockquote> <h1>Changelog</h1> <p>All notable changes to this project will be documented in this file.</p> <p>This project adheres to <a href="https://semver.org">Semantic Versioning</a>.</p> <!-- raw HTML omitted --> <h2>[Unreleased]</h2> <h2>[2.52.6] - 2025-06-04</h2> <ul> <li> <p>Update <code>cargo-udeps@latest</code> to 0.1.56.</p> </li> <li> <p>Update <code>git-cliff@latest</code> to 2.9.1.</p> </li> </ul> <h2>[2.52.5] - 2025-06-03</h2> <ul> <li> <p>Update <code>typos@latest</code> to 1.33.1.</p> </li> <li> <p>Update <code>git-cliff@latest</code> to 2.9.0.</p> </li> <li> <p>Update <code>cargo-shear@latest</code> to 1.3.1.</p> </li> </ul> <h2>[2.52.4] - 2025-05-31</h2> <ul> <li> <p>Update <code>cargo-binstall@latest</code> to 1.12.6.</p> </li> <li> <p>Update <code>wash@latest</code> to 0.42.0.</p> </li> </ul> <h2>[2.52.3] - 2025-05-30</h2> <ul> <li> <p>Update <code>cargo-nextest@latest</code> to 0.9.97.</p> </li> <li> <p>Update <code>trivy@latest</code> to 0.63.0.</p> </li> <li> <p>Update <code>protoc@latest</code> to 3.31.1.</p> </li> </ul> <h2>[2.52.2] - 2025-05-27</h2> <ul> <li>Update <code>mdbook@latest</code> to 0.4.51.</li> </ul> <h2>[2.52.1] - 2025-05-25</h2> <ul> <li> <p>Update <code>taplo@latest</code> to 0.10.0.</p> </li> <li> <p>Update <code>mdbook@latest</code> to 0.4.50.</p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Jamil
|
223fd91c04 |
chore(ci): bump windows-2019 runners to windows-2022 (#9386)
Windows server 2019 is end of life apparently. https://github.blog/changelog/2025-04-15-upcoming-breaking-changes-and-releases-for-github-actions/#windows-server-2019-is-closing-down |
||
|
dependabot[bot]
|
caa19a3083 |
build(deps): bump taiki-e/install-action from 2.52.2 to 2.52.4 (#9336)
Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.52.2 to 2.52.4. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's releases</a>.</em></p> <blockquote> <h2>2.52.4</h2> <ul> <li> <p>Update <code>cargo-binstall@latest</code> to 1.12.6.</p> </li> <li> <p>Update <code>wash@latest</code> to 0.42.0.</p> </li> </ul> <h2>2.52.3</h2> <ul> <li> <p>Update <code>cargo-nextest@latest</code> to 0.9.97.</p> </li> <li> <p>Update <code>trivy@latest</code> to 0.63.0.</p> </li> <li> <p>Update <code>protoc@latest</code> to 3.31.1.</p> </li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's changelog</a>.</em></p> <blockquote> <h1>Changelog</h1> <p>All notable changes to this project will be documented in this file.</p> <p>This project adheres to <a href="https://semver.org">Semantic Versioning</a>.</p> <!-- raw HTML omitted --> <h2>[Unreleased]</h2> <h2>[2.52.4] - 2025-05-31</h2> <ul> <li> <p>Update <code>cargo-binstall@latest</code> to 1.12.6.</p> </li> <li> <p>Update <code>wash@latest</code> to 0.42.0.</p> </li> </ul> <h2>[2.52.3] - 2025-05-30</h2> <ul> <li> <p>Update <code>cargo-nextest@latest</code> to 0.9.97.</p> </li> <li> <p>Update <code>trivy@latest</code> to 0.63.0.</p> </li> <li> <p>Update <code>protoc@latest</code> to 3.31.1.</p> </li> </ul> <h2>[2.52.2] - 2025-05-27</h2> <ul> <li>Update <code>mdbook@latest</code> to 0.4.51.</li> </ul> <h2>[2.52.1] - 2025-05-25</h2> <ul> <li> <p>Update <code>taplo@latest</code> to 0.10.0.</p> </li> <li> <p>Update <code>mdbook@latest</code> to 0.4.50.</p> </li> <li> <p>Update <code>deepsource@latest</code> to 0.9.0.</p> </li> <li> <p>Update <code>cargo-shear@latest</code> to 1.3.0.</p> </li> </ul> <h2>[2.52.0] - 2025-05-22</h2> <ul> <li> <p>Support <code>trivy</code>. (<a href="https://redirect.github.com/taiki-e/install-action/pull/970">#970</a>, thanks <a href="https://github.com/jayvdb"><code>@jayvdb</code></a>)</p> </li> <li> <p>Update <code>syft@latest</code> to 1.26.1.</p> </li> <li> <p>Update <code>rclone@latest</code> to 1.69.3.</p> </li> <li> <p>Update <code>cargo-shear@latest</code> to 1.2.8.</p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
dependabot[bot]
|
9e9be3de66 |
build(deps): bump taiki-e/install-action from 2.50.4 to 2.52.2 (#9277)
Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.50.4 to 2.52.2. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's releases</a>.</em></p> <blockquote> <h2>2.52.2</h2> <ul> <li>Update <code>mdbook@latest</code> to 0.4.51.</li> </ul> <h2>2.52.1</h2> <ul> <li> <p>Update <code>taplo@latest</code> to 0.10.0.</p> </li> <li> <p>Update <code>mdbook@latest</code> to 0.4.50.</p> </li> <li> <p>Update <code>deepsource@latest</code> to 0.9.0.</p> </li> <li> <p>Update <code>cargo-shear@latest</code> to 1.3.0.</p> </li> </ul> <h2>2.52.0</h2> <ul> <li> <p>Support <code>trivy</code>. (<a href="https://redirect.github.com/taiki-e/install-action/pull/970">#970</a>, thanks <a href="https://github.com/jayvdb"><code>@jayvdb</code></a>)</p> </li> <li> <p>Update <code>syft@latest</code> to 1.26.1.</p> </li> <li> <p>Update <code>rclone@latest</code> to 1.69.3.</p> </li> <li> <p>Update <code>cargo-shear@latest</code> to 1.2.8.</p> </li> </ul> <h2>2.51.3</h2> <ul> <li> <p>Update <code>wasmtime@latest</code> to 33.0.0.</p> </li> <li> <p>Update <code>cargo-tarpaulin@latest</code> to 0.32.7.</p> </li> <li> <p>Update <code>espup@latest</code> to 0.15.1.</p> </li> <li> <p>Update <code>dprint@latest</code> to 0.50.0.</p> </li> </ul> <h2>2.51.2</h2> <ul> <li> <p>Update <code>syft@latest</code> to 1.25.1.</p> </li> <li> <p>Update <code>release-plz@latest</code> to 0.3.135.</p> </li> </ul> <h2>2.51.1</h2> <ul> <li> <p>Update <code>syft@latest</code> to 1.25.0.</p> </li> <li> <p>Update <code>cargo-binstall@latest</code> to 1.12.5.</p> </li> </ul> <h2>2.51.0</h2> <ul> <li> <p>Support <code>cargo-shear</code>. (<a href="https://redirect.github.com/taiki-e/install-action/pull/962">#962</a>, thanks <a href="https://github.com/vivienm"><code>@vivienm</code></a>)</p> </li> <li> <p>Update <code>grcov@latest</code> to 0.10.0.</p> </li> <li> <p>Update <code>cargo-nextest@latest</code> to 0.9.96.</p> </li> <li> <p>Update <code>protoc@latest</code> to 3.31.0.</p> </li> <li> <p>Update <code>syft@latest</code> to 1.24.0.</p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's changelog</a>.</em></p> <blockquote> <h1>Changelog</h1> <p>All notable changes to this project will be documented in this file.</p> <p>This project adheres to <a href="https://semver.org">Semantic Versioning</a>.</p> <!-- raw HTML omitted --> <h2>[Unreleased]</h2> <h2>[2.52.2] - 2025-05-27</h2> <ul> <li>Update <code>mdbook@latest</code> to 0.4.51.</li> </ul> <h2>[2.52.1] - 2025-05-25</h2> <ul> <li> <p>Update <code>taplo@latest</code> to 0.10.0.</p> </li> <li> <p>Update <code>mdbook@latest</code> to 0.4.50.</p> </li> <li> <p>Update <code>deepsource@latest</code> to 0.9.0.</p> </li> <li> <p>Update <code>cargo-shear@latest</code> to 1.3.0.</p> </li> </ul> <h2>[2.52.0] - 2025-05-22</h2> <ul> <li> <p>Support <code>trivy</code>. (<a href="https://redirect.github.com/taiki-e/install-action/pull/970">#970</a>, thanks <a href="https://github.com/jayvdb"><code>@jayvdb</code></a>)</p> </li> <li> <p>Update <code>syft@latest</code> to 1.26.1.</p> </li> <li> <p>Update <code>rclone@latest</code> to 1.69.3.</p> </li> <li> <p>Update <code>cargo-shear@latest</code> to 1.2.8.</p> </li> </ul> <h2>[2.51.3] - 2025-05-20</h2> <ul> <li> <p>Update <code>wasmtime@latest</code> to 33.0.0.</p> </li> <li> <p>Update <code>cargo-tarpaulin@latest</code> to 0.32.7.</p> </li> <li> <p>Update <code>espup@latest</code> to 0.15.1.</p> </li> <li> <p>Update <code>dprint@latest</code> to 0.50.0.</p> </li> </ul> <h2>[2.51.2] - 2025-05-18</h2> <ul> <li>Update <code>syft@latest</code> to 1.25.1.</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
d16ffe5f0f |
chore(gui-client): make better use of vite as a bundler (#9148)
We already use `vite` as a bundling tool but only to rollup some of the pre-built files. This setup (and therefore our buildscripts) can be massively simplified by instructing `vite` to also build our TypeScript code and compile tailwind. This makes it much easier to develop locally because one only needs to run `pnpm vite build --watch` to keep everything up to date. |
||
|
Jamil
|
fbac6554e5 |
fix(ci): Increase setup-tauri timeout to 10 minutes (#9139)
These regularly take more than 5 minutes to run due to the number of deb packages to install. https://github.com/firezone/firezone/actions/runs/15024129636/job/42220517903?pr=9137 |
||
|
Thomas Eizinger
|
656f5db1d0 |
ci(rust): add timeout to GUI smoke tests (#9085)
These don't have an inherent timeout so the CI job gets stuck forever. They typically finish in about a minute. |
||
|
Thomas Eizinger
|
81ba49e2bf |
ci(rust): reorder static analysis (#9025)
Running `clippy` first is more useful because it provides better feedback around compile-errors. When working with cross-platform code, it is often the case that one needs to push to CI to ensure everything builds. Therefore, getting fast feedback is important. |
||
|
Thomas Eizinger
|
41cae2ed3b |
ci(rust): only run proptest's regression seeds on Windows (#9010)
GitHub's Windows runners are very slow. In order to not prolong CI runs too much, we set the number of _additional_ proptest cases for Windows to 0. This means we still run all the regression seeds that we've accumulated in `proptest-regressions/tests.txt` and simply don't generate any new ones on top of it. This is also a good benchmark to ensure that our regression seeds cover all cases that we are testing further down below using the coverage grepping. Related: #8948 |
||
|
Thomas Eizinger
|
f53e4419b8 |
ci(rust): run the default number of proptest cases (#8982)
By default, proptest runs all regression cases + 256 new ones. Given that we run the tests on 3 different operating systems in various versions each and that on each PR, we are likely hitting enough different cases to detect any bugs. Related: #8948 |
||
|
dependabot[bot]
|
b1408ebbff |
build(deps): bump taiki-e/install-action from 2.49.50 to 2.50.4 (#8971)
Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.49.50 to 2.50.4. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's releases</a>.</em></p> <blockquote> <h2>2.50.4</h2> <ul> <li> <p>Update <code>typos@latest</code> to 1.31.2.</p> </li> <li> <p>Update <code>osv-scanner@latest</code> to 2.0.2.</p> </li> <li> <p>Update <code>cargo-nextest@latest</code> to 0.9.95.</p> </li> </ul> <h2>2.50.3</h2> <ul> <li>Update <code>cargo-zigbuild@latest</code> to 0.20.0.</li> </ul> <h2>2.50.2</h2> <ul> <li> <p>Update <code>cargo-lambda@latest</code> to 1.8.4.</p> </li> <li> <p>Update <code>syft@latest</code> to 1.23.1.</p> </li> </ul> <h2>2.50.1</h2> <ul> <li> <p>Update <code>syft@latest</code> to 1.23.0.</p> </li> <li> <p>Update <code>cargo-semver-checks@latest</code> to 0.41.0.</p> </li> </ul> <h2>2.50.0</h2> <ul> <li> <p>Support <code>taplo</code>. (<a href="https://redirect.github.com/taiki-e/install-action/pull/944">#944</a>, thanks <a href="https://github.com/vivienm"><code>@vivienm</code></a>)</p> </li> <li> <p>Update <code>wasmtime@latest</code> to 32.0.0.</p> </li> <li> <p>Update <code>release-plz@latest</code> to 0.3.133.</p> </li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's changelog</a>.</em></p> <blockquote> <h1>Changelog</h1> <p>All notable changes to this project will be documented in this file.</p> <p>This project adheres to <a href="https://semver.org">Semantic Versioning</a>.</p> <!-- raw HTML omitted --> <h2>[Unreleased]</h2> <h2>[2.50.4] - 2025-05-01</h2> <ul> <li> <p>Update <code>typos@latest</code> to 1.31.2.</p> </li> <li> <p>Update <code>osv-scanner@latest</code> to 2.0.2.</p> </li> <li> <p>Update <code>cargo-nextest@latest</code> to 0.9.95.</p> </li> </ul> <h2>[2.50.3] - 2025-04-26</h2> <ul> <li>Update <code>cargo-zigbuild@latest</code> to 0.20.0.</li> </ul> <h2>[2.50.2] - 2025-04-26</h2> <ul> <li> <p>Update <code>cargo-lambda@latest</code> to 1.8.4.</p> </li> <li> <p>Update <code>syft@latest</code> to 1.23.1.</p> </li> </ul> <h2>[2.50.1] - 2025-04-25</h2> <ul> <li> <p>Update <code>syft@latest</code> to 1.23.0.</p> </li> <li> <p>Update <code>cargo-semver-checks@latest</code> to 0.41.0.</p> </li> </ul> <h2>[2.50.0] - 2025-04-21</h2> <ul> <li> <p>Support <code>taplo</code>. (<a href="https://redirect.github.com/taiki-e/install-action/pull/944">#944</a>, thanks <a href="https://github.com/vivienm"><code>@vivienm</code></a>)</p> </li> <li> <p>Update <code>wasmtime@latest</code> to 32.0.0.</p> </li> <li> <p>Update <code>release-plz@latest</code> to 0.3.133.</p> </li> </ul> <h2>[2.49.50] - 2025-04-16</h2> <ul> <li>Update <code>grcov@latest</code> to 0.9.1.</li> </ul> <h2>[2.49.49] - 2025-04-13</h2> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
8a201494d0 |
ci: remove flaky Windows benchmark (#8941)
This tunnel throughput benchmark isn't a very useful benchmark and it is very flaky. Remove it entirely until we can replace it with something more robust and useful. Resolves: #8172 |
||
|
Thomas Eizinger
|
6114bb274f |
chore(rust): make most of the Rust code compile on MacOS (#8924)
When working on the Rust code of Firezone from a MacOS computer, it is useful to have pretty much all of the code at least compile to ensure detect problems early. Eventually, once we target features like a headless MacOS client, some of these stubs will actually be filled in an be functional. |
||
|
dependabot[bot]
|
6366339420 |
build(deps): bump taiki-e/install-action from 2.49.46 to 2.49.50 (#8821)
Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.49.46 to 2.49.50. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's releases</a>.</em></p> <blockquote> <h2>2.49.50</h2> <ul> <li>Update <code>grcov@latest</code> to 0.9.1.</li> </ul> <h2>2.49.49</h2> <ul> <li>Update <code>release-plz@latest</code> to 0.3.132.</li> </ul> <h2>2.49.48</h2> <ul> <li> <p>Update <code>release-plz@latest</code> to 0.3.131.</p> </li> <li> <p>Update <code>cargo-nextest@latest</code> to 0.9.94.</p> </li> <li> <p>Update <code>cargo-lambda@latest</code> to 1.8.3.</p> </li> </ul> <h2>2.49.47</h2> <ul> <li>Update <code>grcov@latest</code> to 0.9.0.</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's changelog</a>.</em></p> <blockquote> <h1>Changelog</h1> <p>All notable changes to this project will be documented in this file.</p> <p>This project adheres to <a href="https://semver.org">Semantic Versioning</a>.</p> <!-- raw HTML omitted --> <h2>[Unreleased]</h2> <ul> <li>Update <code>release-plz@latest</code> to 0.3.133.</li> </ul> <h2>[2.49.50] - 2025-04-16</h2> <ul> <li>Update <code>grcov@latest</code> to 0.9.1.</li> </ul> <h2>[2.49.49] - 2025-04-13</h2> <ul> <li>Update <code>release-plz@latest</code> to 0.3.132.</li> </ul> <h2>[2.49.48] - 2025-04-11</h2> <ul> <li> <p>Update <code>release-plz@latest</code> to 0.3.131.</p> </li> <li> <p>Update <code>cargo-nextest@latest</code> to 0.9.94.</p> </li> <li> <p>Update <code>cargo-lambda@latest</code> to 1.8.3.</p> </li> </ul> <h2>[2.49.47] - 2025-04-09</h2> <ul> <li>Update <code>grcov@latest</code> to 0.9.0.</li> </ul> <h2>[2.49.46] - 2025-04-08</h2> <ul> <li> <p>Update <code>espup@latest</code> to 0.15.0.</p> </li> <li> <p>Update <code>trunk@latest</code> to 0.21.13.</p> </li> </ul> <h2>[2.49.45] - 2025-04-06</h2> <ul> <li> <p>Update <code>knope@latest</code> to 0.19.2.</p> </li> <li> <p>Update <code>cargo-binstall@latest</code> to 1.12.3.</p> </li> </ul> <h2>[2.49.44] - 2025-04-03</h2> <ul> <li>Update <code>grcov@latest</code> to 0.8.24.</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
d560eb00fd |
chore(rust): remove resolved duplicated dependency exclusion (#8766)
We no longer have multiple versions of `tauri-winrt-notification` in our dependency tree and can therefore remove this exclusion rule. To ensure that we don't forget to update these in the future, we now deny the `unnecessary-skip` lint that warns us when we have one of those entries. |
||
|
Thomas Eizinger
|
abe3b54006 |
ci: only run 1000 proptest cases on Windows (#8768)
Windows runners are very slow on GitHub actions. The Rust tests on Windows are regularly the last CI job to finish. In order to speed up overall CI runtime, reduce the number of cases we run on Windows to 1000. It doesn't really matter which OS we run these on as the proptests are entirely platform-agnostic. We just need to get a good amount of testcases in on each CI run. |
||
|
dependabot[bot]
|
a87db29453 |
build(deps): bump taiki-e/install-action from 2.49.40 to 2.49.46 (#8706)
Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.49.40 to 2.49.46. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's releases</a>.</em></p> <blockquote> <h2>2.49.46</h2> <ul> <li> <p>Update <code>espup@latest</code> to 0.15.0.</p> </li> <li> <p>Update <code>trunk@latest</code> to 0.21.13.</p> </li> </ul> <h2>2.49.45</h2> <ul> <li> <p>Update <code>knope@latest</code> to 0.19.2.</p> </li> <li> <p>Update <code>cargo-binstall@latest</code> to 1.12.3.</p> </li> </ul> <h2>2.49.44</h2> <ul> <li> <p>Update <code>grcov@latest</code> to 0.8.24.</p> </li> <li> <p>Update <code>osv-scanner@latest</code> to 2.0.1.</p> </li> <li> <p>Update <code>release-plz@latest</code> to 0.3.130.</p> </li> <li> <p>Update <code>cargo-lambda@latest</code> to 1.8.1.</p> </li> <li> <p>Downgrade <code>cargo-spellcheck@latest</code> to 0.15.1. (<a href="https://redirect.github.com/taiki-e/install-action/pull/932">#932</a>)</p> </li> </ul> <h2>2.49.43</h2> <ul> <li>Update <code>syft@latest</code> to 1.22.0.</li> </ul> <h2>2.49.42</h2> <ul> <li>Update <code>grcov@latest</code> to 0.8.23.</li> </ul> <h2>2.49.41</h2> <ul> <li>Update <code>mdbook@latest</code> to 0.4.48.</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's changelog</a>.</em></p> <blockquote> <h1>Changelog</h1> <p>All notable changes to this project will be documented in this file.</p> <p>This project adheres to <a href="https://semver.org">Semantic Versioning</a>.</p> <!-- raw HTML omitted --> <h2>[Unreleased]</h2> <h2>[2.49.46] - 2025-04-08</h2> <ul> <li> <p>Update <code>espup@latest</code> to 0.15.0.</p> </li> <li> <p>Update <code>trunk@latest</code> to 0.21.13.</p> </li> </ul> <h2>[2.49.45] - 2025-04-06</h2> <ul> <li> <p>Update <code>knope@latest</code> to 0.19.2.</p> </li> <li> <p>Update <code>cargo-binstall@latest</code> to 1.12.3.</p> </li> </ul> <h2>[2.49.44] - 2025-04-03</h2> <ul> <li> <p>Update <code>grcov@latest</code> to 0.8.24.</p> </li> <li> <p>Update <code>osv-scanner@latest</code> to 2.0.1.</p> </li> <li> <p>Update <code>release-plz@latest</code> to 0.3.130.</p> </li> <li> <p>Update <code>cargo-lambda@latest</code> to 1.8.1.</p> </li> <li> <p>Downgrade <code>cargo-spellcheck@latest</code> to 0.15.1. (<a href="https://redirect.github.com/taiki-e/install-action/pull/932">#932</a>)</p> </li> </ul> <h2>[2.49.43] - 2025-04-01</h2> <ul> <li>Update <code>syft@latest</code> to 1.22.0.</li> </ul> <h2>[2.49.42] - 2025-04-01</h2> <ul> <li>Update <code>grcov@latest</code> to 0.8.23.</li> </ul> <h2>[2.49.41] - 2025-04-01</h2> <ul> <li>Update <code>mdbook@latest</code> to 0.4.48.</li> </ul> <h2>[2.49.40] - 2025-03-31</h2> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
dependabot[bot]
|
14a4d12ceb |
build(deps): bump taiki-e/install-action from 2.49.9 to 2.49.40 (#8597)
Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.49.9 to 2.49.40. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's releases</a>.</em></p> <blockquote> <h2>2.49.40</h2> <ul> <li>Update <code>typos@latest</code> to 1.31.1.</li> </ul> <h2>2.49.39</h2> <ul> <li>Downgrade <code>cargo-lambda@latest</code> to 1.8.0. (<a href="https://redirect.github.com/taiki-e/install-action/pull/923">#923</a>)</li> </ul> <h2>2.49.38</h2> <ul> <li> <p>Update <code>cargo-lambda@latest</code> to 1.8.1.</p> </li> <li> <p>Update <code>typos@latest</code> to 1.31.0.</p> </li> <li> <p>Update <code>trunk@latest</code> to 0.21.12.</p> </li> </ul> <h2>2.49.37</h2> <ul> <li>Update <code>trunk@latest</code> to 0.21.11.</li> </ul> <h2>2.49.36</h2> <ul> <li> <p>Update <code>release-plz@latest</code> to 0.3.129.</p> </li> <li> <p>Update <code>protoc@latest</code> to 3.30.2.</p> </li> </ul> <h2>2.49.35</h2> <ul> <li> <p>Update <code>cargo-nextest@latest</code> to 0.9.93.</p> </li> <li> <p>Update <code>typos@latest</code> to 1.30.3.</p> </li> <li> <p>Update <code>wash@latest</code> to 0.41.0.</p> </li> </ul> <h2>2.49.34</h2> <ul> <li>Update <code>knope@latest</code> to 0.19.0.</li> </ul> <h2>2.49.33</h2> <ul> <li>Update <code>release-plz@latest</code> to 0.3.128.</li> </ul> <h2>2.49.32</h2> <ul> <li>Update <code>wasmtime@latest</code> to 31.0.0.</li> </ul> <h2>2.49.31</h2> <ul> <li> <p>Update <code>cargo-hack@latest</code> to 0.6.36.</p> </li> <li> <p>Update <code>cargo-binstall@latest</code> to 1.12.2.</p> </li> </ul> <h2>2.49.30</h2> <ul> <li>Update <code>dprint@latest</code> to 0.49.1.</li> </ul> <h2>2.49.29</h2> <ul> <li> <p>Update <code>syft@latest</code> to 1.21.0.</p> </li> <li> <p>Update <code>release-plz@latest</code> to 0.3.127.</p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's changelog</a>.</em></p> <blockquote> <h1>Changelog</h1> <p>All notable changes to this project will be documented in this file.</p> <p>This project adheres to <a href="https://semver.org">Semantic Versioning</a>.</p> <!-- raw HTML omitted --> <h2>[Unreleased]</h2> <ul> <li>Update <code>mdbook@latest</code> to 0.4.48.</li> </ul> <h2>[2.49.40] - 2025-03-31</h2> <ul> <li>Update <code>typos@latest</code> to 1.31.1.</li> </ul> <h2>[2.49.39] - 2025-03-30</h2> <ul> <li>Downgrade <code>cargo-lambda@latest</code> to 1.8.0. (<a href="https://redirect.github.com/taiki-e/install-action/pull/923">#923</a>)</li> </ul> <h2>[2.49.38] - 2025-03-29</h2> <ul> <li> <p>Update <code>cargo-lambda@latest</code> to 1.8.1.</p> </li> <li> <p>Update <code>typos@latest</code> to 1.31.0.</p> </li> <li> <p>Update <code>trunk@latest</code> to 0.21.12.</p> </li> </ul> <h2>[2.49.37] - 2025-03-27</h2> <ul> <li>Update <code>trunk@latest</code> to 0.21.11.</li> </ul> <h2>[2.49.36] - 2025-03-27</h2> <ul> <li> <p>Update <code>release-plz@latest</code> to 0.3.129.</p> </li> <li> <p>Update <code>protoc@latest</code> to 3.30.2.</p> </li> </ul> <h2>[2.49.35] - 2025-03-25</h2> <ul> <li> <p>Update <code>cargo-nextest@latest</code> to 0.9.93.</p> </li> <li> <p>Update <code>typos@latest</code> to 1.30.3.</p> </li> <li> <p>Update <code>wash@latest</code> to 0.41.0.</p> </li> </ul> <h2>[2.49.34] - 2025-03-24</h2> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
3c7ac084c0 |
feat(relay): MVP for routing channel data message in eBPF kernel (#8496)
## Abstract This pull-request implements the first stage of off-loading routing of TURN data channel messages to the kernel via an eBPF XDP program. In particular, the eBPF kernel implemented here **only** handles the decapsulation of IPv4 data channel messages into their embedded UDP payload. Implementation of other data paths, such as the receiving of UDP traffic on an allocation and wrapping it in a TURN channel data message is deferred to a later point for reasons explained further down. As it stands, this PR implements the bare minimum for us to start experimenting and benefiting from eBPF. It is already massive as it is due to the infrastructure required for actually doing this. Let's dive into it! ## A refresher on TURN channel-data messages TURN specifies a channel-data message for relaying data between two peers. A channel data message has a fixed 4-byte header: - The first two bytes specify the channel number - The second two bytes specify the length of the encapsulated payload Like all TURN traffic, channel data messages run over UDP by default, meaning this header sits at the very front of the UDP payload. This will be important later. After making an allocation with a TURN server (i.e. reserving a port on the TURN server's interfaces), a TURN client can bind channels on that allocation. As such, channel numbers are scoped to a client's allocation. Channel numbers are allocated by the client within a given range (0x4000 - 0x4FFF). When binding a channel, the client specifies the remote's peer address that they'd like the data sent on the channel to be sent to. Given this setup, when a TURN server receives a channel data message, it first looks at the sender's IP + port to infer the allocation (a client can only ever have 1 allocation at a time). Within that allocation, the server then looks for the channel number and retrieves the target socket address from that. The allocation itself is a port on the relay's interface. With that, we can now "unpack" the payload of the channel data message and rewrite it to the new receiver: - The new source IP can be set from the old dst IP (when operating in user-space mode this is irrelevant because we are working with the socket API). - The new source port is the client's allocation. - The new destination IP is retrieved from the mapping retrieved via the channel number. - The new destination port is retrieved from the mapping retrieved via the channel number. Last but not least, all that is left is removing the channel data header from the UDP payload and we can send out the packet. In other words, we need to cut off the first 4 bytes of the UDP payload. ## User-space relaying At present, we implement the above flow in user-space. This is tricky to do because we need to bind _many_ sockets, one for each possible allocation port (of which there can be 16383). The actual work to be done on these packets is also extremely minimal. All we do is cut off (or add on) the data-channel header. Benchmarks show that we spend pretty much all of our time copying data between user-space and kernel-space. Cutting this out should give us a massive increase in performance. ## Implementing an eBPF XDP TURN router eBPF has been shown to be a very efficient way of speeding up a TURN server [0]. After many failed experiments (e.g. using TC instead of XDP) and countless rabbit-holes, we have also arrived at the design documented within the paper. Most notably: - The eBPF program is entirely optional. We try to load it on startup, but if that fails, we will simply use the user-space mode. - Retaining the user-space mode is also important because under certain circumstances, the eBPF kernel needs to pass on the packet, for example, when receiving IPv4 packets with options. Those make the header dynamically-sized which makes further processing difficult because the eBPF verifier disallows indexing into the packet with data derived from the packet itself. - In order to add/remove the channel-data header, we shift the packet headers backwards / forwards and leave the payload in place as the packet headers are constant in size and can thus easily and cheaply be copied out. In order to perform the relaying flow explained above, we introduce maps that are shared with user-space. These maps go from a tuple of (client-socket, channel-number) to a tuple of (allocation-port, peer-socket) and thus give us all the data necessary to rewrite the packet. ## Integration with our relay Last but not least, to actually integrate the eBPF kernel with our relay, we need to extend the `Server` with two more events so we can learn, when channel bindings are created and when they expire. Using these events, we can then update the eBPF maps accordingly and therefore influence the routing behaviour in the kernel. ## Scope What is implemented here is only one of several possible data paths. Implementing the others isn't conceptually difficult but it does increase the scope. Landing something that already works allows us to gain experience running it in staging (and possibly production). Additionally, I've hit some issues with the eBPF verifier when adding more codepaths to the kernel. I expect those to be possible to resolve given sufficient debugging but I'd like to do so after merging this. --- Depends-On: #8506 Depends-On: #8507 Depends-On: #8500 Resolves: #8501 [0]: https://dl.acm.org/doi/pdf/10.1145/3609021.3609296 |
||
|
Thomas Eizinger
|
9ab4507182 |
ci(rust): install nightly toolchain (#8507)
For #8501, we need to install a nightly toolchain in our CI system in order to compile to eBPF kernel. We already use a nightly toolchain for one of the static analysis tools. In this PR, we extend our `setup-rust` action to install the nightly toolchain for us which allows us to reuse that later. |
||
|
Jamil
|
931048a667 |
chore(connlib): Remove manual expansion of search domain (#8443)
Reverts part of #8378 so that our OS-native expansion takes effect on all platforms. --------- Co-authored-by: Thomas Eizinger <thomas@eizinger.io> |
||
|
Thomas Eizinger
|
39e272cfd1 |
refactor(rust): introduce dns-types crate (#8380)
A sizeable chunk of Firezone's Rust components deal with parsing, manipulating and emitting DNS queries and responses. The API surface of DNS is quite large and to make handling of all corner-cases easier, we depend on the `domain` library to do the heavy-lifting for us. For better or worse, `domain` follows a lazy-parsing approach. Thus, creating a new DNS message doesn't actually verify that it is in fact valid. Within Firezone, we make several assumptions around DNS messages, such as that they will only ever contain a single question. Historically, DNS allows for multiple questions per query but in practise, nobody uses that. Due to how we handle DNS in Firezone, manipulating these messages happens in multiple places. That combined with the lazy-parsing approach from `domain` warrants having our own `dns-types` library that wraps `domain` and provides us with types that offer the interface we need in the rest of the codebase. Resolves: #7019 |
||
|
Thomas Eizinger
|
6d87bb4009 |
feat(connlib): expand single-label queries using search-domain (#8378)
Search domains are a way of performing a DNS lookup without typing the full-qualified domain name. For example, with a search domain of `example.com`, performing a DNS query for `app` will automatically expand the query to `app.example.com`. At present, this doesn't work with Firezone because there is no way to configure an account-wide search-domain. With this PR, we extend the `Interface` message sent by the portal to also include an optional `search_domain` field that must be a valid domain name. If set, `connlib`'s DNS stub resolver will now append this domain to all single-label queries and match the resulting domain against all active DNS resource. On Linux - with `systemd-resolved` as the DNS backend - we need to set the search domain on the TUN interface as well and enable LLMNR in order to be able to intercept these queries. `resolved` expands the query for us, however, meaning with this configuration, we don't actually receive a single-label query in `connlib`. Instead, we directly see `app.example.com` when we type `host app` or `dig +search app` and have `example.com` as our search domain. MacOS has a similar system but with a different fallack. There, the operating system will first try all configured search domains on the system (typically just the ones set prior to Firezone starting), and send queries for FQDN to all resolvers. If none of the resolvers (including Firezone's stub resolver) return results, it sends the single-label query directly to the primary resolver. To handle this case, Firezone needs to know about the search-domain and expand it itself when it receives the single-label query. In the future, we may want to look into how we can configure MacOS such that it performs this expansion for us. On Windows and Android, queries for a single-label domain will be directly sent to Firezone's stub resolver where we then hit the same codepath as explained above. Specifically, the way this codepath works is that if we receive a single-label query AND we have a search-domain set, we expand it and match that particular query against our list of resources. In every other case, we continue on with the single-label domain. Related: #8365 Fixes: #8377 |
||
|
Thomas Eizinger
|
99d8fcb8fc |
feat(connlib): resolve SRV & TXT queries for resources in sites (#8335)
## Description We want to resolve DNS queries of type SRV & TXT for DNS resources within the network context of the site that is hosting the DNS resource itself. This allows admins to e.g. deploy dedicated nameservers into those sites and have them resolve their SRV and TXT records to names that are scoped to that particular site. SRV records themselves return more domains which - if they are configured as DNS resources - will be intercepted and then routed to the correct site. Prior to this PR, SRV & TXT records got resolved by the DNS server configured on the client (or the server defined in the Firezone portal), even if the domain in question was a DNS resource. This effectively meant that those SRV records have to be valid globally and could not be specific to the site that the DNS resource is hosted in. ## Example Say we have these wildcard DNS resources: - `**.department-a.example.com` - `**.department-b.example.com` Each of these DNS resources is assigned to a different site. If we now issue an SRV DNS query to `_my-service.department-a.example.com`, we may receive back the following records: - `_my-service.department-a.example.com. 86400 IN SRV 10 60 8080 my-service1.department-a.example.com.` - `_my-service.department-a.example.com. 86400 IN SRV 10 60 8080 my-service2.department-a.example.com.` - `_my-service.department-a.example.com. 86400 IN SRV 10 60 8080 my-service3.department-a.example.com.` Notice how the SRV records point to domains that will also match the wildcard DNS resource above! If that is the case, Firezone will also intercept A & AAAA queries for this service (which are a natural follow-up from an application making an SRV query). As a result, traffic for `my-service1.department-a.example.com` will be routed to the same site the DNS resource is defined in. If the returned domains don't match the wildcard DNS resource, the traffic will either not be intercepted at all (if it is not a DNS resource) or routed to whichever site defines the corresponding DNS resource. All of these scenarios may be what the admin wants. If the SRV records defined for the DNS resource are globally valid (and e.g. not even resources), then resolving them using the Client's system resolver may be all that is needed. If the services are running in a dedicated site, that traffic should indeed be routed to that site. As such, Firezone itself cannot make any assumption about the structure of these records at all. The only thing that is enabled with this PR is that IF the structure happens to match the same DNS resource, it allows admins to deploy site-specific services that resolve their concrete domains via SRV records. ## Testing The implementation is tested using our property-based testing framework. In order to cover these cases, we introduce the notion of site-specific DNS records which are sampled when we create each individual Gateway. When selecting a domain to query for, all global DNS records and the site-specific ones are merged and a domain name and query type is chosen at random. At present, this testing framework does not assert that the DNS response itself is correct, i.e. that it actually returned the site-specific record. We don't assert this for any other DNS queries, hence this is left for a future extension. We do assert using our regression grep's that we hit the codepath of querying an SRV or TXT record for a DNS resource. Related: #8221 |
||
|
dependabot[bot]
|
9972352e9d |
build(deps): bump taiki-e/install-action from 2.47.32 to 2.49.9 (#8314)
Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.47.32 to 2.49.9. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's releases</a>.</em></p> <blockquote> <h2>2.49.9</h2> <ul> <li>Update <code>typos@latest</code> to 1.30.0.</li> </ul> <h2>2.49.8</h2> <ul> <li> <p>Update <code>cargo-binstall@latest</code> to 1.11.2.</p> </li> <li> <p>Update <code>cargo-audit@latest</code> to 0.21.2.</p> </li> </ul> <h2>2.49.7</h2> <ul> <li>Update <code>cargo-deny@latest</code> to 0.18.1.</li> </ul> <h2>2.49.6</h2> <ul> <li>Update <code>cargo-lambda@latest</code> to 1.7.0.</li> </ul> <h2>2.49.5</h2> <ul> <li> <p>Update <code>wasmtime@latest</code> to 30.0.2.</p> </li> <li> <p>Update <code>release-plz@latest</code> to 0.3.123.</p> </li> </ul> <h2>2.49.4</h2> <ul> <li>Update <code>typos@latest</code> to 1.29.10.</li> </ul> <h2>2.49.3</h2> <ul> <li> <p>Update <code>wash@latest</code> to 0.39.0.</p> </li> <li> <p>Update <code>cargo-nextest@latest</code> to 0.9.92.</p> </li> </ul> <h2>2.49.2</h2> <ul> <li> <p>Update <code>sccache@latest</code> to 0.10.0.</p> </li> <li> <p>Update <code>cargo-machete@latest</code> to 0.8.0.</p> </li> </ul> <h2>2.49.1</h2> <ul> <li>Update <code>cargo-deny@latest</code> to 0.18.0.</li> </ul> <h2>2.49.0</h2> <ul> <li>Allow installing pre-release versions using binstall. (<a href="https://redirect.github.com/taiki-e/install-action/pull/868">#868</a>)</li> </ul> <h2>2.48.22</h2> <ul> <li> <p>Update <code>cargo-binstall@latest</code> to 1.11.1.</p> </li> <li> <p>Update <code>release-plz@latest</code> to 0.3.122.</p> </li> </ul> <h2>2.48.21</h2> <ul> <li> <p>Update <code>wasmtime@latest</code> to 30.0.1.</p> </li> <li> <p>Update <code>syft@latest</code> to 1.20.0.</p> </li> </ul> <h2>2.48.20</h2> <ul> <li>Update <code>cargo-udeps@latest</code> to 0.1.55.</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's changelog</a>.</em></p> <blockquote> <h1>Changelog</h1> <p>All notable changes to this project will be documented in this file.</p> <p>This project adheres to <a href="https://semver.org">Semantic Versioning</a>.</p> <!-- raw HTML omitted --> <h2>[Unreleased]</h2> <h2>[2.49.9] - 2025-03-01</h2> <ul> <li>Update <code>typos@latest</code> to 1.30.0.</li> </ul> <h2>[2.49.8] - 2025-02-28</h2> <ul> <li> <p>Update <code>cargo-binstall@latest</code> to 1.11.2.</p> </li> <li> <p>Update <code>cargo-audit@latest</code> to 0.21.2.</p> </li> </ul> <h2>[2.49.7] - 2025-02-27</h2> <ul> <li>Update <code>cargo-deny@latest</code> to 0.18.1.</li> </ul> <h2>[2.49.6] - 2025-02-27</h2> <ul> <li>Update <code>cargo-lambda@latest</code> to 1.7.0.</li> </ul> <h2>[2.49.5] - 2025-02-25</h2> <ul> <li> <p>Update <code>wasmtime@latest</code> to 30.0.2.</p> </li> <li> <p>Update <code>release-plz@latest</code> to 0.3.123.</p> </li> </ul> <h2>[2.49.4] - 2025-02-25</h2> <ul> <li>Update <code>typos@latest</code> to 1.29.10.</li> </ul> <h2>[2.49.3] - 2025-02-25</h2> <ul> <li> <p>Update <code>wash@latest</code> to 0.39.0.</p> </li> <li> <p>Update <code>cargo-nextest@latest</code> to 0.9.92.</p> </li> </ul> <h2>[2.49.2] - 2025-02-25</h2> <ul> <li>Update <code>sccache@latest</code> to 0.10.0.</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |