On some Linux distributions (Amazon Linux 2023), the default `iptables`
install includes a blanket deny rule in the `FORWARD` chain that
prevents packets from the tunnel interface from ever leaving the host.
To fix this, we ensure our `FORWARD` chain rules are inserted with
priority 1 which takes precedence over the blanket-deny rule.
We also update our MASQUERADE in the NAT table to apply only to the CIDR
range possible for Gateway tunnel IPs, as opposed to the default
`0.0.0.0/0`.
Fixes#8481
Bumps
[android_log-sys](https://github.com/rust-mobile/android_log-sys-rs)
from 0.3.1 to 0.3.2.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/rust-mobile/android_log-sys-rs/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 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>
Within the event-loop, we already react to the channel being closed
which happens when the `Sender` within the `Session` gets dropped. As
such, there is no need to send an explicit `Stop` command, dropping the
`Session` is equivalent.
As it turns out, `swift-bridge` already calls `Drop` for us when the
last pointer is set to `nil`:
280a9dd999/swift/apple/FirezoneNetworkExtension/Connlib/Generated/connlib-client-apple/connlib-client-apple.swift (L24-L28)
Thus, we can also remove the explicit `disconnect` call to
`WrappedSession` entirely.
In order to be able to dynamically configure long-running applications
such as the Gateway via feature-flags, we need to regularly re-evaluate
them by sending another POST request to the `/decide` endpoint.
To do this without impacting anything else, we create a separate runtime
that is lazily initialised on first access and use that to run the async
code for connecting to the PostHog service. In addition to that, we also
spawn a task that re-evaluates the feature flags for the currently set
user in the Sentry context every 5 minutes.
Resolves: #8454
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
The bugfix we attempted in #8156 turned out wrong. Reading the
source-code, we have to call `Session::shutdown` in order to actually
cancel the `Session::receive_blocking` call. Not doing so means we run
into the timeout when discarding the `Tun` device because the
recv-thread is stuck in `Session::receive_blocking`.
Fixes: #8395
Dependabot appears to have a hard time to bump the Tauri dependencies in
a group together. Additionally, our dependency linter `cargo deny`
disallows duplicate dependencies by default. To avoid introducing more
duplicate dependencies, we depend on the upstream `main` branch of two
projects that have already updated their dependencies but did not yet
cut a release.
Currently, we are only emitting updates to the `TunConfig` when the
routes or the DNS servers change. This isn't correct, we should also
emit updates for it when the IPs or the search-domain changes.
In order to achieve that, we create a new `TunConfig` based on the
existing one every time we receive an `InterfaceConfig` update.
Depending on our current state, we may create an entirely new
`TunConfig` or create a new one where we copy the fields in from the new
`InterfaceConfig`. We then unconditionally call
`maybe_update_tun_config` which does the necessary work to only emit
updates when things actually changed.
To ensure this works in all cases and the latest update is always
reflected on the TUN device, we also extend the proptests to assert the
latest search domain.
Fixes: #8451
Bumps [tokio-util](https://github.com/tokio-rs/tokio) from 0.7.12 to
0.7.13.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="0b31c2f73d"><code>0b31c2f</code></a>
chore: prepare tokio-util v0.7.13 (<a
href="https://redirect.github.com/tokio-rs/tokio/issues/7012">#7012</a>)</li>
<li><a
href="129f9fc0c8"><code>129f9fc</code></a>
codec: fix incorrect handling of invalid utf-8 in
<code>LinesCodec::decode_eof</code> (#...</li>
<li><a
href="b5c227d51f"><code>b5c227d</code></a>
tracing: move tracing instrumentation tests into tokio tests (<a
href="https://redirect.github.com/tokio-rs/tokio/issues/7007">#7007</a>)</li>
<li><a
href="dcae2b9eb8"><code>dcae2b9</code></a>
ci: unfreeze FreeBSD from rustc 1.81 (<a
href="https://redirect.github.com/tokio-rs/tokio/issues/7009">#7009</a>)</li>
<li><a
href="bb9d57017e"><code>bb9d570</code></a>
chore: prepare Tokio v1.42.0 (<a
href="https://redirect.github.com/tokio-rs/tokio/issues/7005">#7005</a>)</li>
<li><a
href="af9c683d52"><code>af9c683</code></a>
tests: fix typo in build test instructions (<a
href="https://redirect.github.com/tokio-rs/tokio/issues/7004">#7004</a>)</li>
<li><a
href="4bc5a1a058"><code>4bc5a1a</code></a>
ci: allow Unicode-3.0 license for unicode-ident (<a
href="https://redirect.github.com/tokio-rs/tokio/issues/7006">#7006</a>)</li>
<li><a
href="f8948ea021"><code>f8948ea</code></a>
runtime: do not defer <code>yield_now</code> inside
<code>block_in_place</code> (<a
href="https://redirect.github.com/tokio-rs/tokio/issues/6999">#6999</a>)</li>
<li><a
href="bce9780dd3"><code>bce9780</code></a>
time: use <code>array::from_fn</code> instead of manually creating array
(<a
href="https://redirect.github.com/tokio-rs/tokio/issues/7000">#7000</a>)</li>
<li><a
href="38151f30cb"><code>38151f3</code></a>
readme: unlist 1.32.x as LTS release (<a
href="https://redirect.github.com/tokio-rs/tokio/issues/6997">#6997</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/tokio-rs/tokio/compare/tokio-util-0.7.12...tokio-util-0.7.13">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>
Bumps [either](https://github.com/rayon-rs/either) from 1.13.0 to
1.15.0.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="59ae1fce0c"><code>59ae1fc</code></a>
Merge pull request <a
href="https://redirect.github.com/rayon-rs/either/issues/120">#120</a>
from cuviper/release-1.15.0</li>
<li><a
href="7f4bf0222d"><code>7f4bf02</code></a>
Release 1.15.0</li>
<li><a
href="56178e9fdb"><code>56178e9</code></a>
Merge pull request <a
href="https://redirect.github.com/rayon-rs/either/issues/119">#119</a>
from klkvr/klkvr/fix-no-std</li>
<li><a
href="80b6f2a7fd"><code>80b6f2a</code></a>
fix last references of use_std</li>
<li><a
href="2b71801b05"><code>2b71801</code></a>
serde 1.0.95</li>
<li><a
href="8c1ea3e557"><code>8c1ea3e</code></a>
use_std -> std</li>
<li><a
href="d743e25f52"><code>d743e25</code></a>
fix: no-std with serde feature</li>
<li><a
href="6e6dc26828"><code>6e6dc26</code></a>
Merge pull request <a
href="https://redirect.github.com/rayon-rs/either/issues/117">#117</a>
from cuviper/release-1.14.0</li>
<li><a
href="937620642b"><code>9376206</code></a>
Release 1.14.0</li>
<li><a
href="4db2c30e5f"><code>4db2c30</code></a>
Merge pull request <a
href="https://redirect.github.com/rayon-rs/either/issues/118">#118</a>
from cuviper/clippy</li>
<li>Additional commits viewable in <a
href="https://github.com/rayon-rs/either/compare/1.13.0...1.15.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>
For existing `TunConfig`, we had a bug where we failed to update the
search_domain if the effective dns_servers were unchanged.
@thomaseizinger I can see why you want to refactor this; it's quite a
mess to follow ;-). I was going to try my hand at cleaning it up a
little bit just so I can grok it but I figured since this area is going
to be changing quite a bit in #8263, I'll leave those changes out for
now.
I suspect that one issue as part local discovery is that we respond to
LLMNR queries with NXDOMAIN if the domain isn't a resource. This is
probably wrong. LLMNR works over multicast so if a particular interface
can't respond to a query with records, it should probably not respond at
all.
Related: #8266
In order for search-domains to work on Windows, we need to set the
`SearchList` registry key for our interface. This will result in Windows
sending us a DNS query with the expanded domain name from the search
list which we can then process like normal DNS queries.
Related: #8410
Our Posthog integration was so lenient in regards to errors that I
didn't even notice at all that we failed to deserialise them correctly.
In Posthog, I configured the feature flags with `kebab-case` but we
tried to deserialise them as `snake_case`.
In order to have the system expand search domains for us, we need to set
a very peculiar combination of configuration options in the
`NEDNSSettings` of the VPN configuration:
- We need to include our search domains in the list of `matchDomains`
- We need to set `matchDomainsNoSearch = false`
- We need to set the `searchDomains` field
Technically, we don't even need to set `searchDomains` by itself.
Reading the docs in more detail for the `matchDomainsNoSearch` flag
explains why:
> A Boolean that specifies if the domains in the matchDomains list
should not be appended to the resolver’s list of search domains.
The double-negative here is confusing but essentially, what this says
is:
> If false, append the list of match domains to the resolver's search
domains.
That is exactly what we want. We want a search domain of e.g.
`example.com` to append to the list of search domains for the primary
resolver of non-scoped DNS queries.
I tested without setting `searchDomains` and it does still work: The
system will still expand the domain for us und send us a FQDN query of
e.g. `foo.example.com`. However, I figured not setting `searchDomains`
at all is quite confusing so I left it in there.
Related: #8410 (Fixes it for MacOS)
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: thomas <firezone@firezones-MacBook-Air.fritz.box>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
When debugging Firezone, it is useful to use `tail -f` on the current
logfile to see what `connlib` is doing. This is quite annoying to do
however because the log file rolls over with every restart of the
application. As a small QoL improvement, we always symlink the latest
log file to a link called `latest`. Therefore, all one needs to do is
re-run the latest `tail -f ./latest` command to get the new logs.
Resolves: #8388
Proptests found this one. It can't happen in practice because we don't
expose disabling arbitrary resources to the Client's UI, only the
Internet Resource can be enabled / disabled.
Most of the time, these flags are only read from and not written thus.
By using a read-lock, we make sure that even when we use feature-flags
from multiple threads, they don't cause any contention.
A sizeable chunk of Firezone's Rust components deal with parsing,
manipulating and emitting DNS queries and responses. The API surface of
DNS is quite large and to make handling of all corner-cases easier, we
depend on the `domain` library to do the heavy-lifting for us.
For better or worse, `domain` follows a lazy-parsing approach. Thus,
creating a new DNS message doesn't actually verify that it is in fact
valid. Within Firezone, we make several assumptions around DNS messages,
such as that they will only ever contain a single question.
Historically, DNS allows for multiple questions per query but in
practise, nobody uses that.
Due to how we handle DNS in Firezone, manipulating these messages
happens in multiple places. That combined with the lazy-parsing approach
from `domain` warrants having our own `dns-types` library that wraps
`domain` and provides us with types that offer the interface we need in
the rest of the codebase.
Resolves: #7019
Search domains are a way of performing a DNS lookup without typing the
full-qualified domain name. For example, with a search domain of
`example.com`, performing a DNS query for `app` will automatically
expand the query to `app.example.com`. At present, this doesn't work
with Firezone because there is no way to configure an account-wide
search-domain.
With this PR, we extend the `Interface` message sent by the portal to
also include an optional `search_domain` field that must be a valid
domain name. If set, `connlib`'s DNS stub resolver will now append this
domain to all single-label queries and match the resulting domain
against all active DNS resource.
On Linux - with `systemd-resolved` as the DNS backend - we need to set
the search domain on the TUN interface as well and enable LLMNR in order
to be able to intercept these queries. `resolved` expands the query for
us, however, meaning with this configuration, we don't actually receive
a single-label query in `connlib`. Instead, we directly see
`app.example.com` when we type `host app` or `dig +search app` and have
`example.com` as our search domain.
MacOS has a similar system but with a different fallack. There, the
operating system will first try all configured search domains on the
system (typically just the ones set prior to Firezone starting), and
send queries for FQDN to all resolvers. If none of the resolvers
(including Firezone's stub resolver) return results, it sends the
single-label query directly to the primary resolver. To handle this
case, Firezone needs to know about the search-domain and expand it
itself when it receives the single-label query. In the future, we may
want to look into how we can configure MacOS such that it performs this
expansion for us.
On Windows and Android, queries for a single-label domain will be
directly sent to Firezone's stub resolver where we then hit the same
codepath as explained above.
Specifically, the way this codepath works is that if we receive a
single-label query AND we have a search-domain set, we expand it and
match that particular query against our list of resources. In every
other case, we continue on with the single-label domain.
Related: #8365Fixes: #8377
In order to more safely roll out certain changes, being able to
runtime-toggle features is crucial. For this purpose, we build a simple
integration with Posthog that allows us to evaluate feature flags based
on the Firezone ID of a Client or Gateway.
The feature flags are also set in a dedicated context for Sentry events.
This allows us to see, which feature flags were active when a certain
error is logged to Sentry.
UDP is an unreliable transport and thus it can happen that a UDP DNS
query gets lost in transit. Our current algorithm for picking a
nameserver of all provided ones only uses UDP DNS and thus, we may run
into a scenario where we falsely claim to not have nameservers simply
because the UDP request or response got lost in transit.
To mitigate this, we also perform a TCP DNS query to every nameserver.
TCP is reliable and will perform retransmissions in case of packet loss.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
The DNS server added in #8285 was only a dummy DNS server that added
infrastructure to actually receive DNS queries on the IP of the TUN
device at port 53535 and it returns SERVFAIL for all queries. For this
DNS server to be useful, we need to take those queries and replay them
towards a DNS server that is configured locally on the Gateway.
To achieve this, we parse `/etc/resolv.conf` during startup of the
Gateway and pass the contained nameservers into the tunnel. From there,
the Gateway's event-loop can receive the queries, feed them into the
already existing machinery for performing recursive DNS queries that we
use on the Client and resolve the records.
In its current implementation, we only use the first nameserver defined
in `/etc/resolv.conf`. If the lookup fails, we send back a SERVFAIL
error and log a message.
Resolves: #8221
Prior to #8334, we had some logic within the test-suite to only reset
the TCP DNS client if the DNS mapping actually changed. This is
problematic because adding / removing CIDR resources from `connlib` may
cause packets to suddenly be re-routed to a different site. Consider the
case where the Internet Resource is active and we make a DNS query. The
query will be routed to the Internet site. If we then add a CIDR
resource to `connlib` that happens to match the DNS server that is set
as an upstream server, all new packets emitted by the TCP DNS client
will be routed to that new site. However, the DNS server we are talking
to doesn't recognise the new source port as it is routed via a different
Gateway.
This is in fact also a problem with TCP connections in general within
`connlib` when changes to the routing table happen and already tracked
in #7081.
To fix the tests, we need to always reset the DNS servers and the TCP
DNS client whenever any changes to the routes or the DNS mapping
happens.
At present, the TCP DNS server we use in `connlib` exposes an opaque
`SocketHandle` with each received query. This handle refers to the
socket that the query was received on. The response needs to be sent
back on the same socket because it effectively refers to the TCP stream
that was established.
We need to track this `SocketHandle` all the way through to our
user-space DNS client in `connlib` which actually resolves queries with
a DNS server. In order to be able to reuse this DNS client on the
Gateway where we receive DNS queries using a user-space socket (and thus
don't have such a `SocketHandle`), we need to remove this abstraction
from the public API of the TCP DNS server.
A TCP stream is effectively identified by the source and destination
socket address: A given 4-tuple (source IP, source port, destination IP,
destination port) can only ever hold a single TCP connection. As such,
returning the local and remote `SocketAddr` with the query is sufficient
to uniquely identify the socket.
## Description
We want to resolve DNS queries of type SRV & TXT for DNS resources
within the network context of the site that is hosting the DNS resource
itself. This allows admins to e.g. deploy dedicated nameservers into
those sites and have them resolve their SRV and TXT records to names
that are scoped to that particular site.
SRV records themselves return more domains which - if they are
configured as DNS resources - will be intercepted and then routed to the
correct site.
Prior to this PR, SRV & TXT records got resolved by the DNS server
configured on the client (or the server defined in the Firezone portal),
even if the domain in question was a DNS resource. This effectively
meant that those SRV records have to be valid globally and could not be
specific to the site that the DNS resource is hosted in.
## Example
Say we have these wildcard DNS resources:
- `**.department-a.example.com`
- `**.department-b.example.com`
Each of these DNS resources is assigned to a different site. If we now
issue an SRV DNS query to `_my-service.department-a.example.com`, we may
receive back the following records:
- `_my-service.department-a.example.com. 86400 IN SRV 10 60 8080
my-service1.department-a.example.com.`
- `_my-service.department-a.example.com. 86400 IN SRV 10 60 8080
my-service2.department-a.example.com.`
- `_my-service.department-a.example.com. 86400 IN SRV 10 60 8080
my-service3.department-a.example.com.`
Notice how the SRV records point to domains that will also match the
wildcard DNS resource above! If that is the case, Firezone will also
intercept A & AAAA queries for this service (which are a natural
follow-up from an application making an SRV query). As a result, traffic
for `my-service1.department-a.example.com` will be routed to the same
site the DNS resource is defined in. If the returned domains don't match
the wildcard DNS resource, the traffic will either not be intercepted at
all (if it is not a DNS resource) or routed to whichever site defines
the corresponding DNS resource.
All of these scenarios may be what the admin wants. If the SRV records
defined for the DNS resource are globally valid (and e.g. not even
resources), then resolving them using the Client's system resolver may
be all that is needed. If the services are running in a dedicated site,
that traffic should indeed be routed to that site.
As such, Firezone itself cannot make any assumption about the structure
of these records at all. The only thing that is enabled with this PR is
that IF the structure happens to match the same DNS resource, it allows
admins to deploy site-specific services that resolve their concrete
domains via SRV records.
## Testing
The implementation is tested using our property-based testing framework.
In order to cover these cases, we introduce the notion of site-specific
DNS records which are sampled when we create each individual Gateway.
When selecting a domain to query for, all global DNS records and the
site-specific ones are merged and a domain name and query type is chosen
at random.
At present, this testing framework does not assert that the DNS response
itself is correct, i.e. that it actually returned the site-specific
record. We don't assert this for any other DNS queries, hence this is
left for a future extension. We do assert using our regression grep's
that we hit the codepath of querying an SRV or TXT record for a DNS
resource.
Related: #8221
Bumps
[@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node)
from 22.13.0 to 22.13.9.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/node">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>
Bumps [anyhow](https://github.com/dtolnay/anyhow) from 1.0.95 to 1.0.97.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/dtolnay/anyhow/releases">anyhow's
releases</a>.</em></p>
<blockquote>
<h2>1.0.97</h2>
<ul>
<li>Documentation improvements</li>
</ul>
<h2>1.0.96</h2>
<ul>
<li>Documentation improvements</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="bfb89ef244"><code>bfb89ef</code></a>
Release 1.0.97</li>
<li><a
href="c7fca9b086"><code>c7fca9b</code></a>
Ignore elidable_lifetime_names pedantic clippy lint</li>
<li><a
href="427c0bb0f3"><code>427c0bb</code></a>
Point standard library links to stable</li>
<li><a
href="f0aa0d367f"><code>f0aa0d3</code></a>
Release 1.0.96</li>
<li><a
href="bc33c24bd2"><code>bc33c24</code></a>
Convert html links to intra-doc links</li>
<li><a
href="1cff785c76"><code>1cff785</code></a>
Unset doc-scrape-examples for lib target</li>
<li><a
href="d71c806e97"><code>d71c806</code></a>
More precise gitignore patterns</li>
<li><a
href="3e409755ce"><code>3e40975</code></a>
Remove **/*.rs.bk from project-specific gitignore</li>
<li><a
href="b880dd050e"><code>b880dd0</code></a>
Ignore Cargo-generated tests/crate/target directory</li>
<li><a
href="8891ce34b4"><code>8891ce3</code></a>
Merge pull request <a
href="https://redirect.github.com/dtolnay/anyhow/issues/404">#404</a>
from dtolnay/missingabi</li>
<li>Additional commits viewable in <a
href="https://github.com/dtolnay/anyhow/compare/1.0.95...1.0.97">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: Thomas Eizinger <thomas@eizinger.io>
Bumps the tauri group in /rust/gui-client with 2 updates:
[@tauri-apps/api](https://github.com/tauri-apps/tauri) and
[@tauri-apps/cli](https://github.com/tauri-apps/tauri).
Updates `@tauri-apps/api` from 2.2.0 to 2.3.0
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/tauri-apps/tauri/releases"><code>@tauri-apps/api</code>'s
releases</a>.</em></p>
<blockquote>
<h2><code>@tauri-apps/api</code> v2.3.0</h2>
<!-- raw HTML omitted -->
<pre><code>No known vulnerabilities found
</code></pre>
<!-- raw HTML omitted -->
<h2>[2.3.0]</h2>
<h3>Enhancements</h3>
<ul>
<li><a
href="a2d36b8c34"><code>a2d36b8c3</code></a>
(<a
href="https://redirect.github.com/tauri-apps/tauri/pull/12181">#12181</a>
by <a
href="https://www.github.com/tauri-apps/tauri/../../bastiankistner"><code>@bastiankistner</code></a>)
Add an option to change the default background throttling policy
(currently for WebKit only).</li>
</ul>
<!-- raw HTML omitted -->
<pre><code>> @tauri-apps/api@2.3.0 npm-publish
/home/runner/work/tauri/tauri/packages/api
> pnpm build && cd ./dist && pnpm publish --access
public --loglevel silly --no-git-checks
<p>> <code>@tauri-apps/api</code><a
href="https://github.com/2"><code>@2</code></a>.3.0 build
/home/runner/work/tauri/tauri/packages/api
> rollup -c --configPlugin typescript</p>
<p>[36m
[1m./src/app.ts, ./src/core.ts, ./src/dpi.ts, ./src/event.ts,
./src/image.ts, ./src/index.ts, ./src/menu.ts, ./src/mocks.ts,
./src/path.ts, ./src/tray.ts, ./src/webview.ts, ./src/webviewWindow.ts,
./src/window.ts[22m → [1m./dist, ./dist[22m...[39m
[32mcreated [1m./dist, ./dist[22m in [1m1.4s[22m[39m
[36m
[1msrc/index.ts[22m →
[1m../../crates/tauri/scripts/bundle.global.js[22m...[39m
[32mcreated [1m../../crates/tauri/scripts/bundle.global.js[22m in
[1m1.8s[22m[39m
npm verbose cli /opt/hostedtoolcache/node/20.18.3/x64/bin/node
/opt/hostedtoolcache/node/20.18.3/x64/bin/npm
npm info using npm@10.8.2
npm info using node@v20.18.3
npm silly config
load:file:/opt/hostedtoolcache/node/20.18.3/x64/lib/node_modules/npm/npmrc
npm silly config load:file:/tmp/cde6886dbee94df8b0f32d4d1d016777/.npmrc
npm silly config load:file:/home/runner/work/_temp/.npmrc
npm silly config
load:file:/opt/hostedtoolcache/node/20.18.3/x64/etc/npmrc
npm verbose title npm publish tauri-apps-api-2.3.0.tgz
npm verbose argv "publish" "--ignore-scripts"
"tauri-apps-api-2.3.0.tgz" "--access"
"public" "--loglevel" "silly"
"--no-git-checks"
npm verbose logfile logs-max:10
dir:/home/runner/.npm/_logs/2025-02-26T16_09_54_529Z-
npm verbose logfile
/home/runner/.npm/_logs/2025-02-26T16_09_54_529Z-debug-0.log
npm verbose publish [ 'tauri-apps-api-2.3.0.tgz' ]
npm silly logfile done cleaning log files
npm notice
npm notice 📦 <code>@tauri-apps/api</code><a
href="https://github.com/2"><code>@2</code></a>.3.0
npm notice Tarball Contents
npm notice 86.9kB CHANGELOG.md
</tr></table>
</code></pre></p>
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="7d618f12d8"><code>7d618f1</code></a>
apply version updates (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12518">#12518</a>)</li>
<li><a
href="385a41dea2"><code>385a41d</code></a>
enhance(windows): disable our in-client resizing for undecorated window
with ...</li>
<li><a
href="955832e56b"><code>955832e</code></a>
ci: Build win-arm64 cli with rustls (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12813">#12813</a>)</li>
<li><a
href="c116dfcdee"><code>c116dfc</code></a>
fix(cli): Hide <code>updater</code> bundle target in help output (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12801">#12801</a>)</li>
<li><a
href="d6520a21ce"><code>d6520a2</code></a>
chore(deps): wry@0.50muda@0.16tray-icon@0.20windows@0.60webview2-com@0.36...</li>
<li><a
href="ab81adb71b"><code>ab81adb</code></a>
docs: improve documentation around incognito and data store (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12806">#12806</a>)</li>
<li><a
href="6e417c9435"><code>6e417c9</code></a>
fix(linux): Add missing RPM signature (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12786">#12786</a>)</li>
<li><a
href="ddc469367a"><code>ddc4693</code></a>
style: fix Vite and React branding (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12768">#12768</a>)</li>
<li><a
href="d7b998fe71"><code>d7b998f</code></a>
fix(tauri): deprecate <code>Manager::unmanage</code> to fix
<code>use-after-free</code> (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12723">#12723</a>)</li>
<li><a
href="d9a07e66af"><code>d9a07e6</code></a>
chore(deps): update dependency globals to v16 (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12750">#12750</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/tauri-apps/tauri/compare/@tauri-apps/api-v2.2.0...@tauri-apps/api-v2.3.0">compare
view</a></li>
</ul>
</details>
<br />
Updates `@tauri-apps/cli` from 2.2.7 to 2.3.1
<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> v2.3.1</h2>
<h2>[2.3.1]</h2>
<h3>Dependencies</h3>
<ul>
<li>Upgraded to <code>tauri-cli@2.3.1</code></li>
</ul>
<h2><code>@tauri-apps/cli</code> v2.3.0</h2>
<h2>[2.3.0]</h2>
<h3>Enhancements</h3>
<ul>
<li><a
href="a2d36b8c34"><code>a2d36b8c3</code></a>
(<a
href="https://redirect.github.com/tauri-apps/tauri/pull/12181">#12181</a>
by <a
href="https://www.github.com/tauri-apps/tauri/../../bastiankistner"><code>@bastiankistner</code></a>)
Add an option to change the default background throttling policy
(currently for WebKit only).</li>
</ul>
<h3>Dependencies</h3>
<ul>
<li>Upgraded to <code>tauri-cli@2.3.0</code></li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="cab7f76d01"><code>cab7f76</code></a>
apply version updates (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12826">#12826</a>)</li>
<li><a
href="e103e87f15"><code>e103e87</code></a>
fix(windows): ensure APIs exist before using it (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12848">#12848</a>)</li>
<li><a
href="bca02967a9"><code>bca0296</code></a>
docs: Update wording from <a
href="https://redirect.github.com/tauri-apps/tauri/issues/12830">#12830</a>
(<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12839">#12839</a>)</li>
<li><a
href="887db0813f"><code>887db08</code></a>
chore(deps): update js dependencies (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12832">#12832</a>)</li>
<li><a
href="4f26dcf309"><code>4f26dcf</code></a>
fix(deps): os webview not gated in wry feature (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12833">#12833</a>)</li>
<li><a
href="4bffc326ea"><code>4bffc32</code></a>
docs: update
<code>WebViewBuilder::with_asynchronous_custom_protocol</code> with
platfor...</li>
<li><a
href="b859dc43fc"><code>b859dc4</code></a>
chore(deps): update rust crate resvg to 0.45.0 (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12825">#12825</a>)</li>
<li><a
href="9332132239"><code>9332132</code></a>
chore(deps): update dependency eslint-config-prettier to v10.0.2 (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12822">#12822</a>)</li>
<li><a
href="22e9bf74a4"><code>22e9bf7</code></a>
fix(cli/ios): Configure initial view controller for the launch screen on
iOS ...</li>
<li><a
href="b495fe0fdc"><code>b495fe0</code></a>
ci: install corepack in docker (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12824">#12824</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/tauri-apps/tauri/compare/@tauri-apps/cli-v2.2.7...@tauri-apps/cli-v2.3.1">compare
view</a></li>
</ul>
</details>
<br />
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: Thomas Eizinger <thomas@eizinger.io>
Currently - because we know all our upstream DNS servers at the time of
initialisation - we configure them on the TCP DNS client in `connlib`
upfront. This allocates the necessary ports and sockets to emit TCP
packets for queries that we want to send to upstream DNS servers, e.g.
if the Internet Resource is active or if the Firezone-configured
upstream DNS server is also a CIDR resource.
In order to resolve SRV and TXT records within the DNS context of a site
(#8221), we need to send DNS queries to the Gateway's TUN device which
now hosts a DNS server on port 53535 (#8285). The IPs of Gateway's
aren't known until we connect to them, meaning we cannot include them in
the set of upstream resolver IPs that we want our DNS-over-TCP client to
connect to.
To be able to reuse the same library, we refactor the
`dns_over_tcp::Client` implementation to dynamically allocate sockets
for upstream resolvers. With that in place, we will be able to send
DNS-over-TCP queries to Gateway's in case the application requests SRV
or TXT records for a DNS resource.
Related: #8221
To support resolving SRV and TXT records for DNS-resources, we host a
DNS server on UDP/53535 and TCP/53535 on the IPv4 and IPv6 IP of the
Gateway's TUN device. This will later be used by connlib to send DNS
queries of particular types (concretely SRV and TXT) to the Gateway
itself.
With this PR, this DNS server is already functional and reachable but it
will answer all queries with SERVFAIL. Actual handling of these queries
is left to a future PR.
We listen on port 53535 because:
- Port 53 may be taken by another DNS server running on the customer's
machine where they deploy the Gateway
- Port 5353 is the standard port for mDNS
- I could not find anything on the Internet about it being used by a
specific application
In theory, we could also bind to a random port but then we'd have to
communicate this port somehow to the client. This could be done using a
control protocol message but it just makes things more complicated. For
example, there would be additional buffering needed on the Client side
for the time-period where we've established a connection to the Gateway
already but haven't received the control protocol message yet, at which
port the Gateway is hosting the DNS server.
If one knows the Gateway's IP (and has a connection to it already), this
DNS server will be usable by users with standard DNS tools such as
`dig`:
```sh
dig @100.76.212.99 -p 53535 example.com
```
Related: #8221
