Bumps [tauri-utils](https://github.com/tauri-apps/tauri) from 1.5.2 to
1.5.3.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/tauri-apps/tauri/releases">tauri-utils's
releases</a>.</em></p>
<blockquote>
<h2>tauri-utils v1.5.3</h2>
<p>Updating crates.io index</p>
<!-- raw HTML omitted -->
<pre><code>Fetching advisory database from
`https://github.com/RustSec/advisory-db.git`
Loaded 603 security advisories (from /home/runner/.cargo/advisory-db)
Updating crates.io index
Scanning Cargo.lock for vulnerabilities (581 crate dependencies)
Crate: atty
Version: 0.2.14
Warning: unsound
Title: Potential unaligned read
Date: 2021-07-04
ID: RUSTSEC-2021-0145
URL: https://rustsec.org/advisories/RUSTSEC-2021-0145
Dependency tree:
atty 0.2.14
└── clap 3.2.25
└── tauri 1.6.0
├── tauri 1.6.0
├── restart 0.1.0
└── app-updater 0.1.0
<p>warning: 1 allowed warning found
</code></pre></p>
<!-- raw HTML omitted -->
<h2>[1.5.3]</h2>
<h3>New features</h3>
<ul>
<li><a
href="7aa30dec85"><code>7aa30dec</code></a>(<a
href="https://redirect.github.com/tauri-apps/tauri/pull/8620">#8620</a>)
Add <code>priority</code>, <code>section</code> and
<code>changelog</code> options in Debian config.</li>
</ul>
<!-- raw HTML omitted -->
<pre><code>Updating crates.io index
Packaging tauri-utils v1.5.3
(/home/runner/work/tauri/tauri/core/tauri-utils)
Verifying tauri-utils v1.5.3
(/home/runner/work/tauri/tauri/core/tauri-utils)
Updating crates.io index
Downloading crates ...
Downloaded phf_codegen v0.8.0
Downloaded phf v0.8.0
Downloaded nodrop v0.1.14
Downloaded phf_generator v0.11.2
Downloaded itoa v0.4.8
</tr></table>
</code></pre>
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="a4b82d9dba"><code>a4b82d9</code></a>
chore: bump tauri-utils</li>
<li><a
href="b735b6799f"><code>b735b67</code></a>
Apply Version Updates From Current Changes (v1) (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/8475">#8475</a>)</li>
<li><a
href="7b5e8712e7"><code>7b5e871</code></a>
ci: update msrv test and cargo.lock</li>
<li><a
href="2421073576"><code>2421073</code></a>
fix(macos): use BTreeMap for windows map to prevent crash on idle (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/8117">#8117</a>)</li>
<li><a
href="510b62261c"><code>510b622</code></a>
chore(core): Add missing changefile for <a
href="https://redirect.github.com/tauri-apps/tauri/issues/8546">#8546</a>
(<a
href="https://redirect.github.com/tauri-apps/tauri/issues/8822">#8822</a>)</li>
<li><a
href="b0f27814b9"><code>b0f2781</code></a>
fix(cli): map <code>--profile dev</code> to <code>debug</code> folder
when finding executable (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/8776">#8776</a>)</li>
<li><a
href="cc3d8e7731"><code>cc3d8e7</code></a>
fix(core): Command::output suspend while wait for response (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/8539">#8539</a>)</li>
<li><a
href="8ce51cec3b"><code>8ce51ce</code></a>
feat: retain cli args when relaunching after update, closes <a
href="https://redirect.github.com/tauri-apps/tauri/issues/7402">#7402</a>
(<a
href="https://redirect.github.com/tauri-apps/tauri/issues/7718">#7718</a>)</li>
<li><a
href="0bff8c325d"><code>0bff8c3</code></a>
fix(cli): Ignore query parameter in dev server (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/8697">#8697</a>)</li>
<li><a
href="a9b2c0625c"><code>a9b2c06</code></a>
chore: Commit Cargo.lock (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/8586">#8586</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/tauri-apps/tauri/compare/tauri-utils-v1.5.2...tauri-utils-v1.5.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>
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.
With the use of `quinn-udp`, we are actually already using GRO for
reading packets from the UDP socket. Especially during a test like
iperf, it is thus very likely to read multiple packets from the same
peer in a single syscall. In that case, `stride` tells us how they are
split.
Without handling `stride` correctly, we would be feeding multiple
packets at once to boringtun which would (obviously) choke on it because
its checksum verification fails.
It turns out we can actually handle this quite nicely by returning an
`Iterator<Item = Received>` and decapsulating them one-by-one.
As part of handling an incoming packet, `snownet` has to go through
several steps:
1. The packet might be a control message from a STUN server, we handle
that first.
2. The packet might from a TURN server, which could either be a control
message or a channel-data message.
The former should be handled directly where as the latter needs to
unpacked and passed along further.
3. Once potentially unpacked, the packet could be a STUN message for an
ICE agent of one of our connections.
4. Lastly, the packet might be a wireguard payload from one of our
connections.
Previously, we handled all of that in one big function which resulted in
us sometimes "falling through" to the next branch when we didn't want
that. For example, if a message is from a TURN server's address, it MUST
be a control or channel data message but it can never be a wireguard
packet. In certain circumstances, we don't detect that though. For
example, if a channel is not yet bound, we refuse to decapsulate the
message which results in us incorrectly passing on the message to later
stages.
We refactor the handling into individual functions and explicitly signal
to the upper layer using `ControlFlow`, whether we should continue or
abort.
As an added benefit, this allows us to remove the "memory" of timed-out
control messages in `StunBinding` and `Allocation`.
This was moved up to the main `/scripts/tests` dir and combined with
some other automated tests, so this is redundant now. Due to a merge
conflict or some small oversight I accidentally left the original file
in place too.
In #3726 this value was increased but the test didn't reflect that.
I've not the slightest idea how this is passing on CI. It isn't locally.
Now I have an Idea, relay tests aren't run on CI.
The CI tests aren't running for Linux just yet.
This organizes the well-known directories used on Linux and Windows for
logs, config, etc., and adds them to the (unused) Linux smoke test
Waiting on #3727
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
I will need to set up the same paths for Linux, (#3734) and I want an
automated test to make sure everything gets into the right directories.
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
I don't know much about `cargo chef` so I gave this its own PR in case
I'm doing something that'll subtly break it
I've run into this problem on some branches and not others, where it's
trying to build all the Tauri / glib stuff even though the Docker image
won't need it:
https://github.com/firezone/firezone/actions/runs/8012206575/job/21887478015#step:7:1175
If I do `rm Cargo.lock && cargo check --all` then I get errors about
rtnetlink.
Dependabot tried to update these a couple weeks ago in #3558 and it had
some conflicts, so I'm just making the old versions explicit so that
redoing the lockfile won't break anything.
This is because I got into a weird state with the new `dirs` dependency
for Linux where I removed it from Cargo.toml, but it was still in the
lockfile or something, so the program built even though it should not
have. And then when I tried to rebuild Cargo.lock I got these errors
about rtnetlink.
Previously, we eagerly created a channel bind message and then buffered
it if we didn't have an allocation. That resulted in some duplicated
checks once we did end up sending the message.
To avoid this, we remove the dedicated `BufferedChannelBindings` struct
and instead use the newly added `RingBuffer`. Whilst we are at it, we
also increase the number of buffered messages to avoid dropping them too
early.
This may cause conflicts with all my other PRs but it has to happen.
```[tasklist]
- [ ] Update test names in branch protection (I don't think I have perms for this)
```
This prevents duplication for different Tauri jobs like building the
release packages vs testing a debug build with mock keyring.
```[tasklist]
- [ ] Fix branch protection rules for changed tests
```
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
The `from` address is already logged as part of the `decapsulate` span
in the `Node`. The `local` address isn't that interesting thus noise
most of the time.
In the relay's authentication scheme, each nonce is only valid for a
certain number of requests. This guards against replay attacks.
Currently, this is set to 10 which means all requests after 10 will
receive a "stale nonce" error. 10 turns out to be way to low and greatly
delays the setup of channels and allocations which is always a burst of
messages that end up incurring additional round trips because they all
need to be re-sent with a new nonce.
I forgot to actually call the expire resources function after the
refactor 🤦
This will be much cleaned up in a PR that I'm working on to eliminate
the `peers_by_id`/`peers_by_ip` maps.
In the mean time let's merge this asap since the gateway not expiring
resources is a security hole.
Currently, we bind a lot of TURN channels on our relays because we bind
a channel to each candidate on each relay. With every node having
usually 4 relays, that results in 16 channels per connection just for
the relay candidates.
We can bring this down optimistically by first checking if the remote's
candidate is a relay candidate and happens to be on a relay that we are
also using. In that case, we only bind the channel on that one.
That should also improve latency when data needs to be relayed because
we reduce the number of hops by 1 and don't send traffic between two
relays.
Additionally, there is no reason to bind channels for host candidates.
It is still client-specific, but this was the closest place I could find
in connlib to put it.
A hypothetical GUI / .deb / systemd-involved gateway would need to be
"dev.firezone.gateway"
This was fixed at some point in the feature branch but was lost to time.
This is preventing macos from working(and might be causing some issues
in other platforms)
Previously, we would only bind channels for _established_ connections.
This caused a problem if we'd get the other parties candidates before
the offer response. Additionally, we'd often send multiple channel
bindings for the same peer which caused additional warnings in the logs.
Bumps [arboard](https://github.com/1Password/arboard) from 3.3.0 to
3.3.1.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/1Password/arboard/releases">arboard's
releases</a>.</em></p>
<blockquote>
<h2>v3.3.1</h2>
<h3>Changed</h3>
<ul>
<li>Updated Windows clipboard and migrated from <code>winapi</code> to
<code>windows-sys</code>.</li>
<li>Internally migrated to Rust 2021 edition.</li>
<li>Significantly improved the crate's error documentation.</li>
<li>Updated <code>core-graphics</code> to <code>0.23</code></li>
<li>Updated <code>x11rb</code> to <code>0.13</code></li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/1Password/arboard/compare/v3.3.0...v3.3.1">https://github.com/1Password/arboard/compare/v3.3.0...v3.3.1</a></p>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/1Password/arboard/blob/master/CHANGELOG.md">arboard's
changelog</a>.</em></p>
<blockquote>
<h2>3.3.1 on 2024-12-02</h2>
<h3>Changed</h3>
<ul>
<li>Updated Windows clipboard and migrated from <code>winapi</code> to
<code>windows-sys</code>.</li>
<li>Internally migrated to Rust 2021 edition.</li>
<li>Significantly improved the crate's error documentation.</li>
<li>Updated <code>core-graphics</code> to <code>0.23</code></li>
<li>Updated <code>x11rb</code> to <code>0.13</code></li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="77e0e078eb"><code>77e0e07</code></a>
Release 3.3.1</li>
<li><a
href="409bd98978"><code>409bd98</code></a>
Update x11rb to 0.13 and core-graphics to 0.23</li>
<li><a
href="bd91f9c438"><code>bd91f9c</code></a>
Increase error documentation on Clipboard type</li>
<li><a
href="a648570ce9"><code>a648570</code></a>
Update CI actions</li>
<li><a
href="0d6725d97f"><code>0d6725d</code></a>
Spell check docs</li>
<li><a
href="a100f2d77c"><code>a100f2d</code></a>
Update clipboard-win to v5 and replace winapi with windows-sys (<a
href="https://redirect.github.com/1Password/arboard/issues/123">#123</a>)</li>
<li><a
href="1b8df75ee2"><code>1b8df75</code></a>
Bump to Rust 2021 edition</li>
<li><a
href="e3f54c3049"><code>e3f54c3</code></a>
Document MSRV of 1.61</li>
<li><a
href="8c475cfd14"><code>8c475cf</code></a>
Make winapi crate optional</li>
<li>See full diff in <a
href="https://github.com/1Password/arboard/compare/v3.3.0...v3.3.1">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
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Currently, we will always try to reach all relays that we are given by
the portal. That creates unnecessary warnings if we don't have
connectivity for a certain IP version.
By filtering based on the IP version of our bound sockets, we can avoid
these warnings in the logs.
---------
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
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>
Binding the IPv6 socket would always fail because we do it _after_ the
IPv4 socket. However, without setting the socket to `IP6_ONLY`, binding
the unspecified IPv6 address (`::`) also wants to bind to IPv4
(depending on the kernel settings). To avoid this, we need to first
configure the socket properly and then bind it to the given address.
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Bumps [ring](https://github.com/briansmith/ring) from 0.17.7 to 0.17.8.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/briansmith/ring/commits">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <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
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Currently, after the refresh timeout the gateway or client starts
looping forever, since after the refresh timeout is reached the
`poll_timeout` will always return `ALLOCATION_LIFETIME/2`(which would be
"now"), since `allocation_lifetime` is never updated.
To fix this, we need to check whether we currently have a refresh
request in flight before queuing a new one. Additionally, we need to
abort refreshing as soon as the lifetime of the allocation expires.
Related: #3617.
Related: #3631.
---------
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Bumps [semver](https://github.com/dtolnay/semver) from 1.0.21 to 1.0.22.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/dtolnay/semver/releases">semver's
releases</a>.</em></p>
<blockquote>
<h2>1.0.22</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="c8ad1bf6db"><code>c8ad1bf</code></a>
Release 1.0.22</li>
<li><a
href="f76db8d7f2"><code>f76db8d</code></a>
Resolve redundant import warning</li>
<li><a
href="f32b420f75"><code>f32b420</code></a>
Ignore incompatible_msrv clippy lint for conditionally compiled
code</li>
<li>See full diff in <a
href="https://github.com/dtolnay/semver/compare/1.0.21...1.0.22">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
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
If `FIREZONE_DNS_CONTROL` is set to `systemd-resolved`, then shell out
to `resolvectl` to request all system DNS queries to go to Firezone's
sentinel DNS server(s).
```[tasklist]
- [ ] Figure out how to stop the runner from using the Docker bridge iface
```
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
This is done to delay the candidate generation after the gateway has
already received the request.
Since we already know the candidates in most cases, an optimization in
the future to reduce the number of round-trips to the gateway we can add
the candidates to the request connection message.
Previously, this mapping was not stored within the tunnel so we had to
perform the resolution further up. This has changed and the tunnel
itself now knows about this mapping. Thus, we can easily move the actual
DNS resolution also into the tunnel, thereby reducing the API surface of
`Tunnel` because we don't need the `write_dns_lookup_response` function.
This is crucial because it is the last place where `Tunnel` is being
cloned in #3391. With this sorted out the way, we can remove all `Arc`s
and locks from `Tunnel` as part of #3391.
Trying to make sure I don't overlook anything. The possible combinations
of setups is like 100+, but these 6 will at least exercise everything
one time, and they're probably going to be the most common, right?
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Regardless of `FIREZONE_DNS_CONTROL`, always try to notify systemd that
we've started.
I had accidentally conflated the idea of running as a systemd service
with the idea of using systemd to control DNS. They're separate, but
I'll keep the service unit in here and always use `sd-notify` since it
should be harmless to use even in Alpine.
~~If `FIREZONE_DNS_CONTROL` is `systemd-resolved`, try to notify systemd
that we've finished startup and the tunnel is ready.~~
Also adds a CI test, including a systemd service file that is **not**
ready for general use.
Ready for review once it's green.
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
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.~~
Initially, we thought that we need to replace the entire `Allocation` if
the credentials to the relay change. However, during testing it turned
out that the credentials will change every time the portal sends us new
credentials. Likely, the portal hashes some kind of nonce into the
password as well.
Consequently, throwing away the entire state of the `Allocation` is
wrong. Instead, we will simply try to refresh the allocation using the
new credentials. If the refresh fails, we will try to make a new
allocation. If that also fails unrecoverably, then we "suspend" the
allocation, i.e. the `Allocation` will not perform any further action by
itself.
In case we get a new `refresh` call (which happens every time we want to
use the `Allocation` for a connection), we restart things and try to
make a new one.
