Internal (Not private, just un-interesting to most users) docs and
research to explain the DNS control methods.
I think Jamil was right, we should revert `/etc/resolv.conf` on exit in
case it's used on some minimal Debian kitten. We can keep that and the
`systemd-resolved` method around to support desktop Ubuntu. Everything
else is going to be "When someone needs it".
This opens the door for unit testing `ClientState` with a
`GatewayState`, similarly as we have a test for a `ClientNode` and
`ServerNode` in `snownet`.
Before we can do that though, we need to move several functions from
`ClientTunnel` onto `ClientState`, i.e. essentially encapsulate
`ClientState` better. This is left to a future PR though to keep the
steps small.
Resolves: #3928.
Bumps
[follow-redirects](https://github.com/follow-redirects/follow-redirects)
from 1.15.5 to 1.15.6.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="35a517c586"><code>35a517c</code></a>
Release version 1.15.6 of the npm package.</li>
<li><a
href="c4f847f851"><code>c4f847f</code></a>
Drop Proxy-Authorization across hosts.</li>
<li><a
href="8526b4a1b2"><code>8526b4a</code></a>
Use GitHub for disclosure.</li>
<li>See full diff in <a
href="https://github.com/follow-redirects/follow-redirects/compare/v1.15.5...v1.15.6">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: Reactor Scram <ReactorScram@users.noreply.github.com>
I ended up calling it `reconnect` because that is really what we are
doing:
- We reconnect to the portal.
- We "reconnect" to all relays, i.e. refresh the allocations.
I decided **not** to use an ICE restart. An ICE restart clears the local
as well as the remote credentials, meaning we would need to run another
instance of the signalling protocol. The current control plane does not
support this and it is also unnecessary in our situation. In the case of
an actual network change (e.g. WiFI to cellular), refreshing of the
allocations will turn up new candidates as that is how we discovered our
original ones in the first place. Because we constantly operate in ICE
trickle mode, those will be sent to the remote via the control plane and
we start testing them.
As those new paths become available, str0m will automatically nominate
them in case the current one runs into an ICE timeout. Here is a
screen-recording of the Linux CLI client where `Session::refresh` is
triggered via the SIGHUP signal:
[Screencast from 2024-03-14
11-16-47.webm](https://github.com/firezone/firezone/assets/5486389/7171d199-f2a2-4b22-92c8-243494d5d6d8)
Provides the infrastructure for: #4028.
Fixes the compile warning in macOS for the `version-check` CI job.
Removes some error variants that were never matched on, folding them
into `anyhow::Error`s
Using the current thread in apple was causing a crashloop, since
connlib's thread was taken down by the network extension after
`WrappedSession::connect` returned.
Now we force the runtime to create the thread to prevent it from being
taken down.
Currently, each use of `Session` creates its own `Runtime`. That is
unnecessary because some platforms already have a tokio runtime running.
Instead of creating another one, we simply ask the caller to provide us
with a `Handle` to an existing tokio runtime. For Android and iOS we
spawn a new single-threaded runtime to satisfy this new requirement.
This adds the same kind of HTTP health-check that is already present in
the relay to the gateway. The health-check returns 200 OK for as long as
the gateway is active. The gateway automatically shuts down on fatal
errors (like authentication failures with the portal).
To enable this, I've extracted a crate `http-health-check` that shares
this code between the relay and the gateway.
Resolves: #2465.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com>
With the use of `snownet`, we now have explicit control over how we read
and write messages to sockets. As such, we can make the remaining
stack-allocated buffer heap-allocated and remove the increased
stack-size on our tokio worker threads.
This refactors `Session` to allow for commands to be sent to the
`Eventloop`. Currently, we only send a `Stop` command. With #3429, we
will add more commands like refreshing and updating the DNS servers.
Right now it only works on my dev VM, not on my test VMs, due to #4053
and #4103, but it passes tests and should be safe to merge.
There's one doc fix and one script fix which are unrelated and could be
their own PRs, but they'd be tiny, so I left them in here.
Ref #4106 and #3713 for the plan to fix all this by splitting the tunnel
process off so that the GUI runs as a normal user.
This is heavily inspired by how `str0m`'s `IceAgent` is tested. I left a
link for attribution. We can copy / move this later to write unit tests
for the `Tunnel`.
Bumps [@tauri-apps/cli](https://github.com/tauri-apps/tauri) from 1.5.10
to 1.5.11.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/tauri-apps/tauri/releases"><code>@tauri-apps/cli</code>'s
releases</a>.</em></p>
<blockquote>
<h2><code>@tauri-apps/cli</code> v1.5.11</h2>
<h2>[1.5.11]</h2>
<h3>Bug Fixes</h3>
<ul>
<li><a
href="b15948b11c"><code>b15948b11</code></a>(<a
href="https://redirect.github.com/tauri-apps/tauri/pull/8903">#8903</a>)
Fix <code>.taurignore</code> failing to ignore in some cases.</li>
</ul>
<h3>Dependencies</h3>
<ul>
<li>Upgraded to <code>tauri-cli@1.5.11</code></li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="b705f89a10"><code>b705f89</code></a>
Apply Version Updates From Current Changes (v1) (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/9074">#9074</a>)</li>
<li><a
href="97a05145fb"><code>97a0514</code></a>
fix(cli): migrate to stable features of <code>log</code> crate (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/9119">#9119</a>)</li>
<li><a
href="b15948b11c"><code>b15948b</code></a>
fix(cli): use <code>matched_path_or_any_parents</code> when checking if
a file is ignore...</li>
<li><a
href="5163861588"><code>5163861</code></a>
fix(bundler): escape potentially problematic strings in an XML (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/9040">#9040</a>)</li>
<li><a
href="80a215a6f3"><code>80a215a</code></a>
Apply Version Updates From Current Changes (v1) (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/9013">#9013</a>)</li>
<li><a
href="01ae1218dc"><code>01ae121</code></a>
ci: downgrade thread_local to 1.1.7 in msrv list (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/9012">#9012</a>)</li>
<li><a
href="d42668ce17"><code>d42668c</code></a>
fix(runtime-wry): avoid panic during clipboard initialization on wayland
(<a
href="https://redirect.github.com/tauri-apps/tauri/issues/9003">#9003</a>)</li>
<li><a
href="1ab0db6352"><code>1ab0db6</code></a>
chore: port PR template from <code>dev</code> branch (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/9004">#9004</a>)</li>
<li><a
href="e816a46b95"><code>e816a46</code></a>
chore: update lock files</li>
<li><a
href="a4b82d9dba"><code>a4b82d9</code></a>
chore: bump tauri-utils</li>
<li>See full diff in <a
href="https://github.com/tauri-apps/tauri/compare/@tauri-apps/cli-v1.5.10...@tauri-apps/cli-v1.5.11">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>
Followup from #4100:
- Add `perf/relay` and `debug/relay` etc data plane images in
`firezone-staging`.
- The `perf` images are `debug` stage images and have tooling installed,
but use release binaries.
- The `debug` images are `debug` binaries inside `debug` images
- `firezone-prod` contains only release binaries -- these image names
haven't changed
Previously, the relay neither scheduled a `Wake` command nor did it
register a `TimedAction` to expire a channel binding. Such an action was
only scheduled after the first refresh.
This PR fixes this and adds a test that asserts we can re-bind the same
channel to a different peer after 15 minutes.
Resolves: #3979.
Unfortunately, the current logs don't allow us to correlate, which
allocation and thus which client the expired channel binding relates to.
This PR fixes this by adding more fields to the relevant log messages.
- Runs release asset builds simultaneously with `deploy-staging`. Those
don't depend on each other.
- Prevents running some build workflows in CD because they're run
already in the PR and in the merge group, and the risk of semantic
conflict is negligible
- Run `release` assets in staging
- Adds `compatibility_tests`: **To successfully introduce a breaking
change in the control / data plane APIs, you must now "Merge as
Administrator"**
- Since `CI` is no longer run on `main`, caching needed to be refactored
to make sense again
- Since `CI` is no longer run on `main`, the Elixir
`migrations_and_seeds_test` had to be rewritten. This now tests
migrations using `git checkout` instead of importing `main`'s DB dump.
- Move tauri builds to its own workflow so we can trigger Linux and
Windows builds manually on an adhoc basis like we do for the Swift and
Kotlin builds
- Add a new `hotfix` workflow that will run `compatibility_tests` with
the latest published images
- Add `workflow_dispatch` to trigger `CD` manually for testing purposes
(cc @ReactorScram)
Refs #3995
As part of implementing https://github.com/firezone/firezone/pull/4022,
I realised that I probably composed all the SANS-IO components in the
wrong way. This PR fixes this and adds some documentation on why.
Interestingly, this makes several things of the design simpler because
we end up passing around less state.
Bumps [ctrlc](https://github.com/Detegr/rust-ctrlc) from 3.4.2 to 3.4.4.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/Detegr/rust-ctrlc/releases">ctrlc's
releases</a>.</em></p>
<blockquote>
<h2>v3.4.4</h2>
<p><code>nix</code> 0.27 -> 0.28
MSRV 1.63.0 -> 1.69.0</p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="8ad302d8a1"><code>8ad302d</code></a>
Version 3.4.4</li>
<li><a
href="716787234a"><code>7167872</code></a>
Fix build error on macOS</li>
<li><a
href="ceef26a11a"><code>ceef26a</code></a>
Format with rustfmt</li>
<li><a
href="bd8310ea9b"><code>bd8310e</code></a>
Migrate to GitHub Actions</li>
<li><a
href="4d590bc84f"><code>4d590bc</code></a>
Version 3.4.3</li>
<li><a
href="394fd83b92"><code>394fd83</code></a>
Update nix</li>
<li>See full diff in <a
href="https://github.com/Detegr/rust-ctrlc/compare/3.4.2...3.4.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 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>
Preceded by some refactoring, this PR adds a log line with a very
important metric: Time since connection intent after WG handshake. This
is the equivalent of time-to-first-byte, i.e. how long the user needs to
wait to actually send their first application data after they've tried
for the firs time (and generated an intent).
Currently, we are passing a lot of data into `Session::connect`. Half of
this data is only needed to construct the URL we will use to connect to
the portal. We can simplify this by extracting a dedicated `LoginUrl`
component that captures and validates this data early.
Not only does this reduce the number of parameters we pass to
`Session::connect`, it also reduces the number of failure cases we have
to deal with in `Session::connect`. Any time the session fails, we have
to call `onDisconnected` to inform the client. Thus, we should perform
as much validation as we can early on. In other words, once
`Session::connect` returns, the client should be able to expect that the
tunnel is starting.
`snownet` is built in a SANS-IO way, which means it doesn't have
internal timers or IO. It is up to the upper layer to correctly check
`poll_timeout` and call `handle_timeout` as soon as that expires. _When_
we want to be called again (i.e. the result of `poll_timeout`) may
change every time `snownet`s internal state changes. This is especially
critical during the initial setup of a connection.
As we learn about our own candidates and candidates from the other
party, we form new pairs. To actually detect whether the pair is a
viable network path, we need to send a STUN request. When to send STUN
requests is controlled by time. A newly formed pair should send a STUN
request as soon as possible to minimize latency.
Previously, we did not update the timer upon which we "wake" `snownet`
using `handle_timeout`. As such, we waited unnecessarily long before
sending STUN requests to newly formed pairs. With this patch, we check
`poll_timeout` at end of the `Tunnel`'s `poll` function and immediately
call `handle_timeout` in case we need to.
Currently, `str0m` throttles updates to `handle_timeout` in 50ms blocks
which still creates some delay. With that commented out, I observed
improvements of ~0.7s for establishing new connections. Most of the
time, the 2nd ping already goes through!
