mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 10:18:54 +00:00
33fdbd960cdb24e2e07e9a8ca9290908bb0cfb43
69 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
dependabot[bot]
|
33fdbd960c |
build(deps): Bump clap from 4.5.3 to 4.5.4 in /rust (#4433)
Bumps [clap](https://github.com/clap-rs/clap) from 4.5.3 to 4.5.4. <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.4</h2> <h2>[4.5.4] - 2024-03-25</h2> <h3>Fixes</h3> <ul> <li><em>(derive)</em> Allow non-literal <code>#[arg(id)]</code> attributes again</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.4] - 2024-03-25</h2> <h3>Fixes</h3> <ul> <li><em>(derive)</em> Allow non-literal <code>#[arg(id)]</code> attributes again</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
fb7f7c0b9a |
chore: apply lints consistently across workspace (#4357)
Motivated by: #4340. I also activated [`clippy::unnnecessary_wraps`](https://rust-lang.github.io/rust-clippy/master/#/unnecessary_wraps) which does create some false-positives for the platform-specific code but is IMO overall a net-positive. With the amount of Rust code and crates increasing, it is good to have tools point out simplifications like these as they are otherwise hard to spot, especially across crate boundaries. |
||
|
Gabi
|
ee34621ee8 |
chore(connlib): unit tests for additional fields in messages (#4337)
Fixes #4308 |
||
|
Jamil
|
228389882e |
refactor(connlib): delay initialization of Sockets until we have a tokio runtime (#4286)
Our sockets need to be initialized within a tokio runtime context. To achieve this, we don't actually initialize anything on `Sockets::new`. Instead, we call `rebind` within the constructor of `Tunnel` which already runs in a tokio context. Fixes: #4282 --------- Signed-off-by: Jamil <jamilbk@users.noreply.github.com> Co-authored-by: Thomas Eizinger <thomas@eizinger.io> Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com> |
||
|
Thomas Eizinger
|
e628fa5d06 |
refactor(connlib): implement new FFI guidelines (#4263)
This updates connlib to follow the new guidelines described in #4262. I only made the bare-minimum changes to the clients. With these changes `reconnect` should only be called when the network interface actually changed, meaning clients have to be updated to reflect that. |
||
|
Thomas Eizinger
|
8c1500d03e |
chore(connlib): tidy up logs and docs (#4265)
Wrong / outdated docs are worse than no docs. This PR removes some of these stale docs. We may add new docs at a later point again. |
||
|
Thomas Eizinger
|
e8f2320d08 |
fix(gateway): answer with empty list of addresses on DNS resolution failure (#4266)
Currently, a failure during DNS resolution results in the client hanging during the connection setup. Instead, we fall back to an empty list which results in an empty DNS query result for the client. That in turn will make most application consider the DNS request failed. As far as I know, we don't currently retry these DNS requests, meaning a user would have to sign-in and out again to fix this state. Whilst not ideal, I think this is a better behaviour and what we currently have where the initial connection just hangs. |
||
|
Thomas Eizinger
|
2a46fce574 |
refactor(connlib): remove Result return values from callbacks (#4158)
Currently, an error returned by `Tunnel::poll_next_event` is only logged. In other words, they are never fatal. This creates a tricky to understand relationship on what kind of errors should be returned from callbacks. Because connlib is used on multiple operating systems, it has no idea how fatal a particular error is. This PR removes all of these `Result` return values with the following consequences: - For Android, we now panic when a callback fails. This is a slight change in behaviour. I believe that previously, any exception thrown by a callback into Android was caught and returned as an error. Now, we panic because in the FFI layer, we don't have any information on how fatal the error is. For non-fatal errors, the Android app should simply not throw an exception. The panics will cause the connlib task to be shut down which triggers an `on_disconnect`. - For Swift, there is no behaviour change. The FFI layer already did not support `Result`s for those callbacks. I don't know how exceptions from Swift are translated across the FFI layer but there is no change to what we had before. - For the Tauri client: - I chose to log errors on ERROR level and continue gracefully for the DNS resolvers. - We panic in case the controller channel is full / closed. That should really never happen in practice though unless we are currently shutting down the app. Resolves: #4064. |
||
|
dependabot[bot]
|
baa2831664 |
build(deps): Bump clap from 4.5.2 to 4.5.3 in /rust (#4191)
Bumps [clap](https://github.com/clap-rs/clap) from 4.5.2 to 4.5.3. <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.3</h2> <h2>[4.5.3] - 2024-03-15</h2> <h3>Internal</h3> <ul> <li><em>(derive)</em> Update <code>heck</code></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.3] - 2024-03-15</h2> <h3>Internal</h3> <ul> <li><em>(derive)</em> Update <code>heck</code></li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
dependabot[bot]
|
5408838189 |
build(deps): Bump anyhow from 1.0.80 to 1.0.81 in /rust (#4195)
Bumps [anyhow](https://github.com/dtolnay/anyhow) from 1.0.80 to 1.0.81. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/dtolnay/anyhow/releases">anyhow's releases</a>.</em></p> <blockquote> <h2>1.0.81</h2> <ul> <li>Make backtrace support available when using -Dwarnings (<a href="https://redirect.github.com/dtolnay/anyhow/issues/354">#354</a>)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
62e082d47a |
refactor(connlib): make {Client,Gateway}State SANS-IO (#4096)
Resolves: #3929. |
||
|
Thomas Eizinger
|
9767bddcca |
feat(gateway): add HTTP health check (#4120)
This adds the same kind of HTTP health-check that is already present in the relay to the gateway. The health-check returns 200 OK for as long as the gateway is active. The gateway automatically shuts down on fatal errors (like authentication failures with the portal). To enable this, I've extracted a crate `http-health-check` that shares this code between the relay and the gateway. Resolves: #2465. --------- Signed-off-by: Thomas Eizinger <thomas@eizinger.io> Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com> |
||
|
Thomas Eizinger
|
407d20d817 |
refactor(connlib): use phoenix-channel crate for clients (#3682)
Depends-On: #4048. Depends-On: #4015. Resolves: #2158. --------- Co-authored-by: conectado <gabrielalejandro7@gmail.com> |
||
|
Thomas Eizinger
|
fdb33674cd |
refactor(connlib): introduce LoginUrl component (#4048)
Currently, we are passing a lot of data into `Session::connect`. Half of this data is only needed to construct the URL we will use to connect to the portal. We can simplify this by extracting a dedicated `LoginUrl` component that captures and validates this data early. Not only does this reduce the number of parameters we pass to `Session::connect`, it also reduces the number of failure cases we have to deal with in `Session::connect`. Any time the session fails, we have to call `onDisconnected` to inform the client. Thus, we should perform as much validation as we can early on. In other words, once `Session::connect` returns, the client should be able to expect that the tunnel is starting. |
||
|
Thomas Eizinger
|
4339030d03 |
refactor(phoenix-channel): reduce Error to fatal errors (#4015)
As part of doing https://github.com/firezone/firezone/pull/3682, we noticed that the handling of errors up to the clients needs to differentiate between fatal errors that require clearing the token vs not. Upon closer inspection of `phoenix_channel::Error`, it becomes obvious that the current design is not good here. In particular, we handle certain errors with retries internally but still expose those same errors. To make this more obvious, we reduce the public `Error` to the variants that are actually fatal. Those can really only be three: - HTTP client errors (those are by definition non-retryable) - Token expired - We have reached our max number of retries |
||
|
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=" |
||
|
Thomas Eizinger
|
0ed2480ac0 |
refactor(connlib): merge control_protocol::gateway into gateway module (#3984)
This separation doesn't really hold anymore as we already have an `impl Tunnel` and `impl GatewayState` within `gateway.rs`. It is easier to maintain if more gateway-specific things are in `gateway.rs`. Plus, once we integrate the portal connection into the tunnel, we can collapse a lot of these APIs. |
||
|
Andrew Dryga
|
bfe1fb0ff4 |
refactor(portal): unify format of error payloads in websocket connection (#3697)
Co-authored-by: Thomas Eizinger <thomas@eizinger.io> |
||
|
dependabot[bot]
|
beb5c3834d |
build(deps): Bump anyhow from 1.0.79 to 1.0.80 in /rust (#3765)
Bumps [anyhow](https://github.com/dtolnay/anyhow) from 1.0.79 to 1.0.80. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/dtolnay/anyhow/releases">anyhow's releases</a>.</em></p> <blockquote> <h2>1.0.80</h2> <ul> <li>Fix unused_imports warnings when compiled by rustc 1.78</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Gabi
|
77b00b3be9 |
feat(connlib): support resource updates from the portal (#3754)
This PR doesn't yet provide support for the update of upstream DNS but it does provide support for all the other resources update messages. Should comply with the description of issue #2022 but it doesn't respond to DNS upstream updates which is imply it should on the issue title --------- Signed-off-by: Gabi <gabrielalejandro7@gmail.com> Co-authored-by: Thomas Eizinger <thomas@eizinger.io> |
||
|
Gabi
|
5edd195320 |
refactor(connlib): unify peer storage (#3738)
Now that we have `&mut` access everywhere in the tunnel, the remaining shared-memory and locks are in how we store peers. To resolve this, we introduce a new `PeerStore` that allows us to look up peers by IP and by ID. |
||
|
Thomas Eizinger
|
e766407dfb |
feat!(portal): return relays as plain socket addresses (#3665)
Extracted out of #3391. We don't actually need this for #3391 though because we've added a compatibility layer during deserialization. But, it will be good to remove that compat layer at some point which means we have to return the addresses as plain socket addresses. Because that is a breaking change, I decided to extract this into a different PR. Co-authored-by: conectado <gabrielalejandro7@gmail.com> --------- Co-authored-by: conectado <gabrielalejandro7@gmail.com> |
||
|
Gabi
|
3d3e737ba3 |
refactor(connlib): replace webrtc-rs with snownet (#3391)
Co-authored-by: Thomas Eizinger <thomas@eizinger.io> Resolves: #3377. --------- Co-authored-by: Thomas Eizinger <thomas@eizinger.io> |
||
|
dependabot[bot]
|
97eb506bb3 |
build(deps): Bump tokio from 1.35.1 to 1.36.0 in /rust (#3561)
Bumps [tokio](https://github.com/tokio-rs/tokio) from 1.35.1 to 1.36.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/tokio-rs/tokio/releases">tokio's releases</a>.</em></p> <blockquote> <h2>Tokio v1.36.0</h2> <h1>1.36.0 (February 2nd, 2024)</h1> <h3>Added</h3> <ul> <li>io: add <code>tokio::io::Join</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6220">#6220</a>)</li> <li>io: implement <code>AsyncWrite</code> for <code>Empty</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6235">#6235</a>)</li> <li>net: add support for anonymous unix pipes (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6127">#6127</a>)</li> <li>net: add <code>UnixSocket</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6290">#6290</a>)</li> <li>net: expose keepalive option on <code>TcpSocket</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6311">#6311</a>)</li> <li>sync: add <code>{Receiver,UnboundedReceiver}::poll_recv_many</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6236">#6236</a>)</li> <li>sync: add <code>Sender::{try_,}reserve_many</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6205">#6205</a>)</li> <li>sync: add <code>watch::Receiver::mark_unchanged</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6252">#6252</a>)</li> <li>task: add <code>JoinSet::try_join_next</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6280">#6280</a>)</li> </ul> <h3>Changed</h3> <ul> <li>io: make <code>copy</code> cooperative (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6265">#6265</a>)</li> <li>io: make <code>repeat</code> and <code>sink</code> cooperative (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6254">#6254</a>)</li> <li>io: simplify check for empty slice (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6293">#6293</a>)</li> <li>process: use pidfd on Linux when available (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6152">#6152</a>)</li> <li>sync: use AtomicBool in broadcast channel future (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6298">#6298</a>)</li> </ul> <h3>Documented</h3> <ul> <li>io: clarify <code>clear_ready</code> docs (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6304">#6304</a>)</li> <li>net: document that <code>*Fd</code> traits on <code>TcpSocket</code> are unix-only (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6294">#6294</a>)</li> <li>sync: document FIFO behavior of <code>tokio::sync::Mutex</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6279">#6279</a>)</li> <li>chore: typographic improvements (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6262">#6262</a>)</li> <li>runtime: remove obsolete comment (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6303">#6303</a>)</li> <li>task: fix typo (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6261">#6261</a>)</li> </ul> <p><a href="https://redirect.github.com/tokio-rs/tokio/issues/6220">#6220</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6220">tokio-rs/tokio#6220</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6235">#6235</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6235">tokio-rs/tokio#6235</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6127">#6127</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6127">tokio-rs/tokio#6127</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6290">#6290</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6290">tokio-rs/tokio#6290</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6311">#6311</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6311">tokio-rs/tokio#6311</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6236">#6236</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6236">tokio-rs/tokio#6236</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6205">#6205</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6205">tokio-rs/tokio#6205</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6252">#6252</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6252">tokio-rs/tokio#6252</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6280">#6280</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6280">tokio-rs/tokio#6280</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6265">#6265</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6265">tokio-rs/tokio#6265</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6254">#6254</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6254">tokio-rs/tokio#6254</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6293">#6293</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6293">tokio-rs/tokio#6293</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6238">#6238</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6238">tokio-rs/tokio#6238</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6152">#6152</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6152">tokio-rs/tokio#6152</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6298">#6298</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6298">tokio-rs/tokio#6298</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6262">#6262</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6262">tokio-rs/tokio#6262</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6303">#6303</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6303">tokio-rs/tokio#6303</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6261">#6261</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6261">tokio-rs/tokio#6261</a></p> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Gabi
|
55e4fb100f |
fix(gateway): re-implement resource address resolution in eventloop (#3656)
Reimplements what #3654 reverted with a fix --------- Co-authored-by: Thomas Eizinger <thomas@eizinger.io> |
||
|
Reactor Scram
|
085351f455 |
revert: 3622 to fix failing DNS CI test (#3654)
Reverts #3622 I don't know why, but that change seemed to cause the `/etc/resolv.conf` test to fail in CI and I was thinking of the "roll back first" principle https://cloud.google.com/blog/products/gcp/reliable-releases-and-rollbacks-cre-life-lessons ~~I also change one `ping` in CI to `until ping`. This was an earlier attempt before I did the revert, and it seems safe to leave it in.~~ |
||
|
Thomas Eizinger
|
f42aa862a8 |
refactor(gateway): perform DNS resolution of resources in eventloop (#3622)
With #3391, constructing a new tunnel will no longer be `async` which makes DNS resolution the only `async` component of `set_peer_connection_request`. In general, adding resources as part of setting up a connection is a duplicated of the logic within `allow_access`. We solve both of these problems at once by moving the DNS resolution out of `connlib` into the `gateway` binary and perform it as part of the eventloop during a connection setup. |
||
|
Thomas Eizinger
|
6c2fdcfd0a | chore: bump Rust version to 1.76 (#3632) | ||
|
Thomas Eizinger
|
d550c9da89 |
refactor(connlib): remove unnecessary Serialize derive (#3595)
These messages are only deserialized, never serialized. The `derive` can thus be removed. Extracted from: #3391. |
||
|
Andrew Dryga
|
a211f96109 |
feat(portal): Broadcast state changes to connected clients and gateways (#2240)
# Gateways - [x] When Gateway Group is deleted all gateways should be disconnected - [x] When Gateway Group is updated (eg. routing) broadcast to all affected gateway to disconnect all the clients - [x] When Gateway is deleted it should be disconnected - [x] When Gateway Token is revoked all gateways that use it should be disconnected # Relays - [x] When Relay Group is deleted all relays should be disconnected - [x] When Relay is deleted it should be disconnected - [x] When Relay Token is revoked all gateways that use it should be disconnected # Clients - [x] Remove Delete Client button, show clients using the token on the Actors page (#2669) - [x] When client is deleted disconnect it - [ ] ~When Gateway is offline broadcast to the Clients connected to it it's status~ - [x] Persist `last_used_token_id` in Clients and show it in tokens UI # Resources - [x] When Resource is deleted it should be removed from all gateways and clients - [x] When Resource connection is removed it should be deleted from removed gateway groups - [x] When Resource is updated (eg. traffic filters) all it's authorizations should removed # Authentication - [x] When Token is deleted related sessions are terminated - [x] When an Actor is deleted or disabled it should be disconnected from browser and client - [x] When Identity is deleted it's sessions should be disconnected from browser and client - [x] ^ Ensure the same happens for identities during IdP sync - [x] When IdP is disabled act like all actors for it are disabled? - [x] When IdP is deleted act like all actors for it are deleted? # Authorization - [x] When Policy is created clients that gain access to a resource should get an update - [x] When Policy is deleted we need to all authorizations it's made - [x] When Policy is disabled we need to all authorizations it's made - [x] When Actor Group adds or removes a user, related policies should be re-evaluated - [x] ^ Ensure the same happens for identities during IdP sync # Settings - [x] Re-send init message to Client when DNS settings change # Code - [x] Crear way to see all available topics and messages, do not use binary topics any more --------- Co-authored-by: conectado <gabrielalejandro7@gmail.com> |
||
|
Thomas Eizinger
|
35cdf84578 |
feat(gateway): don't print stacktrace upon exit (#3404)
Previously, we would print the following whenever the gateway exits:
```
2024-01-25T17:37:53.258145Z INFO init{user_agent="Alpine Linux/3.19.0 (x86_64;6.6.11;) connlib/1.0.0" login_topic="gateway"}: phoenix_channel: Connected to portal, waiting for `init` message
2024-01-25T17:37:53.260751Z WARN init{user_agent="Alpine Linux/3.19.0 (x86_64;6.6.11;) connlib/1.0.0" login_topic="gateway"}: phoenix_channel: Fatal client error (401 Unauthorized) in portal connection: Invalid token
Error: websocket failed
Caused by:
HTTP error: 401 Unauthorized
Stack backtrace:
0: anyhow::error::<impl core::convert::From<E> for anyhow::Error>::from
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/anyhow-1.0.79/src/error.rs:565:25
1: <core::result::Result<T,F> as core::ops::try_trait::FromResidual<core::result::Result<core::convert::Infallible,E>>>::from_residual
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/result.rs:1963:27
2: firezone_gateway::run::{{closure}}
at /build/gateway/src/main.rs:85:26
3: <core::pin::Pin<P> as core::future::future::Future>::poll
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/future/future.rs:125:9
4: tokio::runtime::task::core::Core<T,S>::poll::{{closure}}
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/task/core.rs:328:17
5: tokio::loom::std::unsafe_cell::UnsafeCell<T>::with_mut
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/loom/std/unsafe_cell.rs:16:9
6: tokio::runtime::task::core::Core<T,S>::poll
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/task/core.rs:317:13
7: tokio::runtime::task::harness::poll_future::{{closure}}
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/task/harness.rs:485:19
8: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panic/unwind_safe.rs:272:9
9: std::panicking::try::do_call
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:552:40
10: __rust_try
11: std::panicking::try
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:516:19
12: std::panic::catch_unwind
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panic.rs:142:14
13: tokio::runtime::task::harness::poll_future
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/task/harness.rs:473:18
14: tokio::runtime::task::harness::Harness<T,S>::poll_inner
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/task/harness.rs:208:27
15: tokio::runtime::task::harness::Harness<T,S>::poll
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/task/harness.rs:153:15
16: tokio::runtime::task::raw::poll
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/task/raw.rs:271:5
17: tokio::runtime::task::raw::RawTask::poll
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/task/raw.rs:201:18
18: tokio::runtime::task::LocalNotified<S>::run
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/task/mod.rs:416:9
19: tokio::runtime::scheduler::multi_thread::worker::Context::run_task::{{closure}}
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/scheduler/multi_thread/worker.rs:576:13
20: tokio::runtime::coop::with_budget
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/coop.rs:107:5
21: tokio::runtime::coop::budget
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/coop.rs:73:5
22: tokio::runtime::scheduler::multi_thread::worker::Context::run_task
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/scheduler/multi_thread/worker.rs:575:9
23: tokio::runtime::scheduler::multi_thread::worker::Context::run
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/scheduler/multi_thread/worker.rs:526:24
24: tokio::runtime::scheduler::multi_thread::worker::run::{{closure}}::{{closure}}
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/scheduler/multi_thread/worker.rs:491:21
25: tokio::runtime::context::scoped::Scoped<T>::set
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/context/scoped.rs:40:9
26: tokio::runtime::context::set_scheduler::{{closure}}
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/context.rs:176:26
27: std::thread::local::LocalKey<T>::try_with
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/thread/local.rs:270:16
28: std::thread::local::LocalKey<T>::with
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/thread/local.rs:246:9
29: tokio::runtime::context::set_scheduler
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/context.rs:176:9
30: tokio::runtime::scheduler::multi_thread::worker::run::{{closure}}
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/scheduler/multi_thread/worker.rs:486:9
31: tokio::runtime::context::runtime::enter_runtime
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/context/runtime.rs:65:16
32: tokio::runtime::scheduler::multi_thread::worker::run
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/scheduler/multi_thread/worker.rs:478:5
33: tokio::runtime::scheduler::multi_thread::worker::Launch::launch::{{closure}}
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/scheduler/multi_thread/worker.rs:447:45
34: <tokio::runtime::blocking::task::BlockingTask<T> as core::future::future::Future>::poll
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/blocking/task.rs:42:21
35: tokio::runtime::task::core::Core<T,S>::poll::{{closure}}
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/task/core.rs:328:17
36: tokio::loom::std::unsafe_cell::UnsafeCell<T>::with_mut
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/loom/std/unsafe_cell.rs:16:9
37: tokio::runtime::task::core::Core<T,S>::poll
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/task/core.rs:317:13
38: tokio::runtime::task::harness::poll_future::{{closure}}
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/task/harness.rs:485:19
39: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panic/unwind_safe.rs:272:9
40: std::panicking::try::do_call
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:552:40
41: __rust_try
42: std::panicking::try
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:516:19
43: std::panic::catch_unwind
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panic.rs:142:14
44: tokio::runtime::task::harness::poll_future
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/task/harness.rs:473:18
45: tokio::runtime::task::harness::Harness<T,S>::poll_inner
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/task/harness.rs:208:27
46: tokio::runtime::task::harness::Harness<T,S>::poll
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/task/harness.rs:153:15
47: tokio::runtime::task::raw::poll
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/task/raw.rs:271:5
48: tokio::runtime::task::raw::RawTask::poll
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/task/raw.rs:201:18
49: tokio::runtime::task::UnownedTask<S>::run
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/task/mod.rs:453:9
50: tokio::runtime::blocking::pool::Task::run
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/blocking/pool.rs:159:9
51: tokio::runtime::blocking::pool::Inner::run
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/blocking/pool.rs:513:17
52: tokio::runtime::blocking::pool::Spawner::spawn_thread::{{closure}}
at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/runtime/blocking/pool.rs:471:13
53: std::sys_common::backtrace::__rust_begin_short_backtrace
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys_common/backtrace.rs:154:18
54: std::thread::Builder::spawn_unchecked_::{{closure}}::{{closure}}
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/thread/mod.rs:529:17
55: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panic/unwind_safe.rs:272:9
56: std::panicking::try::do_call
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:552:40
57: __rust_try
58: std::panicking::try
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:516:19
59: std::panic::catch_unwind
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panic.rs:142:14
60: std::thread::Builder::spawn_unchecked_::{{closure}}
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/thread/mod.rs:528:30
61: core::ops::function::FnOnce::call_once{{vtable.shim}}
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/ops/function.rs:250:5
62: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/boxed.rs:2007:9
63: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/boxed.rs:2007:9
64: std::sys::unix::thread::Thread::new::thread_start
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys/unix/thread.rs:108:17
```
Now, we are just printing this:
```
2024-01-25T17:32:51.613258Z INFO init{user_agent="Alpine Linux/3.19.0 (x86_64;6.6.11;) connlib/1.0.0" login_topic="gateway"}: phoenix_channel: Connected to portal, waiting for `init` message
2024-01-25T17:32:51.617971Z WARN init{user_agent="Alpine Linux/3.19.0 (x86_64;6.6.11;) connlib/1.0.0" login_topic="gateway"}: phoenix_channel: Fatal client error (401 Unauthorized) in portal connection: Invalid token
2024-01-25T17:32:51.619680Z ERROR firezone_gateway: websocket failed: HTTP error: 401 Unauthorized
```
Resolves: #3401.
|
||
|
Thomas Eizinger
|
f9f95677d5 |
feat: automatically rejoin channel on portal after reconnect (#3393)
In https://github.com/firezone/firezone/pull/3364, we forgot to rejoin the channel on the portal. Additionally, I found a way to detect the disconnect even more quickly. |
||
|
Gabi
|
31f2f52d94 |
fix(gateway): tokio feature dependencies (#3396)
I don't know how this didn't fail in CI before |
||
|
Thomas Eizinger
|
6b789d6932 |
feat(phoenix-channel): automatically reconnect based on provided ExponentialBackoff (#3364)
Currently, only the gateway has a reconnect logic for (transient) errors when connecting to the portal. Instead of duplicating this for the relay, I moved the reconnect state machine to `phoenix-channel`. This means the relay now automatically gets it too and in the future, the clients will also benefit from it. As a nice benefit, this also greatly simplifies the gateway's `Eventloop` and removes a bunch of cruft with channels. Resolves: #2915. |
||
|
Gabi
|
0629afce3a |
connlib: make dns request in a new task without blocking peers (#3370)
This required making `allow_access` `async` which is ugly, but we can fix it later like we did it with `set_peer_connection_request`, but doing this ASAP otherwise this would block the `peers_by_ip` struct and also block the executor a bunch of times and slow everything down. Co-authored-by: Jamil <jamilbk@users.noreply.github.com> |
||
|
dependabot[bot]
|
a6ecee2fd4 |
build(deps): Bump clap from 4.4.17 to 4.4.18 in /rust (#3357)
Bumps [clap](https://github.com/clap-rs/clap) from 4.4.17 to 4.4.18. <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.4.18</h2> <h2>[4.4.18] - 2024-01-16</h2> <h3>Fixes</h3> <ul> <li><em>(error)</em> When lacking <code>usage</code> feature, ensure the list of required arguments is unique</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.4.18] - 2024-01-16</h2> <h3>Fixes</h3> <ul> <li><em>(error)</em> When lacking <code>usage</code> feature, ensure the list of required arguments is unique</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
dependabot[bot]
|
42a05e86ea |
build(deps): Bump uuid from 1.6.1 to 1.7.0 in /rust (#3339)
Bumps [uuid](https://github.com/uuid-rs/uuid) from 1.6.1 to 1.7.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/uuid-rs/uuid/releases">uuid's releases</a>.</em></p> <blockquote> <h2>1.7.0</h2> <h2>What's Changed</h2> <ul> <li>Add missing test for invalid parse_str by <a href="https://github.com/CXWorks"><code>@CXWorks</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/723">uuid-rs/uuid#723</a></li> <li>Upgrade borsh unstable dependency to v1.0 and make it stable by <a href="https://github.com/bgeron"><code>@bgeron</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/724">uuid-rs/uuid#724</a></li> <li>Reduce the package size of uuid by <a href="https://github.com/KodrAus"><code>@KodrAus</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/726">uuid-rs/uuid#726</a></li> <li>Make use of newer Cargo features for specifying dependencies by <a href="https://github.com/KodrAus"><code>@KodrAus</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/727">uuid-rs/uuid#727</a></li> <li>Prepare for 1.7.0 release by <a href="https://github.com/KodrAus"><code>@KodrAus</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/728">uuid-rs/uuid#728</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/CXWorks"><code>@CXWorks</code></a> made their first contribution in <a href="https://redirect.github.com/uuid-rs/uuid/pull/723">uuid-rs/uuid#723</a></li> <li><a href="https://github.com/bgeron"><code>@bgeron</code></a> made their first contribution in <a href="https://redirect.github.com/uuid-rs/uuid/pull/724">uuid-rs/uuid#724</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/uuid-rs/uuid/compare/1.6.1...1.7.0">https://github.com/uuid-rs/uuid/compare/1.6.1...1.7.0</a></p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Gabi
|
7233ccdc0a |
gateway(fix): accept nil expiration times (#3288)
Fixes #3240 |
||
|
Jamil
|
5551eece5d |
fix(devops): Use webpki roots instead of OS cert store (#3266)
Fixes
```json
{
"insertId": "1lzwe6ffj77v9n",
"jsonPayload": {
"cos.googleapis.com/container_name": "klt-relay-vmkr",
"cos.googleapis.com/stream": "stderr",
"cos.googleapis.com/container_id": "29e6fd8f9a4ed1ce390e8a25561d73b0fd8cbcdf17344e999637301175c41fdc",
"message": " 1: invalid peer certificate: UnknownIssuer\n",
"time": "2024-01-16T20:21:49.992901207Z"
},
"resource": {
"type": "gce_instance",
"labels": {
"zone": "asia-south1-a",
"instance_id": "4570479834747179906",
"project_id": "firezone-staging"
}
},
"timestamp": "2024-01-16T20:21:49.992901207Z",
"logName": "projects/firezone-staging/logs/cos_containers",
"receiveTimestamp": "2024-01-16T20:21:50.930410255Z"
}
```
|
||
|
Jamil
|
4ff70746c8 |
Revert "build(deps): Bump tokio-tungstenite from 0.20.1 to 0.21.0 in /rust" (#3248)
Reverts firezone/firezone#3191 |
||
|
dependabot[bot]
|
e9a86fe1e7 |
build(deps): Bump tokio-tungstenite from 0.20.1 to 0.21.0 in /rust (#3191)
Bumps [tokio-tungstenite](https://github.com/snapview/tokio-tungstenite) from 0.20.1 to 0.21.0. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/snapview/tokio-tungstenite/blob/master/CHANGELOG.md">tokio-tungstenite's changelog</a>.</em></p> <blockquote> <h1>0.21.0</h1> <ul> <li>Update TLS dependencies.</li> <li>Update <code>tungstenite</code> to <code>0.21.0</code>.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
dependabot[bot]
|
9852808fc2 |
build(deps): Bump clap from 4.4.11 to 4.4.13 in /rust (#3136)
Bumps [clap](https://github.com/clap-rs/clap) from 4.4.11 to 4.4.13. <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.4.13</h2> <h2>[4.4.13] - 2024-01-04</h2> <h3>Documentation</h3> <ul> <li>Fix link to structopt migration guide</li> </ul> <h2>v4.4.12</h2> <h2>[4.4.12] - 2023-12-28</h2> <h3>Performance</h3> <ul> <li>Only ask <code>TypedValueParser</code> for possible values if needed</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.4.13] - 2024-01-04</h2> <h3>Documentation</h3> <ul> <li>Fix link to structopt migration guide</li> </ul> <h2>[4.4.12] - 2023-12-28</h2> <h3>Performance</h3> <ul> <li>Only ask <code>TypedValueParser</code> for possible values if needed</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Jamil
|
1251397651 |
fix(ios/android): Pass device name and os version as overrides over connect (#3036)
Fixes #3035 Fixes #3037 # Before <img width="738" alt="Screenshot 2023-12-28 at 8 05 31 AM" src="https://github.com/firezone/firezone/assets/167144/c7ab4d74-672c-4536-97fe-f75d8d158bfb"> <img width="546" alt="Screenshot 2023-12-28 at 6 12 30 PM" src="https://github.com/firezone/firezone/assets/167144/1bd4ba98-d11d-4277-bd14-b0afcdf78119"> # After <img width="742" alt="Screenshot 2023-12-28 at 10 48 31 AM" src="https://github.com/firezone/firezone/assets/167144/96054f82-069f-47f7-862c-986455ef76c0"> <img width="744" alt="Screenshot 2023-12-28 at 6 29 37 PM" src="https://github.com/firezone/firezone/assets/167144/4ffc19b6-7c87-4ccb-bcfe-cb0e76fe95b7"> |
||
|
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
|
1cc5164f4e |
connlib: decouple data and control plane and fix backoff reset (#2906)
This fixes #2503 Also: * decouples data-plane and control-plane on the gateway * fixes a thing were a client would stop retrying connecting to a resource if it failed too many times * add all routes on start instead of on a per-route basis |
||
|
Thomas Eizinger
|
0de16d3676 |
refactor(connlib): remove async from the Device API (#2815)
At present, the definition of `Device` is heavily nested with conditional code. I've found this hard to understand and navigate. Recent refactorings now made it possible to remove a lot of these layers so we primarily deal with two concepts: - A `Device` which offers async read and non-blocking write functions - A `Tun` abstraction which is platform-specific Instead of dedicated modules, I chose to feature-flag individual functions on `Device` with `#[cfg(target_family = "unix")]` and `#[cfg(target_family = "windows")]`. I find this easier to understand because the code is right next to each other. In addition, changing the module hierarchy of `Device` allows us to remove `async` from the public API which is only introduced by the use of `rtnetlink` in Linux. Instead of making functions across all `Tun` implementations `async`, we embed a "worker" within the `linux::Tun` implementation that gets polled before `poll_read`. --------- Co-authored-by: Gabi <gabrielalejandro7@gmail.com> |
||
|
Gabi
|
8e34457340 |
Add support for DNS sudomains (#2735)
This PR changes the protocol and adds support for DNS subdomains, now when a DNS resource is added all its subdomains are automatically tunneled too. Later we will add support for `*.domain` or `?.domain` but currently there is an Apple split tunnel implementation limitation which is too labor-intensive to fix right away. Fixes #2661 Co-authored-by: Andrew Dryga <andrew@dryga.com> |
||
|
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=" |