```[tasklist]
- [x] Update website
- [x] Update blog entry with old link
- [ ] ~~Replace Github URL in GUI Client updater with our own links~~
- [ ] Wait for CI to go green
```
Refs #4531
This proposes a unified scheme for deb and MSI packages, and moves
Windows to that scheme.
This breaks compatibility. Existing Clients won't recognize the new
asset names once this is merged, so they won't show the "Firezone 1.0.0
is available" pop-up.
---------
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
Closes#4682Closes#4691
```[tasklist]
# Before merging
- [x] Wait for `linux-group` test to go green on `main` (#4692)
- [ ] Wait for those browsers tests to get fixed
- [ ] *All* compatibility tests must pass on this branch
```
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
In Rust, `Result::unwrap()` produces a panic with an owned `String`.
Currently, we only attempt to downcast to a `str` which means those
errors show up as "panicked with a non-string payload" instead of the
actual panic message.
Related: #4736.
As part of testing #4750, @jamilbk ran into an interesting but unrelated
bug. Currently, we never invalidate host candidates. However, because we
rebind our sockets, we get new ports and thus our old host candidates
are always invalid. Thus, if you have a setup where your gateway and
client are on the same subnet they end up settling on a host-host
connection. If the client then roams to a different network, we get a
new srflx IP but because we don't invalidate the host candidate, we run
into an ICE timeout and never switch over the connection.
We actually have a unit test for this but it wasn't caught because of a
bug in str0m (https://github.com/algesten/str0m/pull/504): Candidates
with the same IP but different kind were incorrectly invalidated. In our
test, we don't have a NAT and thus host == srflx candidate. Thus, in the
roaming test, we invalidated the host candidate based on the new srflx
candidate which made the connection migration work.
With the patch included, the reconnect unit test actually fails to send
the packet, confirming this theory. By invalidating all host candidates
on `reconnect`, we fix this bug.
---------
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Currently, the portal returns us a flat list of relays where each entry
only has a single address. But, our relays can operate in dual-stack
mode, meaning that they listen on IPv4 and IPv6 at the same time. Thus,
for a relay that is in dual-stack mode, this list will contain two
entries with the same relay ID, one for each address.
This wasn't really a problem until #4567 where we started indexing
relays by ID. As a result, a relay that operates in dual-stack mode is
now only reachable either under its IPv4 or IPv6 address. Which one wins
is non-deterministic due to the sorting behaviour of `HashMap`s and the
order that the list is returned from the portal.
For the TURN protocol, clients are indexed by their 3-tuple (IP, port,
protocol) which means a client talking to a relay over IPv4 is a
different client than one talking over IPv6. Thus, treating the same
relay as two different relays has additional consequences: It means we
allocate a pair of IPv4 & IPv6 addresses for each one, resulting in up
to 4 relay candidates per relay.
Both of these problems are solved in this PR.
1. Upon deserializing the list of relays from the portal, we group them
by ID and parse the addresses into a `RelaySocket`. This structure is
the equivalent of `IpStack` on the relay end and represents an enum with
3 different values:
- `V4`: Only an IPv4 address is known.
- `V6`: Only an IPv6 address is known.
- `Dual`: Both an IPv4 and an IPv6 address is known.
2. Instead of creating two `Allocation`s (one per address), we now
initialize an `Allocation` with this `RelaySocket`.
3. We let the `Allocation` figure out, which socket to use. Let's look
into how we do that.
Previously, the first action of an `Allocation` was to send an
`ALLOCATE` request. A naive approach would be to simply send an
`ALLOCATE` request to both IPs. In case the client / gateway has a
properly configured IPv4 and IPv6 address, both of these will succeed!
Which one should we pick?
To avoid this problem, we don't send an `ALLOCATE` but a `BINDING`
request instead. `BINDING` requests don't have side-effects and just
returned the observed address (this is commonly known as STUN). Once the
responses for the `BINDING` requests come back, we can deterministically
chose a socket to use for sending an `ALLOCATE` request. In particular,
we just pick the response that comes back first! A successful `BINDING`
request means the network path is working so we can also just it for
`ALLOCATE`. In case both requests are answered, we record both responses
as server-reflexive candidates.
Lastly, one final change with this PR is that we stop filtering the
relays returned by the portal based on the sockets that we have locally.
When a client roams, we may experience any combination of available
network interfaces (dual stack, IPv4 only and IPv6 only). Thus, it is
important that we always attempt to reach all relays over all network
paths and simply give up if we don't receive a response. Pre-filtering
relays based on the sockets that we currently have may leave us without
relays if we e.g. roam from an IPv4-only to and IPv6-only network. A
consequence of this design is that we might see a few more warnings in
the code in case the client's / gateway's interface doesn't support a
particular IP version. The warnings read something like:
```
2024-04-23T07:09:05.209212Z WARN connlib_client_shared::eventloop: Tunnel error: failed send packet to 35.197.175.154:3478: no IPv4 socket
```
Resolves: #4726.
In https://github.com/firezone/firezone/pull/4537, we fixed a bug that
made an `Allocation` busy-loop with invalid credentials. There is no
point in keeping invalid credentials around so with this PR, we are
clearing the credentials and free the memory associated with this
`Allocation`.
This is another safe-guard to prevent these kind of busy-loops and also
reduces the memory footprint of very long-running services.
Bumps the cargo group in /rust with 1 update:
[rustls](https://github.com/rustls/rustls).
Updates `rustls` from 0.22.3 to 0.22.4
<details>
<summary>Commits</summary>
<ul>
<li><a
href="ae277befb5"><code>ae277be</code></a>
Prepare 0.22.4</li>
<li><a
href="5374108df6"><code>5374108</code></a>
complete_io: bail out if progress is impossible</li>
<li><a
href="00e695d68d"><code>00e695d</code></a>
Regression test for <code>complete_io</code> infinite loop bug</li>
<li><a
href="0c6cd7ef68"><code>0c6cd7e</code></a>
Don't specially handle unauthenticated close_notify alerts</li>
<li>See full diff in <a
href="https://github.com/rustls/rustls/compare/v/0.22.3...v/0.22.4">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 <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/firezone/firezone/network/alerts).
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [time](https://github.com/time-rs/time) from 0.3.34 to 0.3.36.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/time-rs/time/releases">time's
releases</a>.</em></p>
<blockquote>
<h2>v0.3.36</h2>
<p>See the <a
href="https://github.com/time-rs/time/blob/main/CHANGELOG.md">changelog</a>
for details.</p>
<h2>v0.3.35</h2>
<p>See the <a
href="https://github.com/time-rs/time/blob/main/CHANGELOG.md">changelog</a>
for details.</p>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/time-rs/time/blob/main/CHANGELOG.md">time's
changelog</a>.</em></p>
<blockquote>
<h2>0.3.36 [2024-04-10]</h2>
<h3># Fixed</h3>
<ul>
<li><code>FormatItem</code> can be used as part of an import path. See
<a href="https://redirect.github.com/time-rs/time/issues/675">#675</a>
for details.</li>
</ul>
<p><a
href="https://redirect.github.com/time-rs/time/issues/675">#675</a>: <a
href="https://redirect.github.com/time-rs/time/issues/675">time-rs/time#675</a></p>
<h2>0.3.35 [2024-04-10]</h2>
<h3>Added</h3>
<ul>
<li><code>Duration::checked_neg</code></li>
<li><code>ext::InstantExt</code>, which provides methods for using
<code>time::Duration</code> with <code>std::time::Instant</code></li>
</ul>
<h3>Changed</h3>
<ul>
<li><code>Instant</code> is deprecated. It is recommended to use
<code>std::time::Instant</code> directly, importing
<code>time::ext::InstantExt</code> for interoperability with
<code>time::Duration</code>.</li>
<li><code>FormatItem</code> has been renamed to
<code>BorrowedFormatItem</code>, avoiding confusion with
<code>OwnedFormatItem</code>.
An alias has been added for backwards compatibility.</li>
</ul>
<h3>Fixed</h3>
<ul>
<li>The weekday is optional when parsing RFC2822.</li>
<li>The range of sub-second values in <code>Duration</code> is
documented correctly. The previous documentation
contained an off-by-one error.</li>
<li>Leap seconds are now correctly handled when parsing ISO 8601.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="3c3c546a66"><code>3c3c546</code></a>
<code>pub use</code> instead of <code>pub type</code> re-exporting</li>
<li><a
href="266178da67"><code>266178d</code></a>
Update code coverage CI</li>
<li><a
href="131049ea15"><code>131049e</code></a>
v0.3.35 release</li>
<li><a
href="9c15ee3466"><code>9c15ee3</code></a>
Permit leap seconds when parsing ISO 8601</li>
<li><a
href="d279d8d38f"><code>d279d8d</code></a>
Fix invalid offset hour diagnostic test</li>
<li><a
href="f04a28feec"><code>f04a28f</code></a>
Eliminate unreachable branch</li>
<li><a
href="06a096d821"><code>06a096d</code></a>
Rename <code>FormatItem</code> to <code>BorrowedFormatItem</code></li>
<li><a
href="fd664eef0d"><code>fd664ee</code></a>
Include diagnostics regression</li>
<li><a
href="b8d09a7bcc"><code>b8d09a7</code></a>
Address nightly lints</li>
<li><a
href="330865ac90"><code>330865a</code></a>
Update deny.toml</li>
<li>Additional commits viewable in <a
href="https://github.com/time-rs/time/compare/v0.3.34...v0.3.36">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>
Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Considered using Elixir and Rust to write the tests.
For Elixir, `wallaby` doesn't seem to have a way to attach to an
existing `chromium` instance, launching it each time, which makes it
hard to coordinate with the relay restart.
For Rust we considered `thirtyfour` which would be very nice since we
could test both firefox and chrome but each time it connects to the
instance it launches a new session making it hard to test the DNS cache
behavior.
We also considered `chrome_headless` for Rust it needs a small patch to
prevent it from closing the browser after `Drop` but it still presents a
problem, since it has no easy way to retrieve if loading a page has
succeeded. There are some workarounds such as retrieving the title that
we could have used but after some testing they are quite finnicky and we
don't want that for CI.
So I ended up settling for TypeScript but I'm open to other options, or
a fix for the previous ones!
There are some modifications still incoming for this PR, around the test
name and that sleep in the middle of the test doesn't look good so I
will probably add some retries, but the gist is here, will keep it in
draft until we expect it to be passing.
So feel free to do some initial reviews.
Note: the number of lines changed is greatly exaggerated by
`package.lock`
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Whenever we receive a `relays_presence` message from the portal, we
invalidate the candidates of all now disconnected relays and make
allocations on the new ones. This triggers signalling of new candidates
to the remote party and migrates the connection to the newly nominated
socket.
This still relies on #4613 until we have #4634.
Resolves: #4548.
---------
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
As a result of moving all logic into `ClientState` and `GatewayState`,
the concrete types of `Peer` are statically known everywhere. Thus, we
can remove this abstraction layer and directly store a `ClientOnGateway`
and `GatewayOnClient` struct in the `PeerStore`.
This makes code-navigation and reasoning easier because one can directly
jump to the function that is being called.
Resolves: #4224.
```[tasklist]
# Before merging
- [x] Remove file extension `.txt`
- [x] Wait for `linux-group` test to go green on `main` (#4692)
- [x] *all* compatibility tests must be green on this branch
```
Closes#4664Closes#4665
~~The compatibility tests are expected to fail until the next release is
cut, for the same reasons as in #4686~~
The compatibility test must be handled somehow, otherwise it'll turn
main red.
`linux-group` was moved out of integration / compatibility testing, but
the DNS tests do need the whole Docker + portal setup, so that one can't
move.
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
With the introduction of `snownet`, we temporarily duplicated the
`IpPacket` abstraction from `firezone-tunnel` because there was no
common place to put it. Overtime, these have grown in size and we needed
to convert back and forth between time. Lately, we've also been adding
more tests to both `snownet` and `firezone-tunnel` that needed to create
`IpPacket`s as test data.
This seems like an appropriate time to do away with this duplication by
introducing a dedicated crate that acts as a facade for the
`pnet_packet` crate, extending it with the functionality that we need.
Resolves: #3926.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
As suspected, there was a bug in the relay where channel bindings were
not cleared if the client freed the allocation early by sending a
REFRESH request with a lifetime of 0.
Resolves: #4588.
Bumps [either](https://github.com/rayon-rs/either) from 1.10.0 to
1.11.0.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="864eae4540"><code>864eae4</code></a>
Merge pull request <a
href="https://redirect.github.com/rayon-rs/either/issues/104">#104</a>
from cuviper/release-1.11.0</li>
<li><a
href="0bdb583188"><code>0bdb583</code></a>
Release 1.11.0</li>
<li><a
href="e385751eda"><code>e385751</code></a>
Merge pull request <a
href="https://redirect.github.com/rayon-rs/either/issues/101">#101</a>
from SFM61319/feat/into-either</li>
<li><a
href="d62efa6fff"><code>d62efa6</code></a>
Feat: Implement trait <code>IntoEither</code></li>
<li><a
href="d48ab1b312"><code>d48ab1b</code></a>
Merge pull request <a
href="https://redirect.github.com/rayon-rs/either/issues/103">#103</a>
from masklinn/patch-1</li>
<li><a
href="365f674f6d"><code>365f674</code></a>
Enable <code>serde</code> feature on playgrounds</li>
<li>See full diff in <a
href="https://github.com/rayon-rs/either/compare/1.10.0...1.11.0">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>
Previously, we would have a single span that was activated for all
messages, including channel-data messages. That was great for
de-duplication but shit for performance, so we turned it down to `debug`
level. That lost us a lot of context for messages like "Successfully
bound channel" or any other state change in the relay.
To restore this, we remove the span from `handle_client_input` and start
a new span on `info` level for each control message. For channel data
messages, the span is however on `debug` level to not affect performance
in production.
Resolves: #4496.
This was discussed with @AndrewDryga to allow us detecting potential
attacks. Some amount of authentication failures are expected during
normal operation because TURN has this system of nonces which can only
be used a certain number of times.
Resolves: #4550.
This did not do anything other than limit the size of the buffer that we
pass in for reading. This has no effect whatsoever. We only ever read a
single packet anyway and we get told how big it is as a result of
`poll_read`.
Resolves: #4469.
Opening this in a basic version that asserts sending of connection
intents to resource IPs. To do this, we add some boilerplate that sets
up the state machine test in general. Together with the
[work](d575dc3866/rust/connlib/snownet/tests/lib.rs (L296-L824))
that I've done on the `snownet` tests, this can then be extended to
describe the entire state machine of connlib and letting `proptest`
search for inputs & combinations that break stuff.
Some more `Transition`s that I'd expect we can implement:
- Add DNS resource
- Reconnect (i.e. roam networks)
- Remove resource
The public API of `Tunnel` isn't actually very large: We add and remove
resources, set upstream DNS servers and call `reconnect`. I think the
bet here is that we can implement the reference state machine in a very
simple way. For example, once we have added a resource and handled the
connection-intent, we should be able to send an ICMP packet through the
tunnel. I've already worked out how to pass `Transmit`s back and forth
between relay, client and gateway (see linked `snownet` tests above). If
we port that to this state machine test, we can actually exercise all
the code paths that are required to encapsulate / decapsulate those
packets whilst asserting against something simple like "packet pops out
at the other end".
Because the setup of the test is also a proptest-strategy, we can even
add the network topology as a variable by configuring the `Firewall`
(see `snownet` tests) dynamically with or without blocking rules and
thus force the entire tunnel through an (in-memory) relay.
Related: #4589.
As part of #4568, we are adding a 2nd relay which showed some
short-comings of the current process state assertions because they were
running outside the docker containers, thus listing all relays as soon
as there are multiple.
Actually parsing this got lost as part of introducing graceful shutdown
where we re-ordered when to connect to the portal. This removes a
warning from the logs which might otherwise be misleading of a problem.
Unfortunately I couldn't make it only happen once. This helps with
debugging service accounts, where DNS bugs look the same as forgetting
to enable a policy.
Closes#4657
```[tasklist]
### Before merging
- [x] Update KB
```
Maybe not a feature since Linux IPC isn't available to users yet?
I think it's okay if the new `linux-group` test fails in compatibility,
since it wasn't implemented at all back then.
Closes#4659Closes#4660
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Closes#4655
This should be more clear since "daemon", like "tunnel", could mean a
variety of things. The IPC thing is the distinct part for this
subcommand, and I didn't want to call it "server" and confuse it with a
web server. "service" hopefully evokes "systemd service" and "Windows
service", something that provides a service locally.
If not it could always be something longer
Bumps [redis](https://github.com/redis-rs/redis-rs) from 0.25.2 to
0.25.3.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/redis-rs/redis-rs/releases">redis's
releases</a>.</em></p>
<blockquote>
<h2>v0.25.3</h2>
<h3>0.25.3 (2024-04-04)</h3>
<ul>
<li>Handle empty results in multi-node operations (<a
href="https://redirect.github.com/redis-rs/redis-rs/pull/1099">#1099</a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="0db8ef7139"><code>0db8ef7</code></a>
Prepare release 0.25.3</li>
<li><a
href="0f9cb3173c"><code>0f9cb31</code></a>
Handle empty results in multi-node operations.</li>
<li>See full diff in <a
href="https://github.com/redis-rs/redis-rs/compare/redis-0.25.2...redis-0.25.3">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>
Closes#4385
```[tasklist]
### Manual test cases (f2c8f47b3 passed)
- [x] Given there is no token on disk, when you start the app, then there is no notification
- [x] Given there is a token on disk, when you start the app and it signs in, then there is 1 notification
- [x] Given the app is signed out, when you sign in, then there is 1 notification (test this in a sign-out-sign-in cycle)
- [x] Given the app is signed in, when you sign out, then there is no notification
- [x] Given the app is signed in, when you change Wi-Fi networks, then there is no notification
```
This will work on Linux once the Linux GUI comes up
This is another step towards #4548. The portal now includes a list of
relays as part of the "init" message. Any time we receive an "init", we
will now upsert those relays based on their ID. This requires us to
change our internal bookkeeping of relays from indexing them by address
to indexing by ID.
To ensure that this works correctly, the unit tests are rewritten to use
the new `upsert_relays` API.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Fixes#4488
```[tasklist]
# Before merging
- [x] There's one call site that won't compile on Linux. Make this cross-platform.
- [x] Does the rule get removed every time when you quit gracefully?
- [x] Will this NRPT rule prevent connlib from re-resolving the portal IP if it needs to?
- [x] Test network switching. Does this work worse, better, or the same?
- [ ] Is the Windows DNS cache flushed exactly when it needs to be?
```
- After connlib connects to the portal, we add an NRPT rule asking
Windows to send **all** DNS queries to our sentinels. This should also
be called whenever the interface is re-configured, which might change
the sentinel IPs
- When exiting gracefully, we delete the rule to restore normal DNS
behavior without having to back up and restore the other IPs
- We also delete the rule at startup so that if Firezone crashes or
misbehaves, restarting it should restore normal DNS
- We also flush the system-wide DNS cache whenever we claim different
routes. This may flush too often, and it may also miss some flushes that
we should do. It needs double-checking.
- There is still a gap when changing networks, DNS can leak there, but I
don't think it's worse than before.
Bumps [hostname](https://github.com/svartalf/hostname) from 0.3.1 to
0.4.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/svartalf/hostname/blob/master/CHANGELOG.md">hostname's
changelog</a>.</em></p>
<blockquote>
<h2>[0.4.0] - 2024-04-01</h2>
<h3>Added</h3>
<ul>
<li>CI setup now covers almost all supported Tier 1 and Tier 2 platform
targets</li>
</ul>
<h3>Changed</h3>
<ul>
<li>Minimum Supported Rust version set to <code>1.67.0</code></li>
<li>Rust edition set to "2021"</li>
</ul>
<h3>Fixed</h3>
<ul>
<li>Handle edge cases for POSIX systems (<a
href="https://redirect.github.com/svartalf/hostname/issues/14">#14</a>)</li>
<li>docs.rs documentation build</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="0e311b92ea"><code>0e311b9</code></a>
Release v0.4.0</li>
<li><a
href="e96d1fde34"><code>e96d1fd</code></a>
Updating the repo to make it usable again</li>
<li><a
href="ecf28ebbf4"><code>ecf28eb</code></a>
bump version-sync: 0.8 -> 0.9 (<a
href="https://redirect.github.com/svartalf/hostname/issues/17">#17</a>)</li>
<li><a
href="4a178ed8f4"><code>4a178ed</code></a>
Handle posix hostname edge cases (<a
href="https://redirect.github.com/svartalf/hostname/issues/14">#14</a>)</li>
<li><a
href="7e930e9aca"><code>7e930e9</code></a>
Upgrade rust edition and migrate dependices（cfg_if, windows_rs） (<a
href="https://redirect.github.com/svartalf/hostname/issues/18">#18</a>)</li>
<li>See full diff in <a
href="https://github.com/svartalf/hostname/compare/v0.3.1...v0.4.0">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>
Upon receiving a SIGTERM, we immediately disconnect from the websocket
connection to the portal and set a flag that we are shutting down.
Once we are disconnected from the portal and no longer have an active
allocations, we exit with 0. A repeated SIGTERM signal will interrupt
this process and force the relay to shutdown.
Disconnecting from the portal will (eventually) trigger a message to
clients and gateways that this relay should no longer be used. Thus,
depending on the timeout our supervisor has configured after sending
SIGTERM, the relay will continue all TURN operations until the number of
allocations drops to 0.
Currently, we also allow clients to make new allocations and refreshing
existing allocations. In the future, it may make sense to implement a
dedicated status code and refuse `ALLOCATE` and `REFRESH` messages
whilst we are shutting down.
Related: #4548.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
In a prior design of the relay and the `phoenix-channel`, connecting to
the portal was a blocking operation, i.e. we weren't meant to start the
relaying operations before the portal connection succeeded.
Since then, `phoenix-channel` got refactored to have an internal
(re)-connection mechanism, meaning we don't actually need to `.await`
anything to obtain a `PhoenixChannel` instance that we can use to
initialize the `Server`. Furthermore, we changed the health-check to
return 200 OK prior to the portal connection being established in #4553.
Taking both of these into account, there is no more need to block on the
portal connection being established, which allows us to remove the use
of `phoenix_channel::init` and connect in the background whilst we
already accept STUN & TURN traffic.
Using the recent improvements made to the test harness, we can now add a
test for `reconnect` and assert that we are indeed discovering the new
interface and signaling the ICE candidate to the other party.
Bumps [h2](https://github.com/hyperium/h2) from 0.3.25 to 0.3.26.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/hyperium/h2/releases">h2's
releases</a>.</em></p>
<blockquote>
<h2>v0.3.26</h2>
<h2>What's Changed</h2>
<ul>
<li>Limit number of CONTINUATION frames for misbehaving
connections.</li>
</ul>
<p>See <a
href="https://seanmonstar.com/blog/hyper-http2-continuation-flood/">https://seanmonstar.com/blog/hyper-http2-continuation-flood/</a>
for more info.</p>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/hyperium/h2/blob/v0.3.26/CHANGELOG.md">h2's
changelog</a>.</em></p>
<blockquote>
<h1>0.3.26 (April 3, 2024)</h1>
<ul>
<li>Limit number of CONTINUATION frames for misbehaving
connections.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="357127e279"><code>357127e</code></a>
v0.3.26</li>
<li><a
href="1a357aaefc"><code>1a357aa</code></a>
fix: limit number of CONTINUATION frames allowed</li>
<li><a
href="5b6c9e0da0"><code>5b6c9e0</code></a>
refactor: cleanup new unused warnings (<a
href="https://redirect.github.com/hyperium/h2/issues/757">#757</a>)</li>
<li>See full diff in <a
href="https://github.com/hyperium/h2/compare/v0.3.25...v0.3.26">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)
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/firezone/firezone/network/alerts).
</details>
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Unfortunately I had to keep `linux-client` to get the compatibility
tests to pass. #4578 aims to remove that package.
Please add to this list if you think of anything:
```[tasklist]
# Things that may break that CI/CD won't catch
- [ ] Github release artifacts
- [ ] Knowledge base
- [ ] Docker images
- [ ] Docker containers
- [ ] Existing `linux-client` users
- [ ] Anything that downloads ghcr artifacts
- [ ] Nix (Not sure if it's built in CI. It had a merge conflict)
```
Refs #4515, and #3712, #3782
I think this is what Thomas and I agreed on in Slack / Github
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
This PR adds a unit-test to `snownet` that exercises all code paths that
are required for a relayed connection to work. This includes:
- Nodes make an allocation with real credentials, nonces etc
- Nodes exchange their ICE candidates
- Nodes bind data channels on the relay
- str0m performs ICE over these data channels
- Nodes handshake a wireguard tunnel on the nominated socket
I consider this a baseline. Once merged, I want to attempt writing a
test in #4568 that asserts migration of a connection to a new relay
without the connection expiring. At some point, we can even go further
and move these tests to `firezone-tunnel` and unit-test even more things
like connection intents etc.
