mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-28 18:18:55 +00:00
32d18abb09ea538ef6a84e290c2ceadbf04dbaff
8 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
dependabot[bot]
|
510714ddcd |
build(deps): Bump clap from 4.5.1 to 4.5.2 in /rust (#4009)
Bumps [clap](https://github.com/clap-rs/clap) from 4.5.1 to 4.5.2. <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.2</h2> <h2>[4.5.2] - 2024-03-06</h2> <h3>Fixes</h3> <ul> <li><em>(macros)</em> Silence a warning</li> </ul> </blockquote> </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.2] - 2024-03-06</h2> <h3>Fixes</h3> <ul> <li><em>(macros)</em> Silence a warning</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Gabi
|
73823ecba0 |
Fix/firezone id handling (#2958)
fixes #2651 Wip because firezone portal doesn't handle names longer than 8 characters yet cc @AndrewDryga |
||
|
Jamil
|
b28e99cdab |
chore(ci): Use 1.0.0 as version base (#2949)
Fixes #2948 So it seems that it's easiest just to use an old-fashioned semver string. This means we'll need to keep a version matrix in the docs of which components are supported and for how long, but it's better than having different version schemes for different Firezone components altogether. |
||
|
Gabi
|
bc8f438a56 |
feat(connlib): directly send wireguard traffic instead of tunneling it through WebRTC datachannels (#2643)
This PR started as part of a degradation in performance for the gateways. The way to test performance in a realistic enviroment is using a GCP vm as a client and an AWS vm as a gateway with a single iperf server behind the gateway. Then the `iperf` results with current main: ``` Connecting to host 172.31.92.238, port 5201 Reverse mode, remote host 172.31.92.238 is sending [ 5] local 100.83.194.77 port 58426 connected to 172.31.92.238 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 1.01 MBytes 8.50 Mbits/sec [ 5] 1.00-2.00 sec 1.14 MBytes 9.59 Mbits/sec [ 5] 2.00-3.00 sec 699 KBytes 5.73 Mbits/sec [ 5] 3.00-4.00 sec 1.11 MBytes 9.31 Mbits/sec [ 5] 4.00-5.00 sec 664 KBytes 5.44 Mbits/sec [ 5] 5.00-6.00 sec 591 KBytes 4.84 Mbits/sec [ 5] 6.00-7.00 sec 722 KBytes 5.91 Mbits/sec [ 5] 7.00-8.00 sec 833 KBytes 6.83 Mbits/sec [ 5] 8.00-9.00 sec 738 KBytes 6.04 Mbits/sec [ 5] 9.00-10.00 sec 836 KBytes 6.85 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.06 sec 8.78 MBytes 7.32 Mbits/sec 3 sender [ 5] 0.00-10.00 sec 8.23 MBytes 6.90 Mbits/sec receiver iperf Done. ``` Most of the performance problems were due to using SCTP and DTLS. So I created a [fork](https://github.com/firezone/webrtc/tree/expose-new-endpoint) of webrtc that let us circumvent those, since we don't need them because we are depending on wireguard for encryption. With those changes much better throughput is achieved: ``` gabriel@cloudshell:~ (firezone-personal-instances)$ iperf3 -R -c 172.31.92.238 Connecting to host 172.31.92.238, port 5201 Reverse mode, remote host 172.31.92.238 is sending [ 5] local 100.83.194.77 port 51206 connected to 172.31.92.238 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 5.60 MBytes 47.0 Mbits/sec [ 5] 1.00-2.00 sec 17.2 MBytes 144 Mbits/sec [ 5] 2.00-3.00 sec 15.8 MBytes 132 Mbits/sec [ 5] 3.00-4.00 sec 14.8 MBytes 125 Mbits/sec [ 5] 4.00-5.00 sec 15.9 MBytes 133 Mbits/sec [ 5] 5.00-6.00 sec 15.8 MBytes 133 Mbits/sec [ 5] 6.00-7.00 sec 15.3 MBytes 128 Mbits/sec [ 5] 7.00-8.00 sec 15.6 MBytes 131 Mbits/sec [ 5] 8.00-9.00 sec 15.6 MBytes 131 Mbits/sec [ 5] 9.00-10.00 sec 16.0 MBytes 134 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.05 sec 151 MBytes 126 Mbits/sec 74 sender [ 5] 0.00-10.00 sec 148 MBytes 124 Mbits/sec receiver iperf Done ``` However, this is still worse than it was achieved with a previous commit(`21afdf0a9a113c996d60a63b2e8c8f32d3aeb87`): ``` gabriel@cloudshell:~ (firezone-personal-instances)$ iperf3 -R -c 172.31.92.238 Connecting to host 172.31.92.238, port 5201 Reverse mode, remote host 172.31.92.238 is sending [ 5] local 100.100.68.41 port 49762 connected to 172.31.92.238 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 6.14 MBytes 51.5 Mbits/sec [ 5] 1.00-2.00 sec 17.1 MBytes 144 Mbits/sec [ 5] 2.00-3.00 sec 22.8 MBytes 191 Mbits/sec [ 5] 3.00-4.00 sec 23.5 MBytes 197 Mbits/sec [ 5] 4.00-5.00 sec 23.0 MBytes 193 Mbits/sec [ 5] 5.00-6.00 sec 22.1 MBytes 185 Mbits/sec [ 5] 6.00-7.00 sec 23.0 MBytes 193 Mbits/sec [ 5] 7.00-8.00 sec 22.7 MBytes 190 Mbits/sec [ 5] 8.00-9.00 sec 21.0 MBytes 176 Mbits/sec [ 5] 9.00-10.00 sec 19.9 MBytes 167 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.05 sec 204 MBytes 170 Mbits/sec 127 sender [ 5] 0.00-10.00 sec 201 MBytes 169 Mbits/sec receiver ``` My profiling suggested that this is due to reading/writing packets happening in its own dedicated tasks. So much so that maybe in the future we should even consider spawning their own dedicated runtime so that those loops have a dedicated OS thread. Also, probably using a multi-queue interface will give us huge gains if we have a dedicated task for each queue(currently the interface is started as a multi-queue but a single file descriptor is used) for handling multiple concurrent clients. However, the changes proposed in this PR are good enough for now as long as performance don't degrade. In that line I will create a CI that reports the throughput using the local `docker-compose.yml` file that we should always check before merging, that is not the be all end all of the performance story but for smaller PRs the correlation to real world throughput should be enough. For bigger PRs we should manually test before merging for now, until we have a way in CI to spin up some realistic tests(note that vms should be in separate cloud enviroments, the same-cloud links are so reliable that we miss actual performance degradation due to dropped packets). On this note I'll write a small manual on how to conduct those tests with full current results that we should use always before merging new PRs that affect the hot-path. cc @thomaseizinger Finally, when testing these changes I found some flakiness regarding the re-connection path. So I changed things so that we cleanup connections only using wireguard's error(connection expiration). This is quite slow for now (~120 seconds) but in the future we can issue an ice restart each time wireguard keepalive expires(rekey timeout) so that we can restart connection each ~30 seconds and we can reduce the keepalive time out from the portal to accelerate it even more. And in the future we can get smarter about it. --------- Co-authored-by: Thomas Eizinger <thomas@eizinger.io> |
||
|
dependabot[bot]
|
0d1df924dc |
build(deps): Bump clap from 4.4.6 to 4.4.7 in /rust (#2525)
Bumps [clap](https://github.com/clap-rs/clap) from 4.4.6 to 4.4.7. <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.4.7] - 2023-10-24</h2> <h3>Performance</h3> <ul> <li>Reduced code size</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Jamil
|
2bca378f17 |
Allow data plane configuration at runtime (#2477)
## Changelog - Updates connlib parameter API_URL (formerly known under different names as `CONTROL_PLANE_URL`, `PORTAL_URL`, `PORTAL_WS_URL`, and friends) to be configured as an "advanced" or "hidden" feature at runtime so that we can test production builds on both staging and production. - Makes `AUTH_BASE_URL` configurable at runtime too - Moves `CONNLIB_LOG_FILTER_STRING` to be configured like this as well and simplifies its naming - Fixes a timing attack bug on Android when comparing the `csrf` token - Adds proper account ID validation to Android to prevent invalid URL parameter strings from being saved and used - Cleans up a number of UI / view issues on Android regarding typos, consistency, etc - Hides vars from from the `relay` CLI we may not want to expose just yet - `get_device_id()` is flawed for connlib components -- SMBios is rarely available. Data plane components now require a `FIREZONE_ID` now instead to use for upserting. Fixes #2482 Fixes #2471 --------- Signed-off-by: Jamil <jamilbk@users.noreply.github.com> Co-authored-by: Gabi <gabrielalejandro7@gmail.com> |
||
|
Jamil
|
fa57d66965 |
Publish Releases (#2344)
- rebuild and publish gateway and relay binaries to currently drafted release - re-tag current relay/gateway images and push to ghcr.io Stacked on #2341 to prevent conflicts Fixes #2223 Fixes #2205 Fixes #2202 Fixes #2239 ~~Still TODO: `arm64` images and binaries...~~ Edit: added via `cross-rs` |
||
|
Jamil
|
573124bd2f |
Document relay gateway client CLIs (#2424)
Fixes #2363 * Rename `relay` package to `firezone-relay` so that binaries outputted match the `firezone-*` cli naming scheme * Rename `firezone-headless-client` package to `firezone-linux-client` for consistency * Add READMEs for user-facing CLI components (there will also be docs later) |