mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-28 10:18:51 +00:00
cfbdc301234db89e69ea2e05f30e4397aa00a423
134 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
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=" |
||
|
|
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. |
||
|
|
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 |
||
|
|
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 |
||
|
|
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. |
||
|
|
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 |
||
|
|
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=" |
||
|
|
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 |
||
|
|
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 |
||
|
|
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=" |
||
|
|
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 |
||
|
|
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>
|
||
|
|
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 |
||
|
|
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=" |
||
|
|
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. |
||
|
|
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. |
||
|
|
ec5c433f5b |
feat(ci): use larger runners for all jobs (#9646)
Append `-xlarge` to the previous runner labels to match new larger runners. |
||
|
|
692b61d159 | ci: move GUI smoke tests to tauri workflow (#9627) | ||
|
|
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=" |
||
|
|
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 |
||
|
|
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=" |
||
|
|
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=" |
||
|
|
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. |
||
|
|
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 |
||
|
|
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. |
||
|
|
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. |
||
|
|
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 |
||
|
|
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 |
||
|
|
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=" |
||
|
|
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 |
||
|
|
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. |
||
|
|
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=" |
||
|
|
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. |
||
|
|
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. |
||
|
|
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=" |
||
|
|
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=" |
||
|
|
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 |
||
|
|
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. |
||
|
|
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> |
||
|
|
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 |
||
|
|
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 |
||
|
|
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 |
||
|
|
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=" |
||
|
|
b8852b3e7a |
ci: attach Windows headless client to release (#8041)
This publishes the windows headless client using the same convention set forth by the linux headless client. Docs and website changes will come in a subsequent PR. Related: #3782 Resolves: #8046 |
||
|
|
087f73b867 |
build(deps): bump taiki-e/install-action from 2.47.30 to 2.47.32 (#7973)
Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.47.30 to 2.47.32. <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.47.32</h2> <ul> <li>Update <code>typos@latest</code> to 1.29.5.</li> </ul> <h2>2.47.31</h2> <ul> <li>Fix checksum error with <code>wash@0.38.0</code> on macOS. (They rebuilt binaries for some reason.)</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.47.32] - 2025-01-31</h2> <ul> <li>Update <code>typos@latest</code> to 1.29.5.</li> </ul> <h2>[2.47.31] - 2025-01-30</h2> <ul> <li>Fix checksum error with <code>wash@0.38.0</code> on macOS. (They rebuilt binaries for some reason.)</li> </ul> <h2>[2.47.30] - 2025-01-28</h2> <ul> <li> <p>Support <code>cargo-cyclonedx</code> on x86_64 Linux (musl).</p> </li> <li> <p>Support installing native binary for <code>cargo-cyclonedx</code> on AArch64 macOS. (Previously x86_64 macOS binary is used as fallback.)</p> </li> <li> <p>Update <code>cargo-cyclonedx@latest</code> to 0.5.7.</p> </li> </ul> <h2>[2.47.29] - 2025-01-28</h2> <ul> <li> <p>Support <code>cargo-semver-checks</code> on AArch64 Linux.</p> </li> <li> <p>Support <code>cargo-zigbuild</code> on x86_64 macOS.</p> </li> <li> <p>Support installing native binary for <code>mdbook</code> and <code>shellcheck</code> on AArch64 macOS. (Previously x86_64 macOS binary is used as fallback.)</p> </li> <li> <p>Support installing native binary for <code>just</code> and <code>sccache</code> on AArch64 Windows. (Previously x86_64 Windows binary is used as fallback.)</p> </li> <li> <p>Update <code>mdbook@latest</code> to 0.4.44.</p> </li> <li> <p>Update <code>cargo-semver-checks@latest</code> to 0.39.0.</p> </li> </ul> <h2>[2.47.28] - 2025-01-28</h2> <p>No change on the <code>install-action</code> itself.</p> <ul> <li> <p>Provide <code>install-action-manifest-schema</code> crate to access to the <code>install-action</code> manifests from Rust code. (<a href="https://redirect.github.com/taiki-e/install-action/pull/657">#657</a>, thanks <a href="https://github.com/NobodyXu"><code>@NobodyXu</code></a>)</p> <p>This is being considered for use to speed up <code>cargo-binstall</code> in the future.</p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
|
b0fb9e8c38 |
build(deps): bump taiki-e/install-action from 2.47.11 to 2.47.30 (#7915)
Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.47.11 to 2.47.30. <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.47.30</h2> <ul> <li> <p>Support <code>cargo-cyclonedx</code> on x86_64 Linux (musl).</p> </li> <li> <p>Support installing native binary for <code>cargo-cyclonedx</code> on AArch64 macOS. (Previously x86_64 macOS binary is used as fallback.)</p> </li> <li> <p>Update <code>cargo-cyclonedx@latest</code> to 0.5.7.</p> </li> </ul> <h2>2.47.29</h2> <ul> <li> <p>Support <code>cargo-semver-checks</code> on AArch64 Linux.</p> </li> <li> <p>Support <code>cargo-zigbuild</code> on x86_64 macOS.</p> </li> <li> <p>Support installing native binary for <code>mdbook</code> and <code>shellcheck</code> on AArch64 macOS. (Previously x86_64 macOS binary is used as fallback.)</p> </li> <li> <p>Support installing native binary for <code>just</code> and <code>sccache</code> on AArch64 Windows. (Previously x86_64 Windows binary is used as fallback.)</p> </li> <li> <p>Update <code>mdbook@latest</code> to 0.4.44.</p> </li> <li> <p>Update <code>cargo-semver-checks@latest</code> to 0.39.0.</p> </li> </ul> <h2>2.47.28</h2> <p>No change on the <code>install-action</code> itself.</p> <ul> <li> <p>Provide <code>install-action-manifest-schema</code> crate to access to the <code>install-action</code> manifests from Rust code. (<a href="https://redirect.github.com/taiki-e/install-action/pull/657">#657</a>, thanks <a href="https://github.com/NobodyXu"><code>@NobodyXu</code></a>)</p> <p>This is being considered for use to speed up <code>cargo-binstall</code> in the future.</p> </li> </ul> <h2>2.47.27</h2> <ul> <li> <p>Update <code>editorconfig-checker@latest</code> to 3.2.0.</p> </li> <li> <p>Update <code>cargo-lambda@latest</code> to 1.6.3.</p> </li> </ul> <h2>2.47.26</h2> <ul> <li>Update <code>wash@latest</code> to 0.38.0.</li> </ul> <h2>2.47.25</h2> <ul> <li> <p>Update <code>release-plz@latest</code> to 0.3.114.</p> </li> <li> <p>Update <code>git-cliff@latest</code> to 2.8.0.</p> </li> </ul> <h2>2.47.24</h2> <ul> <li> <p>Update <code>syft@latest</code> to 1.19.0.</p> </li> <li> <p>Update <code>just@latest</code> to 1.39.0.</p> </li> </ul> <h2>2.47.23</h2> <ul> <li>Update <code>wasmtime@latest</code> to 29.0.1.</li> </ul> <h2>2.47.22</h2> <ul> <li>Update <code>trunk@latest</code> to 0.21.7.</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.47.30] - 2025-01-28</h2> <ul> <li> <p>Support <code>cargo-cyclonedx</code> on x86_64 Linux (musl).</p> </li> <li> <p>Support installing native binary for <code>cargo-cyclonedx</code> on AArch64 macOS. (Previously x86_64 macOS binary is used as fallback.)</p> </li> <li> <p>Update <code>cargo-cyclonedx@latest</code> to 0.5.7.</p> </li> </ul> <h2>[2.47.29] - 2025-01-28</h2> <ul> <li> <p>Support <code>cargo-semver-checks</code> on AArch64 Linux.</p> </li> <li> <p>Support <code>cargo-zigbuild</code> on x86_64 macOS.</p> </li> <li> <p>Support installing native binary for <code>mdbook</code> and <code>shellcheck</code> on AArch64 macOS. (Previously x86_64 macOS binary is used as fallback.)</p> </li> <li> <p>Support installing native binary for <code>just</code> and <code>sccache</code> on AArch64 Windows. (Previously x86_64 Windows binary is used as fallback.)</p> </li> <li> <p>Update <code>mdbook@latest</code> to 0.4.44.</p> </li> <li> <p>Update <code>cargo-semver-checks@latest</code> to 0.39.0.</p> </li> </ul> <h2>[2.47.28] - 2025-01-28</h2> <p>No change on the <code>install-action</code> itself.</p> <ul> <li> <p>Provide <code>install-action-manifest-schema</code> crate to access to the <code>install-action</code> manifests from Rust code. (<a href="https://redirect.github.com/taiki-e/install-action/pull/657">#657</a>, thanks <a href="https://github.com/NobodyXu"><code>@NobodyXu</code></a>)</p> <p>This is being considered for use to speed up <code>cargo-binstall</code> in the future.</p> </li> </ul> <h2>[2.47.27] - 2025-01-28</h2> <ul> <li> <p>Update <code>editorconfig-checker@latest</code> to 3.2.0.</p> </li> <li> <p>Update <code>cargo-lambda@latest</code> to 1.6.3.</p> </li> </ul> <h2>[2.47.26] - 2025-01-27</h2> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
|
0f82001034 |
ci: Add macos-15 to Rust unit tests (#7729)
We try to unit test on each major platform we support in CI to reduce the possibility a specific OS has issues with our unit tests. Now that macos-15 is available in GitHub CI, it would be a good idea to add it to the mix. |
||
|
|
d26df944c0 |
ci: reference GitHub actions by hash (#7724)
To improve supply-chain security, reference all GitHub actions using the hash of the released tag. GitHub recommends to do this for third-party actions (https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-third-party-actions). In order to make our CI more deterministic, I opted to do it for all our actions. This means any change to our workflow configuration requires a source code change and thus passing CI on our end. Dependabot will automatically issue PRs for these actions and update the comment with the new version next to them. Resolves: #2497. |
||
|
|
30376cd79a |
fix(gateway): polish error handling in main (#7500)
Currently, the Gateway logs all errors that happen when the event-loop exits on ERROR level. This creates Sentry alerts for things like "Unauthorized" errors or "404 Not found". That isn't useful to us. To mitigate this, we polish the code a bit to only log an ERROR when we actually fail to setup something during startup (like the TUN device). In all other cases, we now log a more user-friendly message on INFO but still exit with the appropriate exit code (0 on CTRL+C, 1 on any other error). |
||
|
|
9073bddaef |
fix(gateway): translate ICMP destination unreachable errors (#7398)
## Context The Gateway implements a stateful NAT that translates the destination IP and source protocol of every packet that targets a DNS resource IP. This is necessary because the IPs for DNS resources are generated on the client without actually performing a DNS lookup, instead it always generates 4 IPv4 and 4 IPv6 addresses. On the Gateway, these IPs are then assigned in a round-robin fashion to the actual IPs that the domain resolves to, necessitating a NAT64/46 translation in case a domain only resolves to IPs of one family. A domain may resolve to a set of IPs but not all of these IPs may be routable. Whilst an arguably poor practise of the domain administrator, routing problems can occur for all kinds of reasons and are well handled on the wider Internet. When an IP packet cannot be routed further, the current routing node generates an ICMP error describing the routing failure and sends it back to the original sender. ICMP is a layer 4 protocol itself, same as TCP and UDP. As such, sending out a UDP packet may result in receiving an ICMP response. In order to allow the sender to learn, which packet failed to route, the ICMP error embeds parts of the original packet in its payload [0] [1]. The Gateway's NAT table uses parts of the layer 4 protocol as part of its key; the UDP and TCP source port and the ICMP echo request identifier (further referred to as "source protocol"). An ICMP error message doesn't have any of these, meaning the lookup in the NAT table currently fails and the ICMP error is silently dropped. A lot of software implements a happy-eyeballs approach and probs for IPv6 and IPv4 connectivity simulataneously. The absence of the ICMP errors confuses that algorithm as it detects the packet loss and starts retransmits instead of giving up. ## Solution Upon receiving an ICMP error on the Gateway, we now extract the partially embedded packet in the ICMP error payload. We use the destination IP and source protocol of _that_ packet for the lookup in the NAT table. This returns us the original (client-assigned) destination IP and source protocol. In order for the Gateway's NAT to be transparent, we need to patch the packet embedded in the ICMP error to use the original destination and source protocol. We also have to account for the fact that the original packet may have been translated with NAT64/46 and translate it back. Finally, we generate an ICMP error with the appropriate code and embed the patched packet in its payload. ## Test implementation To test that this works for all kind of combinations, we extend `tunnel_test` to sample a list of unreachable IPs from all IPs sampled for DNS resources. Upon receiving a packet for one of these IPs, the Gateway will send an ICMP error back instead of invoking its regular echo reply logic. On the client-side, upon receiving an ICMP error, we extract the originally failed packet from the body and treat it as a successful response. This may seem a bit hacky at first but is actually how operating systems would treat ICMP errors as well. For example, a `TcpSocket::connect` call (triggering a TCP SYN packet) may fail with an IO error if we receive an ICMP error packet. Thus, in a way, the original packet got answered, just not with what we expected. In addition, by treating these ICMP errors as responses to the original packet, we automatically perform other assertions on them, like ensuring that they come from the right IP address, that there are no unexpected packets etc. ## Test alternatives It is tricky to solve this in other ways in the test suite because at the time of generating a packet for a DNS resource, we don't know the actual IP that is being targeted by a certain proxy IP unless we'd start reimplementing the round-robin algorithm employed by the Gateway. To "test" the transparency of the NAT, we'd like to avoid knowing about these implementation details in the test. ## Future work In this PR, we currently only deal with "Destination Unreachable" ICMP errors. There are other ICMP messages such as ICMPv6's `PacketTooBig` or `ParameterProblem`. We should eventually handle these as well. They are being deferred because translating those between the different IP versions is only partially implemented and would thus require more work. The most pressing need is to translate destination unreachable errors to enable happy-eyeballs algorithms to work correctly. Resolves: #5614. Resolves: #6371. [0]: https://www.rfc-editor.org/rfc/rfc792 [1]: https://www.rfc-editor.org/rfc/rfc4443#section-3.1 |