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.
Run the Linux Client or firezone-client-tunnel with `--act-as-tunnel`
and it'll listen for incoming connections on a Unix Domain Socket.
---------
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
To seamlessly migrate relayed connections when relays get re-deployed,
we will be introducing a new message from the portal that informs us
regarding relays that are shutting down and new ones that became active.
Currently, relays are scoped to a particular connection. With the
introduction of the above message, it would be unclear, how these new
relays should be added to these allow lists.
To make this simpler, we remove these allow lists and always use all
relays for all connections.
Related: #4548.
During the latest relay outage, we failed to send heartbeats to the
portal because we were busy-looping and never got to handle messages or
timers for the portal.
To mitigate this or similar bugs, we update an `Instant` every time we
send a heartbeat to the portal. In case we are actually
network-partitioned, this will cause the health-check to fail after 15
minutes. This value is the same as the partition timeout for the portal
connection itself[^1]. Very likely, we will never see a relay being
shutdown because of a failing health check in this case as it would have
already shut itself down.
An exception to this are bugs in the eventloop where we fail to interact
with the portal at all.
Resolves: #4510.
[^1]: Previously, this was unlimited.
Reducing the number of crates as outlined in #4470 would help with
detecting this sort of unused code because we could make more things
`pub(crate)` which allows the compiler to check whether code is actually
used.
Public API items are never subject to the dead-code analysis of the
compiler because they could be used by other crates.
