mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 18:18:55 +00:00
aaa278f6ce04fa2a15e7fc89ff8b2ce7d206889c
2078 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Thomas Eizinger
|
aaa278f6ce |
build(rust): bump ring dependency (#8379)
Resolves: https://rustsec.org/advisories/RUSTSEC-2025-0009 |
||
|
Thomas Eizinger
|
3273abf64b |
fix(connlib): use TCP as well to pick fastest nameserver (#8372)
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> |
||
|
Thomas Eizinger
|
eacf67f2bc |
feat(gateway): forward queries to local nameserver (#8350)
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 |
||
|
Thomas Eizinger
|
7bf401ee8d |
fix(connlib): always reset TCP DNS client connections (#8364)
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. |
||
|
Thomas Eizinger
|
e534207bbd |
refactor(connlib): remove SocketHandle from TCP DNS server API (#8360)
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. |
||
|
Thomas Eizinger
|
99d8fcb8fc |
feat(connlib): resolve SRV & TXT queries for resources in sites (#8335)
## 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 |
||
|
dependabot[bot]
|
1650671508 |
build(deps-dev): bump @types/node from 22.13.0 to 22.13.9 in /rust/gui-client (#8343)
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> |
||
|
dependabot[bot]
|
6953e90d97 |
build(deps): bump anyhow from 1.0.95 to 1.0.97 in /rust (#8338)
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=" |
||
|
dependabot[bot]
|
883c8c173d |
build(deps): bump log from 0.4.25 to 0.4.26 in /rust (#8337)
Bumps [log](https://github.com/rust-lang/log) from 0.4.25 to 0.4.26. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/rust-lang/log/releases">log's releases</a>.</em></p> <blockquote> <h2>0.4.26</h2> <h2>What's Changed</h2> <ul> <li>Derive <code>Clone</code> for <code>kv::Value</code> by <a href="https://github.com/SpriteOvO"><code>@SpriteOvO</code></a> in <a href="https://redirect.github.com/rust-lang/log/pull/668">rust-lang/log#668</a></li> <li>Add <code>spdlog-rs</code> link to crate doc by <a href="https://github.com/SpriteOvO"><code>@SpriteOvO</code></a> in <a href="https://redirect.github.com/rust-lang/log/pull/669">rust-lang/log#669</a></li> <li>Prepare for 0.4.26 release by <a href="https://github.com/KodrAus"><code>@KodrAus</code></a> in <a href="https://redirect.github.com/rust-lang/log/pull/670">rust-lang/log#670</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/rust-lang/log/compare/0.4.25...0.4.26">https://github.com/rust-lang/log/compare/0.4.25...0.4.26</a></p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/rust-lang/log/blob/master/CHANGELOG.md">log's changelog</a>.</em></p> <blockquote> <h2>[0.4.26] - 2025-02-18</h2> <h2>What's Changed</h2> <ul> <li>Derive <code>Clone</code> for <code>kv::Value</code> by <a href="https://github.com/SpriteOvO"><code>@SpriteOvO</code></a> in <a href="https://redirect.github.com/rust-lang/log/pull/668">rust-lang/log#668</a></li> <li>Add <code>spdlog-rs</code> link to crate doc by <a href="https://github.com/SpriteOvO"><code>@SpriteOvO</code></a> in <a href="https://redirect.github.com/rust-lang/log/pull/669">rust-lang/log#669</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/rust-lang/log/compare/0.4.25...0.4.26">https://github.com/rust-lang/log/compare/0.4.25...0.4.26</a></p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
dependabot[bot]
|
a6110d7f5f |
build(deps): bump the tauri group in /rust/gui-client with 2 updates (#8324)
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=" |
||
|
Thomas Eizinger
|
91c6242ccc |
refactor(connlib): dynamic sockets for upstream TCP DNS servers (#8334)
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 |
||
|
Thomas Eizinger
|
36cefe3f20 |
test(connlib): don't generate CIDR resources in CG-NAT range (#8333)
Strategy for generating CIDR resources needs adjustment to not generate IPs in the CG-NAT range that we use for peers. Related: #8294 |
||
|
Thomas Eizinger
|
3978661fbc |
feat(gateway): run a DNS resolver on $tun_ip:53535 (#8285)
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 |
||
|
Thomas Eizinger
|
eac2516e18 |
refactor(connlib): decouple mangled DNS queries from DNS mapping (#8331)
When `connlib` receives a UDP packet for one of its DNS resolver IPs and determines that it needs to be forwarded to another resolver through the tunnel, it mangles the destination IP + port to point to this new resolver. In order for the response to be correctly recognised by the application, the response packet needs its _source_ IP + port mangled. This information is currently stored in a `HashMap` together with an expiry timestamp. To be precise, the information that is captured is only the new destination socket, not the current one. The old socket is then later implied by the DNS mapping that we remember internally, i.e. which one of `connlib`'s DNS resolver IPs maps to which upstream DNS server. For the usecase of forwarding DNS queries of type SRV and TXT to the site that hosts the DNS resource in question, we want to send those DNS queries to a Gateway within that site. For UDP DNS queries, this requires the same data structure as we do for DNS queries that are tunneled to another DNS resolver _beyond_ the Gateway. In fact, from the perspective of the Client, there is no difference between a packet that is handled by the Gateway or by a resolver behind the Gateway. The only difference is in the new destination IP + port. In the case where the Gateway is targeted with the DNS query, we won't be able to resolve the original destination socket from the DNS mapping data structure because the Gateway's IP isn't explicitly configured as a DNS resolver. To handle both of these cases with the same data structure, we refactor this temporary mapping to simply store the original destination socket. To make the data structure less complicated to use, we introduce an `ExpiringMap` that automatically removes entries after a certain deadline. This is important for UDP DNS queries to ensure this map doesn't in an unbounded manner if for some reason, the configured DNS resolver never replies. Related: #8221 |
||
|
Thomas Eizinger
|
e63f1cb4da |
feat(connlib): allow and route packets to Gateway TUN IPs (#8294)
At the moment, `connlib` doesn't allow routing packets directly to Gateways because the subnet we've chosen for the tunnel IPs isn't part of the routing table. In addition, all traffic within `connlib` is expected to be targeting a resource _beyond_ a Gateway. In order to resolve SRV and TXT records within a certain site, we've opted to host a DNS server on the Gateway's TUN device. See #8285 for details on that. To actually reach that DNS server, we need to add a few new control flows to `connlib` where we detect whether a packet is directly for the tunnel IP of a Gateway or for a resource. We only know a Gateway's IP once we are connected to it, meaning we cannot route those packets prior to that. We also cannot establish a connection when the user attempts to as every connection intent sent to the portal needs to reference a Resource. For the usecase of resolving SRV and TXT records, the packets will be associated with the DNS resource for which we are trying to resolve records. This patch only established the base connectivity and necessary exceptions to the Client's filter rules in order to route packets to the Gateway's TUN device. The following commands have been issued against a staging Gateway, demonstrating connectivity to the Gateway's TUN device from a Client after establishing a connection to it: ``` ❯ ping github.com -c 1 PING github.com (fd00:2021:1111:8000::) 56 data bytes 64 bytes from github.com (fd00:2021:1111:8000::): icmp_seq=1 ttl=50 time=1441 ms --- github.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1440.614/1440.614/1440.614/0.000 ms ❯ ping 100.72.145.83 -c 1 PING 100.72.145.83 (100.72.145.83) 56(84) bytes of data. 64 bytes from 100.72.145.83: icmp_seq=1 ttl=64 time=213 ms --- 100.72.145.83 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 212.574/212.574/212.574/0.000 ms ``` Related: #8221 |
||
|
dependabot[bot]
|
7957d671c5 |
build(deps-dev): bump tailwindcss from 4.0.3 to 4.0.9 in /rust/gui-client (#8326)
Bumps [tailwindcss](https://github.com/tailwindlabs/tailwindcss/tree/HEAD/packages/tailwindcss) from 4.0.3 to 4.0.9. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/tailwindlabs/tailwindcss/releases">tailwindcss's releases</a>.</em></p> <blockquote> <h2>v4.0.9</h2> <h3>Fixed</h3> <ul> <li>Make JS APIs available to plugins and configs in the Standalone CLI (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/15934">#15934</a>)</li> <li>Vite: Don't crash when importing a virtual module from JavaScript that ends in <code>.css</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16780">#16780</a>)</li> <li>Fix an issue where <code>@reference "…"</code> would sometimes omit keyframe animations (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16774">#16774</a>)</li> <li>Ensure <code>z-*!</code> utilities are properly marked as <code>!important</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16795">#16795</a>)</li> <li>Read UTF-8 CSS files that start with a byte-order mark (BOM) (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16800">#16800</a>)</li> <li>Ensure nested functions in selectors used with JavaScript plugins are not truncated (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16802">#16802</a>)</li> </ul> <h3>Changed</h3> <ul> <li>Emit variable fallbacks when using <code>@reference "…"</code> instead of duplicate CSS variable declarations (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16774">#16774</a>)</li> </ul> <h2>v4.0.8</h2> <h3>Added</h3> <ul> <li>Allow <code>@import</code> with <code>theme(…)</code> options for stylesheets that contain more than just <code>@theme</code> rules (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16514">#16514</a>)</li> </ul> <h3>Fixed</h3> <ul> <li>Don't add <code>!important</code> to CSS variable declarations when using the important modifier (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16668">#16668</a>)</li> <li>Vite: Ignore files and directories specified in your <code>.gitignore</code> file when using automatic source detection(<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16631">#16631</a>)</li> <li>Vite: Don't rely on the module graph for detecting candidates to ensure setups with multiple Vite builds work as expected (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16631">#16631</a>)</li> <li>Vite: Ensure Astro production builds always contain classes used in client-only components (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16631">#16631</a>)</li> <li>Vite: Always scan raw file contents for utility classes before any other transforms have been applied to ensure utility classes are scanned without any additional escaping (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16631">#16631</a>)</li> <li>Ensure utilities with more declarations are always sorted before utilities with fewer declarations when utilities only define CSS variables (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16715">#16715</a>)</li> <li>Only include <code>translate-z-px</code> utilities once in compiled CSS (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16718">#16718</a>)</li> </ul> <h3>Changed</h3> <ul> <li>Don't include theme variables that aren't used in compiled CSS (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16211">#16211</a>, <a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16676">#16676</a>)</li> </ul> <h2>v4.0.7</h2> <h3>Fixed</h3> <ul> <li>Export <code>tailwindcss/lib/util/flattenColorPalette.js</code> for backward compatibility (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16411">#16411</a>)</li> <li>Fix sorting of numeric utility suggestions when they have different magnitudes (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16414">#16414</a>)</li> <li>Show suggestions for fractions in IntelliSense (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16353">#16353</a>)</li> <li>Don’t replace <code>_</code> in suggested theme keys (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16433">#16433</a>)</li> <li>Ensure <code>--default-outline-width</code> can be used to change the <code>outline-width</code> value of the <code>outline</code> utility (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16469">#16469</a>)</li> <li>Ensure drop shadow utilities don't inherit unexpectedly (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16471">#16471</a>)</li> <li>Export config and plugin types from <code>tailwindcss/plugin</code> for backward compatibility (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16505">#16505</a>)</li> <li>Ensure JavaScript plugins that emit nested rules referencing the utility name work as expected (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16539">#16539</a>)</li> <li>Statically link Visual Studio redistributables in <code>@tailwindcss/oxide</code> Windows builds (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16602">#16602</a>)</li> <li>Ensure that Next.js splat routes are scanned for classes (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16457">#16457</a>)</li> <li>Pin exact version of <code>tailwindcss</code> in <code>@tailwindcss/*</code> packages (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16623">#16623</a>)</li> <li>Upgrade: Report errors when updating dependencies (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16504">#16504</a>)</li> <li>Upgrade: Ensure a <code>darkMode</code> JS config setting with block syntax converts to use <code>@slot</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16507">#16507</a>)</li> <li>Upgrade: Ensure the latest version of <code>tailwindcss</code> and <code>@tailwindcss/postcss</code> are installed when upgrading (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16620">#16620</a>)</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/tailwindlabs/tailwindcss/blob/main/CHANGELOG.md">tailwindcss's changelog</a>.</em></p> <blockquote> <h2>[4.0.9] - 2025-02-25</h2> <h3>Fixed</h3> <ul> <li>Make JS APIs available to plugins and configs in the Standalone CLI (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/15934">#15934</a>)</li> <li>Vite: Don't crash when importing a virtual module from JavaScript that ends in <code>.css</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16780">#16780</a>)</li> <li>Fix an issue where <code>@reference "…"</code> would sometimes omit keyframe animations (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16774">#16774</a>)</li> <li>Ensure <code>z-*!</code> utilities are properly marked as <code>!important</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16795">#16795</a>)</li> <li>Read UTF-8 CSS files that start with a byte-order mark (BOM) (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16800">#16800</a>)</li> <li>Ensure nested functions in selectors used with JavaScript plugins are not truncated (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16802">#16802</a>)</li> </ul> <h3>Changed</h3> <ul> <li>Emit variable fallbacks when using <code>@reference "…"</code> instead of duplicate CSS variable declarations (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16774">#16774</a>)</li> </ul> <h2>[4.0.8] - 2025-02-21</h2> <h3>Added</h3> <ul> <li>Allow <code>@import</code> with <code>theme(…)</code> options for stylesheets that contain more than just <code>@theme</code> rules (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16514">#16514</a>)</li> </ul> <h3>Fixed</h3> <ul> <li>Don't add <code>!important</code> to CSS variable declarations when using the important modifier (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16668">#16668</a>)</li> <li>Vite: Ignore files and directories specified in your <code>.gitignore</code> file when using automatic source detection(<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16631">#16631</a>)</li> <li>Vite: Don't rely on the module graph for detecting candidates to ensure setups with multiple Vite builds work as expected (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16631">#16631</a>)</li> <li>Vite: Ensure Astro production builds always contain classes used in client-only components (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16631">#16631</a>)</li> <li>Vite: Always scan raw file contents for utility classes before any other transforms have been applied to ensure utility classes are scanned without any additional escaping (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16631">#16631</a>)</li> <li>Ensure utilities with more declarations are always sorted before utilities with fewer declarations when utilities only define CSS variables (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16715">#16715</a>)</li> <li>Only include <code>translate-z-px</code> utilities once in compiled CSS (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16718">#16718</a>)</li> </ul> <h3>Changed</h3> <ul> <li>Don't include theme variables that aren't used in compiled CSS (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16211">#16211</a>, <a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16676">#16676</a>)</li> </ul> <h2>[4.0.7] - 2025-02-18</h2> <h3>Fixed</h3> <ul> <li>Export <code>tailwindcss/lib/util/flattenColorPalette.js</code> for backward compatibility (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16411">#16411</a>)</li> <li>Fix sorting of numeric utility suggestions when they have different magnitudes (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16414">#16414</a>)</li> <li>Show suggestions for fractions in IntelliSense (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16353">#16353</a>)</li> <li>Don’t replace <code>_</code> in suggested theme keys (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16433">#16433</a>)</li> <li>Ensure <code>--default-outline-width</code> can be used to change the <code>outline-width</code> value of the <code>outline</code> utility (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16469">#16469</a>)</li> <li>Ensure drop shadow utilities don't inherit unexpectedly (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16471">#16471</a>)</li> <li>Export config and plugin types from <code>tailwindcss/plugin</code> for backward compatibility (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16505">#16505</a>)</li> <li>Ensure JavaScript plugins that emit nested rules referencing the utility name work as expected (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16539">#16539</a>)</li> <li>Statically link Visual Studio redistributables in <code>@tailwindcss/oxide</code> Windows builds (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16602">#16602</a>)</li> <li>Ensure that Next.js splat routes are scanned for classes (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16457">#16457</a>)</li> <li>Pin exact version of <code>tailwindcss</code> in <code>@tailwindcss/*</code> packages (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16623">#16623</a>)</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
dependabot[bot]
|
eab3a8888d |
build(deps): bump @tailwindcss/cli from 4.0.3 to 4.0.9 in /rust/gui-client (#8327)
Bumps [@tailwindcss/cli](https://github.com/tailwindlabs/tailwindcss/tree/HEAD/packages/@tailwindcss-cli) from 4.0.3 to 4.0.9. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/tailwindlabs/tailwindcss/releases"><code>@tailwindcss/cli</code>'s releases</a>.</em></p> <blockquote> <h2>v4.0.9</h2> <h3>Fixed</h3> <ul> <li>Make JS APIs available to plugins and configs in the Standalone CLI (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/15934">#15934</a>)</li> <li>Vite: Don't crash when importing a virtual module from JavaScript that ends in <code>.css</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16780">#16780</a>)</li> <li>Fix an issue where <code>@reference "…"</code> would sometimes omit keyframe animations (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16774">#16774</a>)</li> <li>Ensure <code>z-*!</code> utilities are properly marked as <code>!important</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16795">#16795</a>)</li> <li>Read UTF-8 CSS files that start with a byte-order mark (BOM) (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16800">#16800</a>)</li> <li>Ensure nested functions in selectors used with JavaScript plugins are not truncated (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16802">#16802</a>)</li> </ul> <h3>Changed</h3> <ul> <li>Emit variable fallbacks when using <code>@reference "…"</code> instead of duplicate CSS variable declarations (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16774">#16774</a>)</li> </ul> <h2>v4.0.8</h2> <h3>Added</h3> <ul> <li>Allow <code>@import</code> with <code>theme(…)</code> options for stylesheets that contain more than just <code>@theme</code> rules (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16514">#16514</a>)</li> </ul> <h3>Fixed</h3> <ul> <li>Don't add <code>!important</code> to CSS variable declarations when using the important modifier (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16668">#16668</a>)</li> <li>Vite: Ignore files and directories specified in your <code>.gitignore</code> file when using automatic source detection(<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16631">#16631</a>)</li> <li>Vite: Don't rely on the module graph for detecting candidates to ensure setups with multiple Vite builds work as expected (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16631">#16631</a>)</li> <li>Vite: Ensure Astro production builds always contain classes used in client-only components (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16631">#16631</a>)</li> <li>Vite: Always scan raw file contents for utility classes before any other transforms have been applied to ensure utility classes are scanned without any additional escaping (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16631">#16631</a>)</li> <li>Ensure utilities with more declarations are always sorted before utilities with fewer declarations when utilities only define CSS variables (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16715">#16715</a>)</li> <li>Only include <code>translate-z-px</code> utilities once in compiled CSS (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16718">#16718</a>)</li> </ul> <h3>Changed</h3> <ul> <li>Don't include theme variables that aren't used in compiled CSS (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16211">#16211</a>, <a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16676">#16676</a>)</li> </ul> <h2>v4.0.7</h2> <h3>Fixed</h3> <ul> <li>Export <code>tailwindcss/lib/util/flattenColorPalette.js</code> for backward compatibility (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16411">#16411</a>)</li> <li>Fix sorting of numeric utility suggestions when they have different magnitudes (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16414">#16414</a>)</li> <li>Show suggestions for fractions in IntelliSense (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16353">#16353</a>)</li> <li>Don’t replace <code>_</code> in suggested theme keys (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16433">#16433</a>)</li> <li>Ensure <code>--default-outline-width</code> can be used to change the <code>outline-width</code> value of the <code>outline</code> utility (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16469">#16469</a>)</li> <li>Ensure drop shadow utilities don't inherit unexpectedly (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16471">#16471</a>)</li> <li>Export config and plugin types from <code>tailwindcss/plugin</code> for backward compatibility (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16505">#16505</a>)</li> <li>Ensure JavaScript plugins that emit nested rules referencing the utility name work as expected (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16539">#16539</a>)</li> <li>Statically link Visual Studio redistributables in <code>@tailwindcss/oxide</code> Windows builds (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16602">#16602</a>)</li> <li>Ensure that Next.js splat routes are scanned for classes (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16457">#16457</a>)</li> <li>Pin exact version of <code>tailwindcss</code> in <code>@tailwindcss/*</code> packages (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16623">#16623</a>)</li> <li>Upgrade: Report errors when updating dependencies (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16504">#16504</a>)</li> <li>Upgrade: Ensure a <code>darkMode</code> JS config setting with block syntax converts to use <code>@slot</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16507">#16507</a>)</li> <li>Upgrade: Ensure the latest version of <code>tailwindcss</code> and <code>@tailwindcss/postcss</code> are installed when upgrading (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16620">#16620</a>)</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/tailwindlabs/tailwindcss/blob/main/CHANGELOG.md"><code>@tailwindcss/cli</code>'s changelog</a>.</em></p> <blockquote> <h2>[4.0.9] - 2025-02-25</h2> <h3>Fixed</h3> <ul> <li>Make JS APIs available to plugins and configs in the Standalone CLI (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/15934">#15934</a>)</li> <li>Vite: Don't crash when importing a virtual module from JavaScript that ends in <code>.css</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16780">#16780</a>)</li> <li>Fix an issue where <code>@reference "…"</code> would sometimes omit keyframe animations (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16774">#16774</a>)</li> <li>Ensure <code>z-*!</code> utilities are properly marked as <code>!important</code> (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16795">#16795</a>)</li> <li>Read UTF-8 CSS files that start with a byte-order mark (BOM) (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16800">#16800</a>)</li> <li>Ensure nested functions in selectors used with JavaScript plugins are not truncated (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16802">#16802</a>)</li> </ul> <h3>Changed</h3> <ul> <li>Emit variable fallbacks when using <code>@reference "…"</code> instead of duplicate CSS variable declarations (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16774">#16774</a>)</li> </ul> <h2>[4.0.8] - 2025-02-21</h2> <h3>Added</h3> <ul> <li>Allow <code>@import</code> with <code>theme(…)</code> options for stylesheets that contain more than just <code>@theme</code> rules (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16514">#16514</a>)</li> </ul> <h3>Fixed</h3> <ul> <li>Don't add <code>!important</code> to CSS variable declarations when using the important modifier (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16668">#16668</a>)</li> <li>Vite: Ignore files and directories specified in your <code>.gitignore</code> file when using automatic source detection(<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16631">#16631</a>)</li> <li>Vite: Don't rely on the module graph for detecting candidates to ensure setups with multiple Vite builds work as expected (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16631">#16631</a>)</li> <li>Vite: Ensure Astro production builds always contain classes used in client-only components (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16631">#16631</a>)</li> <li>Vite: Always scan raw file contents for utility classes before any other transforms have been applied to ensure utility classes are scanned without any additional escaping (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16631">#16631</a>)</li> <li>Ensure utilities with more declarations are always sorted before utilities with fewer declarations when utilities only define CSS variables (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16715">#16715</a>)</li> <li>Only include <code>translate-z-px</code> utilities once in compiled CSS (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16718">#16718</a>)</li> </ul> <h3>Changed</h3> <ul> <li>Don't include theme variables that aren't used in compiled CSS (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16211">#16211</a>, <a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16676">#16676</a>)</li> </ul> <h2>[4.0.7] - 2025-02-18</h2> <h3>Fixed</h3> <ul> <li>Export <code>tailwindcss/lib/util/flattenColorPalette.js</code> for backward compatibility (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16411">#16411</a>)</li> <li>Fix sorting of numeric utility suggestions when they have different magnitudes (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16414">#16414</a>)</li> <li>Show suggestions for fractions in IntelliSense (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16353">#16353</a>)</li> <li>Don’t replace <code>_</code> in suggested theme keys (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16433">#16433</a>)</li> <li>Ensure <code>--default-outline-width</code> can be used to change the <code>outline-width</code> value of the <code>outline</code> utility (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16469">#16469</a>)</li> <li>Ensure drop shadow utilities don't inherit unexpectedly (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16471">#16471</a>)</li> <li>Export config and plugin types from <code>tailwindcss/plugin</code> for backward compatibility (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16505">#16505</a>)</li> <li>Ensure JavaScript plugins that emit nested rules referencing the utility name work as expected (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16539">#16539</a>)</li> <li>Statically link Visual Studio redistributables in <code>@tailwindcss/oxide</code> Windows builds (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16602">#16602</a>)</li> <li>Ensure that Next.js splat routes are scanned for classes (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16457">#16457</a>)</li> <li>Pin exact version of <code>tailwindcss</code> in <code>@tailwindcss/*</code> packages (<a href="https://redirect.github.com/tailwindlabs/tailwindcss/pull/16623">#16623</a>)</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
dependabot[bot]
|
4ea455a66e |
build(deps-dev): bump vite from 6.0.11 to 6.2.0 in /rust/gui-client (#8328)
Bumps [vite](https://github.com/vitejs/vite/tree/HEAD/packages/vite) from 6.0.11 to 6.2.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/vitejs/vite/releases">vite's releases</a>.</em></p> <blockquote> <h2>create-vite@6.2.0</h2> <p>Please refer to <a href="https://github.com/vitejs/vite/blob/create-vite@6.2.0/packages/create-vite/CHANGELOG.md">CHANGELOG.md</a> for details.</p> <h2>v6.2.0</h2> <p>Please refer to <a href="https://github.com/vitejs/vite/blob/v6.2.0/packages/vite/CHANGELOG.md">CHANGELOG.md</a> for details.</p> <h2>v6.2.0-beta.1</h2> <p>Please refer to <a href="https://github.com/vitejs/vite/blob/v6.2.0-beta.1/packages/vite/CHANGELOG.md">CHANGELOG.md</a> for details.</p> <h2>v6.2.0-beta.0</h2> <p>Please refer to <a href="https://github.com/vitejs/vite/blob/v6.2.0-beta.0/packages/vite/CHANGELOG.md">CHANGELOG.md</a> for details.</p> <h2>create-vite@6.1.1</h2> <p>Please refer to <a href="https://github.com/vitejs/vite/blob/create-vite@6.1.1/packages/create-vite/CHANGELOG.md">CHANGELOG.md</a> for details.</p> <h2>v6.1.1</h2> <p>Please refer to <a href="https://github.com/vitejs/vite/blob/v6.1.1/packages/vite/CHANGELOG.md">CHANGELOG.md</a> for details.</p> <h2>create-vite@6.1.0</h2> <p>Please refer to <a href="https://github.com/vitejs/vite/blob/create-vite@6.1.0/packages/create-vite/CHANGELOG.md">CHANGELOG.md</a> for details.</p> <h2>v6.1.0</h2> <p>Please refer to <a href="https://github.com/vitejs/vite/blob/v6.1.0/packages/vite/CHANGELOG.md">CHANGELOG.md</a> for details.</p> <h2>v6.1.0-beta.2</h2> <p>Please refer to <a href="https://github.com/vitejs/vite/blob/v6.1.0-beta.2/packages/vite/CHANGELOG.md">CHANGELOG.md</a> for details.</p> <h2>v6.1.0-beta.1</h2> <p>Please refer to <a href="https://github.com/vitejs/vite/blob/v6.1.0-beta.1/packages/vite/CHANGELOG.md">CHANGELOG.md</a> for details.</p> <h2>v6.1.0-beta.0</h2> <p>Please refer to <a href="https://github.com/vitejs/vite/blob/v6.1.0-beta.0/packages/vite/CHANGELOG.md">CHANGELOG.md</a> for details.</p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/vitejs/vite/blob/main/packages/vite/CHANGELOG.md">vite's changelog</a>.</em></p> <blockquote> <h2>6.2.0 (2025-02-25)</h2> <ul> <li>fix(deps): update all non-major dependencies (<a href="https://github.com/vitejs/vite/tree/HEAD/packages/vite/issues/19501">#19501</a>) (<a href=" |
||
|
Jamil
|
d71fdbf269 |
fix(connlib): Always emit_resources_changed (#8297)
When adding a new Resource that has the same address as a previous Resource, we would fail to call `emit_resources_changed`, and the Resource would fail to show up in the client's resource list. This happened because we essentially didn't consider "activating" the resource if the resource address didn't change. With this PR, we always do the following: - DNS Resource: Add address to the stub resolver -> no-op if address exists - CIDR Resource: `maybe_update_cidr_resources` -> no-op if duplicate CIDR is added - Internet Resource: No-op if resource ID doesn't change (it shouldn't ever) Since we remove the early-exit logic, the `maybe_update_tun_routes` and `emit_resources_changed` is always called. `maybe_update_tun_routes` is a no-op if the address hasn't changed, so the early-exit logic to avoid calling that seems to be redundant. ## Tested: - [x] Adding / removing a resource - [x] Updating a resource's fields individually, observing the client resource updates properly - [x] Adding two CIDR resources with the same address, observing that the routing table _was not updated_ (thus no disruption to packet flows). Fixes #8100 |
||
|
Jamil
|
1bd8051aae |
fix(connlib): Emit resources updated when display fields change (#8286)
Whenever a Resource's name, address_description, or assigned sites change, it is not currently reflected in clients. For that to happen the address is changed. This PR updates that behavior so that if any display fields are changed, the `on_update_resources` callback is called which properly updates the resource list views in clients. Fixes #8284 |
||
|
Thomas Eizinger
|
f222cb893e |
fix(connlib): be more lenient in deserialising resources (#8289)
At present, `connlib` can process a resource list gracefully that handles unknown resource types. If a known type fails to match the schema however, we fail to deserialise the entire list. To reduce the blast radius of potential bugs here, we accept everything that is valid JSON as the "value" of a resource. Only when processing the individual items will we attempt to deserialise it into the expected model, skipping any resources that cannot be deserialised. |
||
|
Thomas Eizinger
|
315d99f723 |
feat(gateway): allow tunneling packets to and from TUN device (#8283)
At present, Clients are only allowed to send packets to resources accessible via the Gateway but not to the Gateway itself. Thus, any application (including Firezone itself) that opens a listening socket on the TUN device will never receive any traffic. This has opens up interesting features like hosting additional services on the machine that the Gateway is running on. Concretely, in order to implement #8221, we will run a DNS server on port 53 of the TUN device as part of the Gateway. The diff for this ended up being a bit larger because we are introducing an `IpConfig` abstraction so we don't have to track 4 IP addresses as separate fields within `ClientOnGateway`; the connection-specific state on a Gateway. This is where we allow / deny traffic from a Client. To allow traffic for this particular Gateway, we need to know our own TUN IP configuration within the component. |
||
|
Thomas Eizinger
|
325604b3dd |
build(rust): bump str0m to v0.7.0 (#8277)
Good to get rid of patch dependencies where possible. |
||
|
Thomas Eizinger
|
10314e2540 |
chore(phoenix-channel): immediately retry on first error (#8238)
Currently, we wait for the first "backoff" duration when the WebSocket disconnects. Instead, we should just try to reconnect immediately and only wait if we hit another error. |
||
|
Thomas Eizinger
|
b8c4001848 |
fix(connlib): don't buffer exact & TCP SYN retransmissions (#8273)
Whilst we are establishing a connection, the host network stack may run into timeouts and retransmit packets. Buffering these copies doesn't make any sense because we are then just flooding the remote with e.g. 4 TCP SYNs for the same connection. This check is O(N) with the number of buffered packets. Those are at most a few dozens so there shouldn't be a need for anything more efficient. |
||
|
Jamil
|
14436908d2 | chore: Release GUI client 1.4.7 (#8275) | ||
|
Thomas Eizinger
|
4de0fb7640 |
chore(connlib): improve wire::dev logging (#8272)
This will log more details about the packet, such as SYN, RST and FIN flags for TCP. |
||
|
Thomas Eizinger
|
2fe5c00c64 |
fix(windows): break from retry loop if we sent the packet (#8271)
Regression introduced in #8268. |
||
|
Thomas Eizinger
|
71431e8c9c |
fix(gui-client): update Linux-desktop entry to Firezone Client (#8270)
This effectively reverts #8223 due to how this interacts with the generated packages on Linux. The _package_ itself should still be called `firezone-client-gui` because that is what we are installing. Perhaps we will one day add a headless-client package so the naming chosen here should allow for that. To customize the desktop entry, we instead make use of the `desktopTemplate` configuration of the Tauri bundler where we can provide a custom `.desktop` file where we can specify a particular application name. As part of this, we are also updating the docs on the website to mention the new name `Firezone Client`. |
||
|
dependabot[bot]
|
662b958a0b |
build(deps): bump uuid from 1.11.0 to 1.14.0 in /rust (#8243)
Bumps [uuid](https://github.com/uuid-rs/uuid) from 1.11.0 to 1.14.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/uuid-rs/uuid/releases">uuid's releases</a>.</em></p> <blockquote> <h2>v1.14.0</h2> <h2>What's Changed</h2> <ul> <li>Add FromStr impls to the fmt structs by <a href="https://github.com/tysen"><code>@tysen</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/806">uuid-rs/uuid#806</a></li> <li>Prepare for 1.14.0 release by <a href="https://github.com/KodrAus"><code>@KodrAus</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/807">uuid-rs/uuid#807</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/tysen"><code>@tysen</code></a> made their first contribution in <a href="https://redirect.github.com/uuid-rs/uuid/pull/806">uuid-rs/uuid#806</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/uuid-rs/uuid/compare/v1.13.2...v1.14.0">https://github.com/uuid-rs/uuid/compare/v1.13.2...v1.14.0</a></p> <h2>v1.13.2</h2> <h2>What's Changed</h2> <ul> <li>Add a compile_error when no source of randomness is available on wasm32-unknown-unknown by <a href="https://github.com/KodrAus"><code>@KodrAus</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/804">uuid-rs/uuid#804</a></li> <li>Prepare for 1.13.2 release by <a href="https://github.com/KodrAus"><code>@KodrAus</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/805">uuid-rs/uuid#805</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/uuid-rs/uuid/compare/1.13.1...v1.13.2">https://github.com/uuid-rs/uuid/compare/1.13.1...v1.13.2</a></p> <h2>1.13.1</h2> <h2>What's Changed</h2> <ul> <li>Fix <code>wasm32</code> with <code>atomics</code> by <a href="https://github.com/bushrat011899"><code>@bushrat011899</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/797">uuid-rs/uuid#797</a></li> <li>Prepare for 1.13.1 release by <a href="https://github.com/KodrAus"><code>@KodrAus</code></a> in <a href="https://redirect.github.com/uuid-rs/uuid/pull/799">uuid-rs/uuid#799</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/bushrat011899"><code>@bushrat011899</code></a> made their first contribution in <a href="https://redirect.github.com/uuid-rs/uuid/pull/797">uuid-rs/uuid#797</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/uuid-rs/uuid/compare/1.13.0...1.13.1">https://github.com/uuid-rs/uuid/compare/1.13.0...1.13.1</a></p> <h2>1.13.0</h2> <h2>⚠️ Potential Breakage</h2> <p>This release updates our version of <code>getrandom</code> to <code>0.3</code> and <code>rand</code> to <code>0.9</code>. It is a <strong>potentially breaking change</strong> for the following users:</p> <h3>no-std users who enable the <code>rng</code> feature</h3> <p><code>uuid</code> still uses <code>getrandom</code> by default on these platforms. Upgrade your version of <code>getrandom</code> and <a href="https://docs.rs/getrandom/0.3.1/getrandom/index.html#custom-backend">follow its new docs</a> on configuring a custom backend.</p> <h3><code>wasm32-unknown-unknown</code> users who enable the <code>rng</code> feature without the <code>js</code> feature</h3> <p>Upgrade your version of <code>getrandom</code> and <a href="https://docs.rs/getrandom/0.3.1/getrandom/index.html#custom-backend">follow its new docs</a> on configuring a backend.</p> <p>You'll also need to enable the <code>rng-getrandom</code> or <code>rng-rand</code> feature of <code>uuid</code> to force it to use <code>getrandom</code> as its backend:</p> <pre lang="diff"><code>[dependencies.uuid] version = "1.13.0" - features = ["v4"] + features = ["v4", "rng-getrandom"] <p>[dependencies.getrandom] </tr></table> </code></pre></p> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
96170be082 |
fix(gui-client): mitigate deadlock when shutting down TUN device (#8268)
In #8159, we introduced a regression that could lead to a deadlock when shutting down the TUN device. Whilst we did close the channel prior to awaiting the thread to exit, we failed to notice that _another_ instance of the sender could be alive as part of an internally stored "sending permit" with the `PollSender` in case another packet is queued for sending. We need to explicitly call `abort_send` to free that. Judging from the comment and a prior bug, this shutdown logic has been buggy before. To further avoid this deadlock, we introduce two changes: - The worker threads only receive a `Weak` reference to the `wintun::Session` - We move all device-related state into a dedicated `TunState` struct that we can drop prior to joining the threads The combination of these features means that all strong references to channels and the session are definitely dropped without having to wait for anything. To provide a clean and synchronous shutdown, we wait for at most 5s on the worker-threads. If they don't exit until then, we log a warning and exit anyway. This should greatly reduce the risk of future bugs here because the session (and thus the WinTUN device) gets shutdown in any case and so at worst, we have a few zombie threads around. Resolves: #8265 |
||
|
Jamil
|
48030f68d7 |
ci: Bump Apple clients to 1.4.5 (#8252)
These have been published. This fixes a critical bug preventing the client from launching on macOS. |
||
|
Jamil
|
0bc3895c3e |
ci: Bump Apple clients to 1.4.4 (#8245)
These have been released / published. Need to merge this to get website links and changelog updated. |
||
|
Thomas Eizinger
|
a0f079f1cd |
feat(gui-client): send Linux GUI logs to journald (#8236)
This configures the GUI client to log to journald in addition to files as well. For better or worse, this logs all events such that structured information is preserved, e.g. all additional fields next to the message are also saved as fields in the journal. By default, when viewing the logs via `journalctl`, those fields are not displayed. This makes the default output of `journalctl` for the FIrezone GUI not as useful as it could be. Fixing that is left to a later stage. Related: #8173 |
||
|
Thomas Eizinger
|
4cb2b01c26 |
build(nix): manage Rust installation via rustup (#8235)
Using `rustup` - even on NixOS - is easier to manage the Rust toolchain as some tools rely on being able to use the `rustup` shims such as `+nightly` to run a nightly toolchain. |
||
|
Thomas Eizinger
|
57ce0ee469 |
feat(gateway): cache DNS queries for resources (#8225)
With the addition of the Firezone Control Protocol, we are now issuing a lot more DNS queries on the Gateway. Specifically, every DNS query for a DNS resource name always triggers a DNS query on the Gateway. This ensures that changes to DNS entries for resources are picked up without having to build any sort of "stale detection" in the Gateway itself. As a result though, a Gateway has to issue a lot of DNS queries to upstream resolvers which in 99% or more cases will return the same result. To reduce the load on these upstream, we cache successful results of DNS queries for 5 minutes. --------- Signed-off-by: Thomas Eizinger <thomas@eizinger.io> |
||
|
Thomas Eizinger
|
f882edb3bd |
feat(gui-client): configure IPC service to log to stdout (#8219)
On Linux, logs sent to stdout from a systemd-service are automatically captured by `journald`. This is where most admins expect logs to be and frankly, doing any kind of debugging of Firezone is much easier if you can do `journalctl -efu firezone-client-ipc.service` in a terminal and check what the IPC service is doing. On Windows, stdout from a service is (unfortunately) ignored. To achieve this and also allow dynamically changing the log-filter, I had to introduce a (long-overdue) abstraction over tracing's "reload" layer that allows us to combine multiple reload-handles into one. Unfortunately, neither the `reload::Layer` nor the `reload::Handle` implement `Clone`, which makes this unnecessarily difficult. Related: #8173 |
||
|
Thomas Eizinger
|
ea9796e346 |
feat(gateway): apply filter engine to inbound packets (#7702)
The Gateway keeps some state for each client connection. Part of this state are filters which can be controlled via the Firezone portal. Even if no filters are set in the portal, the Gateway uses this data structure to ensure only packets to allowed resources are forwarded. If a resource is not allowed, its IP won't exist in the `IpNetworkTable` of filters and thus won't be allowed. When a Client disconnects, the Gateway cleans up this data structure and thus all filters etc are gone. As soon as a Client reconnects, default filters are installed (which don't allow anything) under the same IP (the portal always assigns the same IP to Clients). These filters are only applied on _outbound_ traffic (i.e. from the Client towards Resources). As a result, packets arriving from Resources to a Client will still be routed back, causing "Source not allowed" errors on the client (which has lost all of its state when restarting). To fix this, we apply the Gateway's filters also on the reverse path of packets from Resources to Clients. Resolves: #5568 Resolves: #7521 Resolves: #6091 |
||
|
Thomas Eizinger
|
f22a285678 |
feat(phoenix-channel): don't try to detect missing heartbeats (#8220)
At present our Rust implementation of the Phoenix Channel client tries to detect missing heartbeat responses from the portal. This is unnecessary and causes brittleness in production. The WebSocket connection runs over TCP, meaning any kind of actual network problem / partition will be detected by TCP itself and cause an IO error further up the stack. In order to keep NAT bindings alive, we only need to send _some_ traffic every so often, meaning sending a heartbeat is good enough. We don't need to actually handle the response in any particular way. Lastly, by just using an interval, I realised that we can very easily implement an optimisation from the Phoenix spec: Only send heartbeats if you haven't sent anything else. In theory, WebSocket ping/pong frames could be used for this keep-alive mechanism. Unfortunately, as I understand the Phoenix spec, it requires its own heartbeat to be sent, otherwise it will disconnect the WebSocket. |
||
|
Thomas Eizinger
|
9bc23732f3 |
chore(apple): downgrade warning about installed crypto provider (#8226)
With the introduction of system extensions, the memory is no longer free'd after the tunnel disconnects meaning this can easily happen. |
||
|
Thomas Eizinger
|
273d723729 |
fix(gui-client): use "Firezone" as the application name on Linux (#8223)
The current `.desktop` file uses the `firezone-client-gui` name from the Tauri config. This looks ugly and unprofessional. Instead, we should just call this "Firezone".  Resolves: #8205 |
||
|
Thomas Eizinger
|
deb47d956e |
chore(gateway): remove log around "No NAT session" (#8227)
This is pretty confusing when reading logs. For inbound packets, we assume that if we don't have a NAT session, they belong to the Internet Resource or a CIDR resource, meaning this log shows up for all packets for those resources and even for packets that don't belong to any resource at all. |
||
|
Thomas Eizinger
|
b10b6e75ea |
fix(gui-client): hide the .desktop entry for deep-links (#8224)
On Linux desktops, we install a dedicated `.desktop` file that is responsible for handling our deep-links for sign-in. This desktop entry is not meant to be launched manually and therefore should be hidden from the application menus. |
||
|
Thomas Eizinger
|
6f68b97558 |
chore(gui-client): release v1.4.6 (#8211)
|
||
|
Thomas Eizinger
|
d5fdb5fda8 |
test(connlib): remove assertion around idle packets / sec (#8210)
This has been flaky recently but it isn't a priority right now. |
||
|
Thomas Eizinger
|
81da120c17 |
fix(phoenix-channel): report connection hiccups to upper layer (#8203)
The WebSocket connection to the portal from within the Clients, Gateways and Relays may be temporarily interrupted by IO errors. In such cases we simply reconnect to it. This isn't as much of a problem for Clients and Gateways. For Relays however, a disconnect can be disruptive for customers because the portal will send `relays_presence` events to all Clients and Gateways. Any relayed connection will therefore be interrupted. See #8177. Relays run on our own infrastructure and we want to be notified if their connection flaps. In order to differentiate between these scenarios, we remove the logging from within `phoenix-channel` and report these connection hiccups one layer up. This allows Clients and Gateways to log them on DEBUG whereas the Relay can log them on WARN. Related: #8177 Related: #7004 |
||
|
Thomas Eizinger
|
cad84922db |
fix(apple): don't panic in FFI functions (#8202)
Now that we have error reporting via Sentry in Swift-land as well, we can handle errors in the FFI layer more gracefully and return them to Swift. --------- Signed-off-by: Jamil <jamilbk@users.noreply.github.com> Co-authored-by: Jamil <jamilbk@users.noreply.github.com> |
||
|
Thomas Eizinger
|
3e4976e4ab |
fix(relay): don't starve items further down in the event-loop (#8177)
At present, the relay uses a priority in the event-loop that favors routing traffic. Whenever a task further up in the loop is `Poll::Ready`, we loop back to the top to continue processing. The issue with that is that in very busy times, this can lead to starvation in processing timers and messages from the portal. If we then finally get to process portal messages, we think that the portal hasn't replied in some time and proactively cut the connection and reconnect. As a result, the portal will send `relays_presence` messages to the clients and gateways which in turn will locally remove the relay. This breaks relayed connections. To fix this, instead of immediately traversing to the top of the event-loop with `continue`, we only set a boolean. This gives each element of the event-loop a chance to execute, even when a certain component is very busy. Related: #8165 Related: #8176 |
||
|
Thomas Eizinger
|
2e43523f75 |
fix(snownet): servers should not initiate WireGuard sessions (#8169)
Whilst ICE for a connection is in progress, it might happen that packets
for a particular client are arriving at the Gateway's TUN device. I
assume that these might be from a previous session?
We can only negotiate a WireGuard session once we have a nominated
socket. Thus, the very first packet sent on a session will always
trigger a new handshake. We don't want Gateway's to start handshakes
though, those should always be initiated by the Clients.
To avoid this, we add a conditional to `snownet::Node` that drops
packets iff the current node is a `ServerNode` and we haven't nominated
a socket yet.
The following log output from a Gateway motivated this change:
```
2025-02-17T15:36:45.372Z INFO snownet::node: Connection failed (ICE timeout) cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
// Here the previous connection failed.
2025-02-17T15:36:45.989Z DEBUG firezone_tunnel::gateway: Unknown client, perhaps already disconnected? dst=100.64.69.110
2025-02-17T15:36:45.989Z DEBUG firezone_tunnel::gateway: Unknown client, perhaps already disconnected? dst=100.64.69.110
2025-02-17T15:36:45.989Z DEBUG firezone_tunnel::gateway: Unknown client, perhaps already disconnected? dst=100.64.69.110
2025-02-17T15:36:46.213Z DEBUG firezone_tunnel::gateway: Unknown client, perhaps already disconnected? dst=100.64.69.110
// Until here, packets for this client got dropped but now a new connection (for the same IP!) is being created.
2025-02-17T15:36:46.474Z DEBUG snownet::node: Sampled relay rid=b7198983-0cf6-48ba-a459-e7d27ef7d6c9 client_id=8b106344-ba59-4050-8f9a-e2f0bab6e9e5 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.474Z INFO str0m::ice_::agent: Set local credentials: IceCreds { ufrag: "ipcg", pass: "eyy6s27emu2joisw7aqc7q" } client_id=8b106344-ba59-4050-8f9a-e2f0bab6e9e5 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.474Z INFO str0m::ice_::agent: Set remote credentials: IceCreds { ufrag: "up5k", pass: "4q6uvhawhcbnhbqrddvy5x" } client_id=8b106344-ba59-4050-8f9a-e2f0bab6e9e5 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.474Z INFO str0m::ice_::agent: Add local candidate: Candidate(host=10.0.0.4:38621/udp prio=2130706175) client_id=8b106344-ba59-4050-8f9a-e2f0bab6e9e5 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.474Z INFO str0m::ice_::agent: Add local candidate: Candidate(relay=34.16.221.134:62250/udp prio=37748479) client_id=8b106344-ba59-4050-8f9a-e2f0bab6e9e5 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.474Z INFO str0m::ice_::agent: Add local candidate: Candidate(relay=[2600:1900:4180:ee3:0:78::]:62250/udp prio=37748735) client_id=8b106344-ba59-4050-8f9a-e2f0bab6e9e5 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.474Z INFO str0m::ice_::agent: State change (new connection): New -> Checking client_id=8b106344-ba59-4050-8f9a-e2f0bab6e9e5 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.474Z INFO snownet::node: Created new connection client_id=8b106344-ba59-4050-8f9a-e2f0bab6e9e5 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.475Z INFO firezone_tunnel::peer: Allowing access to resource client=8b106344-ba59-4050-8f9a-e2f0bab6e9e5 resource=dca3fcc6-b5e0-470a-bc7b-6446cdd03bb3 expires=Some("2025-02-24T15:09:11+00:00") client_id=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
// The connection has been created and very likely another packet has arrived at the TUN interface. This time though, we have an entry in our connection map for this IP and try to route it.
2025-02-17T15:36:46.546Z DEBUG boringtun::noise: Sending handshake_initiation cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.546Z DEBUG snownet::node: ICE is still in progress, buffering WG handshake num_buffered=1 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
// We buffered the handshake packet. This is only meant to be done by clients.
2025-02-17T15:36:46.572Z INFO str0m::ice_::agent: Created peer reflexive remote candidate from STUN request: Candidate(prflx=107.197.104.68:49376/udp prio=1862270719) cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.572Z DEBUG str0m::ice_::agent: Created new pair for STUN request: CandidatePair(1-0 prio=162128486503284223 state=Waiting attempts=0 unanswered=0 remote=0 last=None nom=None) cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.574Z INFO str0m::ice_::agent: Created peer reflexive remote candidate from STUN request: Candidate(prflx=[2600:1700:3ecb:2410:7499:175a:5c9:9bc5]:57622/udp prio=1862270975) cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.574Z DEBUG str0m::ice_::agent: Created new pair for STUN request: CandidatePair(2-1 prio=162129586014912511 state=Waiting attempts=0 unanswered=0 remote=0 last=None nom=None) cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.611Z DEBUG str0m::ice_::pair: Nominated pair: CandidatePair(2-1 prio=162129586014912511 state=Succeeded attempts=1 unanswered=0 remote=2 last=Some(Instant { tv_sec: 286264, tv_nsec: 840170135 }) nom=Nominated) cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.612Z INFO str0m::ice_::agent: State change (got nomination, still trying others): Checking -> Connected cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.612Z DEBUG snownet::node: Flushing packets buffered during ICE num_buffered=1 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.612Z INFO snownet::node: Updating remote socket old=None new=Relay { relay: b7198983-0cf6-48ba-a459-e7d27ef7d6c9, dest: [2600:1700:3ecb:2410:7499:175a:5c9:9bc5]:57622 } duration_since_intent=137.48517ms cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
// The connection has been established and we receive the (forced) handshake initiation by the client. However, we also flushed a handshake initiation.
2025-02-17T15:36:46.612Z DEBUG boringtun::noise: Received handshake_initiation remote_idx=731337473 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.613Z DEBUG boringtun::noise: Sending handshake_response local_idx=185230594 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.613Z DEBUG boringtun::noise: Sending handshake_initiation cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.629Z DEBUG snownet::node: Unknown connection or socket has already been nominated ignored_candidate=candidate:fffeff021b36b51d6f7abdc3 1 udp 50331391 34.94.63.38 55487 typ relay cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.629Z DEBUG snownet::node: Unknown connection or socket has already been nominated ignored_candidate=candidate:fffeff64a52b02479dab9c4 1 udp 1694498559 107.197.104.68 49376 typ srflx cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.629Z DEBUG snownet::node: Unknown connection or socket has already been nominated ignored_candidate=candidate:fffeff7ec9b7a7db40ec1c44 1 udp 2130706175 192.168.1.150 49376 typ host cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.630Z DEBUG snownet::node: Unknown connection or socket has already been nominated ignored_candidate=candidate:ffffff026d81f5c8a4d5600e 1 udp 50331647 2600:1900:4120:521c:0:78:: 55487 typ relay cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.630Z DEBUG snownet::node: Unknown connection or socket has already been nominated ignored_candidate=candidate:ffffff64e2c91c4ff6f343f5 1 udp 1694498815 2600:1700:3ecb:2410:7499:175a:5c9:9bc5 57622 typ srflx cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.630Z DEBUG snownet::node: Unknown connection or socket has already been nominated ignored_candidate=candidate:ffffff7ed64262b110d1f279 1 udp 2130706431 2600:1700:3ecb:2410:7499:175a:5c9:9bc5 57622 typ host cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
// We are receiving a response for our handshake initiation. Let the fight begin!
2025-02-17T15:36:46.651Z DEBUG boringtun::noise: Received handshake_response local_idx=185230593 remote_idx=731337474 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.651Z DEBUG firezone_gateway::eventloop: Tunnel error: Failed to decapsulate: Failed to decapsulate: UnexpectedPacket
2025-02-17T15:36:46.651Z DEBUG boringtun::noise: Received handshake_initiation remote_idx=731337475 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.652Z DEBUG boringtun::noise: Sending handshake_response local_idx=185230596 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.652Z DEBUG boringtun::noise: Sending handshake_initiation cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.652Z DEBUG boringtun::noise: Received handshake_response local_idx=185230595 remote_idx=731337476 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.652Z DEBUG firezone_gateway::eventloop: Tunnel error: Failed to decapsulate: Failed to decapsulate: UnexpectedPacket
2025-02-17T15:36:46.652Z DEBUG boringtun::noise: Received handshake_initiation remote_idx=731337477 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.653Z DEBUG boringtun::noise: Sending handshake_response local_idx=185230598 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.653Z DEBUG boringtun::noise: Sending handshake_initiation cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.691Z DEBUG boringtun::noise: Received handshake_response local_idx=185230597 remote_idx=731337478 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.691Z DEBUG firezone_gateway::eventloop: Tunnel error: Failed to decapsulate: Failed to decapsulate: UnexpectedPacket
2025-02-17T15:36:46.691Z DEBUG boringtun::noise: Received handshake_initiation remote_idx=731337479 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.692Z DEBUG boringtun::noise: Sending handshake_response local_idx=185230600 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
2025-02-17T15:36:46.692Z INFO snownet::node: Completed wireguard handshake cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5 duration_since_intent=217.247362ms
2025-02-17T15:36:46.692Z DEBUG firezone_gateway::eventloop: Tunnel error: Failed to decapsulate: Failed to decapsulate: NoCurrentSession
2025-02-17T15:36:46.692Z DEBUG firezone_gateway::eventloop: Tunnel error: Failed to decapsulate: Failed to decapsulate: NoCurrentSession
2025-02-17T15:36:46.692Z DEBUG firezone_gateway::eventloop: Tunnel error: Failed to decapsulate: Failed to decapsulate: NoCurrentSession
2025-02-17T15:36:46.692Z DEBUG firezone_gateway::eventloop: Tunnel error: Failed to decapsulate: Failed to decapsulate: NoCurrentSession
2025-02-17T15:36:46.708Z DEBUG firezone_gateway::eventloop: Tunnel error: Failed to decapsulate: Failed to decapsulate: NoCurrentSession
2025-02-17T15:36:46.731Z DEBUG boringtun::noise: New session session=185230600 cid=8b106344-ba59-4050-8f9a-e2f0bab6e9e5
```
As you can see, with both parties initiating handshakes, they end up
fighting over who should initiate the session.
|
||
|
Thomas Eizinger
|
2d37cfa264 |
refactor(snownet): make kind of connection more descriptive (#8167)
When `snownet` establishes a connection to another peer, we may end up in one of four different connection types: - `PeerToPeer` - `PeerToRelay` - `RelayToPeer` - `RelayToRelay` From the perspective of the local node, it only matters whether or not we are sending data from our local socket or a relay's socket because in the latter case, we have to encapsulate it in a channel data message. Hence, at present, we often see logs that say "Direct" but really, we are talking to a port allocated by the remote on a relay. We know whether or not the remote candidate is a relay by looking at the candidates they sent us. To make our logs more descriptive, we now model out all 4 possibilities here. |