mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-28 02:18:50 +00:00
8ca43300cdc43d3f6897dfbbbb3304593e201459
2175 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
391e94ebed |
fix(relay): set a Firezone ID to enable feature-flags (#8657)
Our feature-flags are currently coupled to our Firezone ID. Without a Firezone ID, we cannot evaluate feature flags. In order to be able to use the feature flags to enable / disable the eBPF TURN router, we see a random UUID as the Firezone ID upon startup of the relay. Not setting this causes the eBPF router to currently be instantly disabled as soon as we start up because the default of the feature flag is false and we don't reevaluate it later due to the missing ID. |
||
|
|
6fe7e77f76 |
refactor(relay): fail if eBPF offloading is requested but fails (#8656)
It happens a bunch of times to me during testing that I'd forget to set the right interface onto which the eBPF kernel should be loaded and was wondering why it didn't work. Defaulting to `eth0` wasn't a very smart decision because it means users cannot disable the eBPF kernel at all (other than via the feature-flag). It makes more sense to default to not loading the program at all AND hard-fail if we are requested to load it but cannot. This allows us to catch configuration errors early. |
||
|
|
cd94dd8a2c | fix(relay): update cached eBPF config when it changes (#8655) | ||
|
|
941ef6c668 |
feat(relay): introduce feature-flag for toggling eBPF program (#8650)
This PR implements a feature-flag in PostHog that we can use to toggle the use of the eBPF data plane at runtime. At every tick of the event-loop, the relay will compare the (cached) configuration of the eBPF program with the (cached) value of the feature-flag. If they differ, the flag will be updated and upon the next packet, the eBPF program will act accordingly. Feature-flags are re-evaluated every 5 minutes, meaning there is some delay until this gets applied. The default value of our all our feature-flags is `false`, meaning if there is some problem with evaluating them, we'd turn the eBPF data plane off. Performing routing in userspace is slower but it is a safer default. Resolves: #8548 |
||
|
|
f0a6367c7f |
refactor(eBPF): rename slice_mut_at module (#8634)
The name `slice_mut_at` came from a time where this function actually returned a slice of bytes. It has since been refactored to return a mutable reference to a type T that gets set by the caller. Thus, `ref_mut_at` is a much more fitting name. |
||
|
|
3ce3c03291 |
fix(telemetry): introduce staging and prod PostHog projects (#8647)
As per PostHog's recommendation [0], we now use different projects to manage the feature-flags. This allows us to turn feature flags in staging or production on / off without affecting the other. [0]: https://posthog.com/tutorials/multiple-environments |
||
|
|
ebb71e0f54 |
fix(relay): increase page size for metrics to 4096 (#8646)
The default here is 2 which is nowhere near enough of a batch-size for us to read all perf events generated by the kernel when it is actually relaying data via eBPF (we generate 1 perf event per relayed packet). If we don't read them fast enough, the kernel has to drop some, meaning we skew our metrics as to how much data we've relayed via eBPF. This has been tested in my local setup and I've seen north of 500 events being read in a single batch now. --------- Signed-off-by: Thomas Eizinger <thomas@eizinger.io> |
||
|
|
818b97a3a6 |
build(deps): bump flowbite from 3.1.1 to 3.1.2 in /rust/gui-client (#8579)
Bumps [flowbite](https://github.com/themesberg/flowbite) from 3.1.1 to 3.1.2. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/themesberg/flowbite/releases">flowbite's releases</a>.</em></p> <blockquote> <h2>v3.1.2</h2> <ul> <li>create new theme file to move CSS variables</li> <li>update quickstart guide to reflect this change</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
|
a532d6033c |
build(deps): bump @tailwindcss/cli from 4.0.9 to 4.0.17 in /rust/gui-client (#8575)
Bumps [@tailwindcss/cli](https://github.com/tailwindlabs/tailwindcss/tree/HEAD/packages/@tailwindcss-cli) from 4.0.9 to 4.0.17. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/tailwindlabs/tailwindcss/releases"><code>@tailwindcss/cli</code>'s releases</a>.</em></p> <blockquote> <h2>v4.0.17</h2> <h3>Fixed</h3> <ul> <li>Fix an issue causing the CLI to hang when processing Ruby files (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17383">#17383</a>)</li> </ul> <h2>v4.0.16</h2> <h3>Added</h3> <ul> <li>Add support for literal values in <code>--value('…')</code> and <code>--modifier('…')</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17304">#17304</a>)</li> </ul> <h3>Fixed</h3> <ul> <li>Fix class extraction followed by <code>(</code> in Pug (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17320">#17320</a>)</li> <li>Ensure <code>@keyframes</code> for theme animations are emitted if they are referenced following a comma (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17352">#17352</a>)</li> <li>Vite: Ensure that updates to an imported CSS file are properly propagated after updating source files (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17347">#17347</a>)</li> <li>Pre process <code>Slim</code> templates embedded in Ruby files (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17336">#17336</a>)</li> <li>Error when input and output files resolve to the same file when using the CLI (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17311">#17311</a>)</li> <li>Add missing suggestions when <code>--spacing(--value(integer, number))</code> is used (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17308">#17308</a>)</li> <li>Add <code>::-webkit-details-marker</code> pseudo to <code>marker</code> variant (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17362">#17362</a>)</li> </ul> <h2>v4.0.15</h2> <h3>Fixed</h3> <ul> <li>Fix incorrect angle in <code>-bg-conic-*</code> utilities (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17174">#17174</a>)</li> <li>Fix <code>border-[12px_4px]</code> being interpreted as a <code>border-color</code> instead of a <code>border-width</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17248">#17248</a>)</li> <li>Work around a crash in Safari 16.4 and 16.5 when using the default Preflight styles (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17306">#17306</a>)</li> <li>Pre-process <code>\<template lang="…"></code> in Vue files (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17252">#17252</a>)</li> <li>Ensure that all CSS variables used by Preflight are prefixed (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17036">#17036</a>)</li> <li>Prevent segfault when loaded in a worker thread on Linux (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17276">#17276</a>)</li> <li>Ensure multiple <code>--value(…)</code> or <code>--modifier(…)</code> calls don't delete subsequent declarations (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17273">#17273</a>)</li> <li>Fix class extraction followed by <code>(</code> in Slim (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17278">#17278</a>)</li> <li>Export <code>PluginUtils</code> from <code>tailwindcss/plugin</code> for compatibility with v3 (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17299">#17299</a>)</li> <li>Remove redundant <code>line-height: initial</code> from Preflight (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/15212">#15212</a>)</li> <li>Increase Standalone hardware compatibility on macOS x64 builds (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17267">#17267</a>)</li> <li>Ensure that the CSS file rebuilds if a new CSS variable is used from templates (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17301">#17301</a>)</li> </ul> <h3>Changed</h3> <ul> <li>The <code>--theme(…)</code> function now returns CSS variables from your theme variables unless used inside positions where CSS variables are invalid (e.g. inside <code>@media</code> queries) (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17036">#17036</a>)</li> </ul> <h2>v4.0.14</h2> <h3>Fixed</h3> <ul> <li>Do not extract candidates with JS string interpolation <code>${</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17142">#17142</a>)</li> <li>Fix extraction of variants containing <code>.</code> character (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17153">#17153</a>)</li> <li>Fix extracting candidates in Clojure/ClojureScript (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17087">#17087</a>)</li> </ul> <h2>v4.0.13</h2> <h3>Fixed</h3> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/tailwindlabs/tailwindcss/blob/main/CHANGELOG.md"><code>@tailwindcss/cli</code>'s changelog</a>.</em></p> <blockquote> <h2>[4.0.17] - 2025-03-26</h2> <h3>Fixed</h3> <ul> <li>Fix an issue causing the CLI to hang when processing Ruby files (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17383">#17383</a>)</li> </ul> <h2>[4.0.16] - 2025-03-25</h2> <h3>Added</h3> <ul> <li>Add support for literal values in <code>--value('…')</code> and <code>--modifier('…')</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17304">#17304</a>)</li> </ul> <h3>Fixed</h3> <ul> <li>Fix class extraction followed by <code>(</code> in Pug (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17320">#17320</a>)</li> <li>Ensure <code>@keyframes</code> for theme animations are emitted if they are referenced following a comma (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17352">#17352</a>)</li> <li>Vite: Ensure that updates to an imported CSS file are properly propagated after updating source files (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17347">#17347</a>)</li> <li>Pre process <code>Slim</code> templates embedded in Ruby files (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17336">#17336</a>)</li> <li>Error when input and output files resolve to the same file when using the CLI (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17311">#17311</a>)</li> <li>Add missing suggestions when <code>--spacing(--value(integer, number))</code> is used (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17308">#17308</a>)</li> <li>Add <code>::-webkit-details-marker</code> pseudo to <code>marker</code> variant (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17362">#17362</a>)</li> </ul> <h2>[4.0.15] - 2025-03-20</h2> <h3>Fixed</h3> <ul> <li>Fix incorrect angle in <code>-bg-conic-*</code> utilities (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17174">#17174</a>)</li> <li>Fix <code>border-[12px_4px]</code> being interpreted as a <code>border-color</code> instead of a <code>border-width</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17248">#17248</a>)</li> <li>Work around a crash in Safari 16.4 and 16.5 when using the default Preflight styles (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17306">#17306</a>)</li> <li>Pre-process <code>\<template lang="…"></code> in Vue files (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17252">#17252</a>)</li> <li>Ensure that all CSS variables used by Preflight are prefixed (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17036">#17036</a>)</li> <li>Prevent segfault when loaded in a worker thread on Linux (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17276">#17276</a>)</li> <li>Ensure multiple <code>--value(…)</code> or <code>--modifier(…)</code> calls don't delete subsequent declarations (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17273">#17273</a>)</li> <li>Fix class extraction followed by <code>(</code> in Slim (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17278">#17278</a>)</li> <li>Export <code>PluginUtils</code> from <code>tailwindcss/plugin</code> for compatibility with v3 (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17299">#17299</a>)</li> <li>Remove redundant <code>line-height: initial</code> from Preflight (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/15212">#15212</a>)</li> <li>Increase Standalone hardware compatibility on macOS x64 builds (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17267">#17267</a>)</li> <li>Ensure that the CSS file rebuilds if a new CSS variable is used from templates (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17301">#17301</a>)</li> </ul> <h3>Changed</h3> <ul> <li>The <code>--theme(…)</code> function now returns CSS variables from your theme variables unless used inside positions where CSS variables are invalid (e.g. inside <code>@media</code> queries) (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17036">#17036</a>)</li> </ul> <h2>[4.0.14] - 2025-03-13</h2> <h3>Fixed</h3> <ul> <li>Do not extract candidates with JS string interpolation <code>${</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17142">#17142</a>)</li> <li>Fix extraction of variants containing <code>.</code> character (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17153">#17153</a>)</li> <li>Fix extracting candidates in Clojure/ClojureScript (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17087">#17087</a>)</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
|
dce5ab9178 | build(deps): bump Rust to 1.86 (#8636) | ||
|
|
b318dd060f |
build(deps): bump tauri-plugin-shell from 2.2.0 to 2.2.1 in /rust in the cargo group (#8625)
Bumps the cargo group in /rust with 1 update: [tauri-plugin-shell](https://github.com/tauri-apps/plugins-workspace). Updates `tauri-plugin-shell` from 2.2.0 to 2.2.1 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/tauri-apps/plugins-workspace/releases">tauri-plugin-shell's releases</a>.</em></p> <blockquote> <h2>opener-js v2.2.1</h2> <h2>[2.2.1]</h2> <ul> <li><a href=" |
||
|
|
27a1d59451 |
chore(relay): Add xdp-tools debug Docker image build script (#8591)
This contains useful utilities like `xdpdump` which can be used on the Relays to debug eBPF codepaths. Build this on the Relays themselves can take prohibitively long, so this image has been pushed to `us-east1-docker.pkg.dev/firezone-staging/firezone/xdp-tools:latest`. |
||
|
|
634c5ee38f |
refactor(eBPF): reuse CdHdr struct (#8635)
Instead of passing just a 4-byte array, we can pass a `CdHdr` struct that we have already defined. This is more type-safe and correctly captures the invariant of the order of fields in the header. |
||
|
|
2b1527b48c |
chore(eBPF): warn when dropping packets (#8630)
When we decide to drop a packet, it means something is seriously off and we should look into it. These warnings will propagate to userspace and trigger a warning that gets reported to Sentry (if telemetry is enabled). |
||
|
|
b863febac8 |
chore(eBPF): fix bad error message (#8629)
Not sure how this one snuck in there. Must have made a mistake with my multi-line cursors. |
||
|
|
6a83b06f9e |
feat(eBPF): log Ethernet header update (#8632)
Similar to IPv4, IPv6 and UDP, this adds a debug log describing how we are updating the Ethernet header of a packet. --------- Signed-off-by: Thomas Eizinger <thomas@eizinger.io> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> |
||
|
|
0ecb8c7f6b |
build(deps): use released version of arboard (#8637)
|
||
|
|
8ee1cb9e89 |
feat(telemetry): include environment in decide request (#8616)
This allows us to toggle feature-flags based on environments. |
||
|
|
7f0bb08225 |
build(deps-dev): bump tailwindcss from 4.0.9 to 4.0.17 in /rust/gui-client (#8576)
Bumps [tailwindcss](https://github.com/tailwindlabs/tailwindcss/tree/HEAD/packages/tailwindcss) from 4.0.9 to 4.0.17. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/tailwindlabs/tailwindcss/releases">tailwindcss's releases</a>.</em></p> <blockquote> <h2>v4.0.17</h2> <h3>Fixed</h3> <ul> <li>Fix an issue causing the CLI to hang when processing Ruby files (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17383">#17383</a>)</li> </ul> <h2>v4.0.16</h2> <h3>Added</h3> <ul> <li>Add support for literal values in <code>--value('…')</code> and <code>--modifier('…')</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17304">#17304</a>)</li> </ul> <h3>Fixed</h3> <ul> <li>Fix class extraction followed by <code>(</code> in Pug (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17320">#17320</a>)</li> <li>Ensure <code>@keyframes</code> for theme animations are emitted if they are referenced following a comma (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17352">#17352</a>)</li> <li>Vite: Ensure that updates to an imported CSS file are properly propagated after updating source files (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17347">#17347</a>)</li> <li>Pre process <code>Slim</code> templates embedded in Ruby files (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17336">#17336</a>)</li> <li>Error when input and output files resolve to the same file when using the CLI (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17311">#17311</a>)</li> <li>Add missing suggestions when <code>--spacing(--value(integer, number))</code> is used (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17308">#17308</a>)</li> <li>Add <code>::-webkit-details-marker</code> pseudo to <code>marker</code> variant (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17362">#17362</a>)</li> </ul> <h2>v4.0.15</h2> <h3>Fixed</h3> <ul> <li>Fix incorrect angle in <code>-bg-conic-*</code> utilities (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17174">#17174</a>)</li> <li>Fix <code>border-[12px_4px]</code> being interpreted as a <code>border-color</code> instead of a <code>border-width</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17248">#17248</a>)</li> <li>Work around a crash in Safari 16.4 and 16.5 when using the default Preflight styles (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17306">#17306</a>)</li> <li>Pre-process <code>\<template lang="…"></code> in Vue files (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17252">#17252</a>)</li> <li>Ensure that all CSS variables used by Preflight are prefixed (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17036">#17036</a>)</li> <li>Prevent segfault when loaded in a worker thread on Linux (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17276">#17276</a>)</li> <li>Ensure multiple <code>--value(…)</code> or <code>--modifier(…)</code> calls don't delete subsequent declarations (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17273">#17273</a>)</li> <li>Fix class extraction followed by <code>(</code> in Slim (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17278">#17278</a>)</li> <li>Export <code>PluginUtils</code> from <code>tailwindcss/plugin</code> for compatibility with v3 (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17299">#17299</a>)</li> <li>Remove redundant <code>line-height: initial</code> from Preflight (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/15212">#15212</a>)</li> <li>Increase Standalone hardware compatibility on macOS x64 builds (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17267">#17267</a>)</li> <li>Ensure that the CSS file rebuilds if a new CSS variable is used from templates (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17301">#17301</a>)</li> </ul> <h3>Changed</h3> <ul> <li>The <code>--theme(…)</code> function now returns CSS variables from your theme variables unless used inside positions where CSS variables are invalid (e.g. inside <code>@media</code> queries) (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17036">#17036</a>)</li> </ul> <h2>v4.0.14</h2> <h3>Fixed</h3> <ul> <li>Do not extract candidates with JS string interpolation <code>${</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17142">#17142</a>)</li> <li>Fix extraction of variants containing <code>.</code> character (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17153">#17153</a>)</li> <li>Fix extracting candidates in Clojure/ClojureScript (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17087">#17087</a>)</li> </ul> <h2>v4.0.13</h2> <h3>Fixed</h3> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/tailwindlabs/tailwindcss/blob/main/CHANGELOG.md">tailwindcss's changelog</a>.</em></p> <blockquote> <h2>[4.0.17] - 2025-03-26</h2> <h3>Fixed</h3> <ul> <li>Fix an issue causing the CLI to hang when processing Ruby files (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17383">#17383</a>)</li> </ul> <h2>[4.0.16] - 2025-03-25</h2> <h3>Added</h3> <ul> <li>Add support for literal values in <code>--value('…')</code> and <code>--modifier('…')</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17304">#17304</a>)</li> </ul> <h3>Fixed</h3> <ul> <li>Fix class extraction followed by <code>(</code> in Pug (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17320">#17320</a>)</li> <li>Ensure <code>@keyframes</code> for theme animations are emitted if they are referenced following a comma (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17352">#17352</a>)</li> <li>Vite: Ensure that updates to an imported CSS file are properly propagated after updating source files (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17347">#17347</a>)</li> <li>Pre process <code>Slim</code> templates embedded in Ruby files (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17336">#17336</a>)</li> <li>Error when input and output files resolve to the same file when using the CLI (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17311">#17311</a>)</li> <li>Add missing suggestions when <code>--spacing(--value(integer, number))</code> is used (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17308">#17308</a>)</li> <li>Add <code>::-webkit-details-marker</code> pseudo to <code>marker</code> variant (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17362">#17362</a>)</li> </ul> <h2>[4.0.15] - 2025-03-20</h2> <h3>Fixed</h3> <ul> <li>Fix incorrect angle in <code>-bg-conic-*</code> utilities (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17174">#17174</a>)</li> <li>Fix <code>border-[12px_4px]</code> being interpreted as a <code>border-color</code> instead of a <code>border-width</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17248">#17248</a>)</li> <li>Work around a crash in Safari 16.4 and 16.5 when using the default Preflight styles (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17306">#17306</a>)</li> <li>Pre-process <code>\<template lang="…"></code> in Vue files (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17252">#17252</a>)</li> <li>Ensure that all CSS variables used by Preflight are prefixed (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17036">#17036</a>)</li> <li>Prevent segfault when loaded in a worker thread on Linux (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17276">#17276</a>)</li> <li>Ensure multiple <code>--value(…)</code> or <code>--modifier(…)</code> calls don't delete subsequent declarations (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17273">#17273</a>)</li> <li>Fix class extraction followed by <code>(</code> in Slim (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17278">#17278</a>)</li> <li>Export <code>PluginUtils</code> from <code>tailwindcss/plugin</code> for compatibility with v3 (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17299">#17299</a>)</li> <li>Remove redundant <code>line-height: initial</code> from Preflight (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/15212">#15212</a>)</li> <li>Increase Standalone hardware compatibility on macOS x64 builds (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17267">#17267</a>)</li> <li>Ensure that the CSS file rebuilds if a new CSS variable is used from templates (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17301">#17301</a>)</li> </ul> <h3>Changed</h3> <ul> <li>The <code>--theme(…)</code> function now returns CSS variables from your theme variables unless used inside positions where CSS variables are invalid (e.g. inside <code>@media</code> queries) (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17036">#17036</a>)</li> </ul> <h2>[4.0.14] - 2025-03-13</h2> <h3>Fixed</h3> <ul> <li>Do not extract candidates with JS string interpolation <code>${</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17142">#17142</a>)</li> <li>Fix extraction of variants containing <code>.</code> character (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17153">#17153</a>)</li> <li>Fix extracting candidates in Clojure/ClojureScript (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/17087">#17087</a>)</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
|
af220119f2 |
build(deps-dev): bump vite from 6.2.3 to 6.2.4 in /rust/gui-client (#8577)
Bumps [vite](https://github.com/vitejs/vite/tree/HEAD/packages/vite) from 6.2.3 to 6.2.4. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/vitejs/vite/releases">vite's releases</a>.</em></p> <blockquote> <h2>v6.2.4</h2> <p>Please refer to <a href="https://github.com/vitejs/vite/blob/v6.2.4/packages/vite/CHANGELOG.md">CHANGELOG.md</a> for details.</p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/vitejs/vite/blob/v6.2.4/packages/vite/CHANGELOG.md">vite's changelog</a>.</em></p> <blockquote> <h2><!-- raw HTML omitted -->6.2.4 (2025-03-31)<!-- raw HTML omitted --></h2> <ul> <li>fix: fs check in transform middleware (<a href="https://github.com/vitejs/vite/tree/HEAD/packages/vite/issues/19761">#19761</a>) (<a href=" |
||
|
|
aba3ab87d8 |
build(deps): bump the tauri group in /rust/gui-client with 2 updates (#8573)
Bumps the tauri group in /rust/gui-client with 2 updates: [@tauri-apps/api](https://github.com/tauri-apps/tauri) and [@tauri-apps/cli](https://github.com/tauri-apps/tauri). Updates `@tauri-apps/api` from 2.3.0 to 2.4.0 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/tauri-apps/tauri/releases"><code>@tauri-apps/api</code>'s releases</a>.</em></p> <blockquote> <h2><code>@tauri-apps/api</code> v2.4.0</h2> <!-- raw HTML omitted --> <pre><code>No known vulnerabilities found </code></pre> <!-- raw HTML omitted --> <h2>[2.4.0]</h2> <h3>New Features</h3> <ul> <li><a href=" |
||
|
|
40fb7d0565 |
fix(eBPF): explicitly attach in SKB mode (#8628)
It appears that the gVNIC driver in Google Cloud doesn't give us enough headroom to use `bpf_xdp_adjust_head` with a delta of 4 bytes. Currently, we are loading the XDP program with default flags. By loading it explicitly in SKB mode, we should be able to bypass these driver limitations at the expense of some performance (which should still be better than userspace!). Related: https://github.com/GoogleCloudPlatform/compute-virtual-ethernet-linux/issues/70 |
||
|
|
8c55c2a46a |
chore(eBPF): include return value in errors (#8626)
At present, we only check for the return value of the various helper functions and bail out if they fail. What we don't learn is what the actual return code is. To further help with debugging, we include the return code in the error so we can print it later. We can't use the formatting macro within the `write` function so we need to stitch the message together ourselves. |
||
|
|
d00995a91e |
fix(eBPF): drop messed up packets (#8618)
In case any of the xdp store/adjust/load functions fail, we need to drop the packet. By the time we get to these functions, we have already overwrote the Ethernet, IP and UDP headers and would only need to copy them either forwards or backwards to get rid of or add the channel data header. Forwarding these packets to userspace is pointless. |
||
|
|
4afcdf1c53 |
test(windows): Expect 80 Mbps on slow actions runners (#8621)
These are still failing a good portion of the time: https://github.com/firezone/firezone/actions/runs/14226461996/job/39867070540?pr=8620 |
||
|
|
e7cf00eb53 |
chore(relay): log when encountering unsupported channel mappings (#8617)
Currently, the relays eBPF module only supports routing from IPv4 to IPv4 as well as IPv6 to IPv6. In general, TURN servers can also route from IPv4 to IPv6 and vice versa. Our userspace routing supports that but doing the same in the eBPF code is a bit more involved. We'd need to move around the headers a bit more (IPv4 and IPv6 headers are different in size), as well as configure the respective "source" address for each interface. Currently, we simply take the destination address of the incoming packet as the new source address. When routing across IP versions, that doesn't work. To gain some more insight into how often this happens, we add these additional maps and populate them. This allows us to emit a dedicated log message whenever we encounter a packet for such a mapping. First, we always do check for an entry in the maps that we can handle. If we can't we check the other map and special-case the error. Otherwise, we fall back to the previous "no entry" error. We shouldn't really see these "no entry" errors anymore now, unless someone starts probing our relays for active channels. |
||
|
|
bac5cfa4cb |
fix(connlib): set idle timer to be longer than ICE timeout (#8612)
Our idle connection detection works based on incoming and outgoing packets, whichever one happened later. If we have not received or sent packets for longer than `MAX_IDLE`, we transition into idle mode where we configure our ICE agent to only send binding requests every 60 seconds. Our ICE timeout in non-idle mode is just north of 10 seconds (the formula is a bit tricky so don't have the accurate number). This can cause a problem whenever a Gateway disappears. We leave the idle mode as soon as we send a packet through the Gateway. Thus, what we intended to happen is that, as long as you keep trying to connect to the Gateway, we will leave the idle mode, increase our rate of STUN bindings through the ICE agent and detect within ~10s that the Gateway is gone. What actually happens is that, IF whatever resource you are trying to talk to is a DNS resource (which is very likely) and the application starts off with a DNS query, then we will reset the local DNS resource NAT state and ping the Gateway to set up the NAT again (we do this to ensure we don't have stale DNS entries on the Gateway). This message is only sent once and all other packets are buffered. Thus, the connection will go back to idle before the newly sent STUN binding requests can determine that the connection is actually broken. Resolves: #8551 |
||
|
|
4695f289a0 | chore(relay): add more logs to eBPF stats reporting (#8613) | ||
|
|
59453bd063 | chore(eBPF): improve log messages (#8611) | ||
|
|
fb1311991a |
fix(eBPF): correctly set Ethernet addresses (#8601)
At present, the eBPF code assumes that the incoming packet needs to be sent back to the same MAC address that it came from. This is only true if there is at least one IP layer hop in-between the relay and the Client / Gateway. When setting up Firezone in my local LAN to debug the eBPF code, all components are within the same subnet and thus can send packets directly to each other, without having to go through the router. In such a scenario, simply swapping the Ethernet addresses is not correct. As part of witnessing traffic coming in via the network, we can build up a mapping of IP to MAC address. This mapping can then later be used to set the correct MAC address for a given destination IP. All of this functions entirely without interaction from userspace. Unless you are running in a LAN environment, most if not all IPs will point to the same MAC address (the one of the next IP layer hop, i.e. the router). For the very first packet that we want to relay, we will not have a MAC address for the destination IP. This doesn't matter though, we simply pass that packet up to userspace and handle it there. Pretty much all communication on the Internet is bi-directional because you need some kind of ACK. As soon as we receive the first ACK, e.g. the response to a binding request, we will learn the MAC address for the given target IP and the eBPF router can kick in for all packets going forward. Related: #7518 |
||
|
|
f71995f7a5 |
fix(eBPF): incorporate change in UDP payload into checksum (#8603)
The UDP checksum also includes the entire payload. Removing and adding bytes to the payload therefore needs to be reflected in the checksum update that we perform. When we add the channel data header, we need to add the bytes to the checksum and when we remove them, they need to be removed. Related: #7518 |
||
|
|
e58ec73bbc |
refactor(eBPF): imply XDP_TX from Ok(()) (#8604)
Currently, the eBPF code isn't consistent in how it handles XDP actions. For some cases, we return errors and then map them to `XDP_PASS` or `XDP_DROP`. For others, we return `Ok(XDP_PASS)`. This is unnecessarily hard to understand. We refactor the eBPF kernel to ALWAYS use `Error`s for all code-paths that don't end in `XDP_TX`, i.e. when we successfully modified the packet and want to send it back out. In addition, we also change the way we log these errors. Not all errors are equal and most `XDP_PASS` actions don't need to be logged. Those packets are simply passing through. Finally, we also introduce new checks in case any calls to the eBPF helper functions fail. Related: #7518 |
||
|
|
cff14b3da0 | feat(relay): make interface for eBPF program configurable (#8592) | ||
|
|
a942dee723 | chore(eBPF): don't count channel data header as relayed bytes (#8590) | ||
|
|
bb36156ea8 |
chore(eBPF): remove commented out codeblock (#8588)
This is a leftover from debugging trying to make the verifier happy. |
||
|
|
db76cc3844 |
fix(relay): reduce memory usage of eBPF program to < 100MB (#8587)
At present, the eBPF program would try to pre-allocate around 800MB of memory for all entries in the maps. This would allow for 1 million channel mappings. We don't need that many to begin with. Reducing the max number of channels down to 65536 reduces our memory usage to less than 100MB. Related: #7518 --------- Signed-off-by: Thomas Eizinger <thomas@eizinger.io> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> |
||
|
|
1d0ecf94b8 |
feat(relay): record metrics about bytes relayed via eBPF (#8556)
Perf events are designed to be an extremely efficient way of transferring data from an eBPF kernel to the user-space program. In order to monitor, how much traffic we are actually relaying via eBPF, we introduce a dedicated `STATS` map that is a `PerfEventArray`. The events from that array are read asynchronously in user-space and fed into our OTEL metrics. They will show up in our Google Cloud metrics as `data_relayed_ebpf_bytes`. We already have a metric for the total relayed bytes. That counter is renamed to `data_relayed_userspace_bytes` so we can clearly differentiate the two. |
||
|
|
b51a68def0 |
feat(relay): implement eBPF routing for IPv6 (#8554)
This fills in the boilerplate for handling IPv6 packets in the eBPF code. Unfortunately, we cannot add an integration test for this because IPv6 doesn't have a checksum and thus doesn't allow the UDP checksum to be set to 0. Because Linux (and other OSs too I'd assume) offload UDP checksumming to the NIC yet on the loopback interface, the packets never get to the NIC, our eBPF code sees only a partial checksum and can thus updates the checksum incorrectly. Related: #7518 Related: #8502 --------- Signed-off-by: Thomas Eizinger <thomas@eizinger.io> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> |
||
|
|
9999027bc1 |
build(deps): bump resolv-conf from 0.7.0 to 0.7.1 in /rust (#8559)
Bumps [resolv-conf](https://github.com/hickory-dns/resolv-conf) from 0.7.0 to 0.7.1. <details> <summary>Commits</summary> <ul> <li>See full diff in <a href="https://github.com/hickory-dns/resolv-conf/commits">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
|
435f6c05cb |
build(deps): bump clap from 4.5.28 to 4.5.34 in /rust (#8557)
Bumps [clap](https://github.com/clap-rs/clap) from 4.5.28 to 4.5.34. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/clap-rs/clap/releases">clap's releases</a>.</em></p> <blockquote> <h2>v4.5.34</h2> <h2>[4.5.34] - 2025-03-27</h2> <h3>Fixes</h3> <ul> <li><em>(help)</em> Don't add extra blank lines with <code>flatten_help(true)</code> and subcommands without arguments</li> </ul> <h2>v4.5.33</h2> <h2>[4.5.33] - 2025-03-26</h2> <h3>Fixes</h3> <ul> <li><em>(error)</em> When showing the usage of a suggestion for an unknown argument, don't show the group</li> </ul> <h2>v4.5.32</h2> <h2>[4.5.32] - 2025-03-10</h2> <h3>Features</h3> <ul> <li>Add <code>Error::remove</code></li> </ul> <h3>Documentation</h3> <ul> <li><em>(cookbook)</em> Switch from <code>humantime</code> to <code>jiff</code></li> <li><em>(tutorial)</em> Better cover required vs optional</li> </ul> <h3>Internal</h3> <ul> <li>Update <code>pulldown-cmark</code></li> </ul> <h2>v4.5.31</h2> <h2>[4.5.31] - 2025-02-24</h2> <h3>Features</h3> <ul> <li>Add <code>ValueParserFactory</code> for <code>Saturating<T></code></li> </ul> <h2>v4.5.30</h2> <h2>[4.5.30] - 2025-02-17</h2> <h3>Fixes</h3> <ul> <li><em>(assert)</em> Allow <code>num_args(0..=1)</code> to be used with <code>SetTrue</code></li> <li><em>(assert)</em> Clean up rendering of <code>takes_values</code> assertions</li> </ul> <h2>v4.5.29</h2> <h2>[4.5.29] - 2025-02-11</h2> <h3>Fixes</h3> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/clap-rs/clap/blob/master/CHANGELOG.md">clap's changelog</a>.</em></p> <blockquote> <h2>[4.5.34] - 2025-03-27</h2> <h3>Fixes</h3> <ul> <li><em>(help)</em> Don't add extra blank lines with <code>flatten_help(true)</code> and subcommands without arguments</li> </ul> <h2>[4.5.33] - 2025-03-26</h2> <h3>Fixes</h3> <ul> <li><em>(error)</em> When showing the usage of a suggestion for an unknown argument, don't show the group</li> </ul> <h2>[4.5.32] - 2025-03-10</h2> <h3>Features</h3> <ul> <li>Add <code>Error::remove</code></li> </ul> <h3>Documentation</h3> <ul> <li><em>(cookbook)</em> Switch from <code>humantime</code> to <code>jiff</code></li> <li><em>(tutorial)</em> Better cover required vs optional</li> </ul> <h3>Internal</h3> <ul> <li>Update <code>pulldown-cmark</code></li> </ul> <h2>[4.5.31] - 2025-02-24</h2> <h3>Features</h3> <ul> <li>Add <code>ValueParserFactory</code> for <code>Saturating<T></code></li> </ul> <h2>[4.5.30] - 2025-02-17</h2> <h3>Fixes</h3> <ul> <li><em>(assert)</em> Allow <code>num_args(0..=1)</code> to be used with <code>SetTrue</code></li> <li><em>(assert)</em> Clean up rendering of <code>takes_values</code> assertions</li> </ul> <h2>[4.5.29] - 2025-02-11</h2> <h3>Fixes</h3> <ul> <li>Change <code>ArgMatches::args_present</code> so not-present flags are considered not-present (matching the documentation)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
|
5e21d07727 |
build(deps): bump windows-service from 0.7.0 to 0.8.0 in /rust (#8558)
Bumps [windows-service](https://github.com/mullvad/windows-service-rs) from 0.7.0 to 0.8.0. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/mullvad/windows-service-rs/blob/main/CHANGELOG.md">windows-service's changelog</a>.</em></p> <blockquote> <h2>[0.8.0] - 2025-02-19</h2> <h3>Added</h3> <ul> <li>Add missing ServiceAccess flags <code>READ_CONTROL</code>, <code>WRITE_DAC</code> and <code>WRITE_OWNER</code>.</li> </ul> <h3>Changed</h3> <ul> <li>Upgrade <code>windows-sys</code> dependency to 0.59 and bump the MSRV to 1.60.0.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
|
a4851ee76f |
feat(relay): implement the reverse IPv4 eBPF code path (#8544)
This PR implements the "reverse path" of handling TURN traffic, i.e. UDP datagrams that arrive on an allocation port and need to be wrapped in a channel-data message to be sent to the TURN client. In order to achieve that, I had to rewrite most of the TURN code to not use the `etherparse` crate. I couldn't quite figure out the details but the eBPF verifier rejected my code in mysterious ways that I didn't understand. Commenting out random code-paths seemed to make it happy but all code-paths combined caused an error. Eventually, I decided that we simply have to use less abstractions to implement the same logic. All the "parsing" code is now using types inspired by `network-types`. The only modification here is that we use byte-arrays within our structs in order to directly receive them in big-endian ordering. `network-types` uses `u16`s and `u32`s which get interpreted as little-endian on x86. Instead of converting around between the endianness, constructing those values where we want them using the right endianness is deemed much simpler. I opened an issue with upstream which - if accepted - will allow us to remove our own structs and instead depend on upstream again. I also had to aggressively add `#[inline(always)]` to several functions, otherwise the compiler would not optimise away our function calls, causing the linker and / or eBPF verifier to fail. This PR also fixes numerous bugs that I've found in the already existing eBPF code. The number of bugs makes me question how this has been working so far at all! - We did not swap the Ethernet source and destination MAC address when re-routing the packet. The integration-test didn't catch this because it only operates on the loopback interface. Further testing on staging should allow us to confirm that this is indeed working now. - The UDP checksum update did not incorporate the new src and dst port. The integration-test didnt' catch that because it has UDP checksumming disabled. We need to have that disabled in the test because UDP checksumming is typically offloaded to the NIC and packets on the loopback interface never leave the device. Related: https://github.com/vadorovsky/network-types/issues/32. Related: #7518 |
||
|
|
ae157bce12 |
fix(relay): turn regression tests back on (#8541)
As part of iterating on #8496, the API of `relay::Server` had changed and I had commented out the regression tests to move quicker. In later iterations, those API changes were reverted but I forgot to uncomment them. |
||
|
|
8a8d314038 |
build(rust): use upstream version of aya-build (#8545)
The PR we have been waiting on got merged. |
||
|
|
afa6814ab4 |
chore(relay): ignore eBPF integration test (#8543)
This needs elevated privileges to run. Our current pattern for these is to set them as ignored. In CI, we run all tests, including the ignored ones. |
||
|
|
e231ba9407 |
fix(relay): update aya-build dependency to latest version (#8540)
As part of working on https://github.com/aya-rs/aya/pull/1228, which I am depending on in here I had to force-push which will break CI. Opening this to fix it. |
||
|
|
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 |
||
|
|
19c5bc530a |
feat(gateway): deprecate the NAT64 module (#8383)
At present, the Gateway implements a NAT64 conversion that can convert IPv4 packets to IPv6 and vice versa. Doing this efficiently creates a fair amount of complexity within our `ip-packet` crate. In addition, routing ICMP errors back through our NAT is also complicated by this because we may have to translate the packet embedded in the ICMP error as well. The NAT64 module was originally conceived as a result of the new stub resolver-based DNS architecture. When the Client resolves IPs for a domain, it doesn't know whether the domain will actually resolve to IPv4 AND IPv6 addresses so it simply assigns 4 of each to every domain. Thus, when receiving an IPv6 packet for such a DNS resource, the Gateway may only have IPv4 addresses available and can therefore not route the packet (unless it translates it). This problem is not novel. In fact, an IP being unroutable or a particular route disappearing happens all the time on the Internet. ICMP was conceived to handle this problem and it is doing a pretty good job at it. We can make use of that and simply return an ICMP unreachable error back to the client whenever it picks an IP that we cannot map to one that we resolved. In this PR, we leave all of the NAT64 code intact and only add a feature-flag that - when active - sends aforementioned ICMP error. While offline (and thus also for our tests), the feature-flag evaluates to false. It is however set to `true` in the backend, meaning on staging and later in production, we will send these ICMP errors. Once this is rolled out and indeed proving to be working as intended, we can simplify our codebase and rip out the NAT64 module. At that point, we will also have to adapt the test-suite. |
||
|
|
aa957be538 |
fix(connlib): only disable not-yet-disabled resources (#8525)
Didn't test this but I think the logic checks out (and our proptests should catch any bugs here). Fixes: #8523 |
||
|
|
f13234955a |
refactor(gui-client): simplify error handling (#8519)
As a follow-up from #7959, we can now simplify the error handling a fair bit as all codepaths that can fail in the client are threaded back to the main function. |