feat(headless-client/linux)!: make FIREZONE_DNS_CONTROL mandatory
#5068
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Closes #5063 Almost all users are likely to have DNS resources, and it will be confusing if we silently don't allow those resources. Defaulting to `etc-resolv-conf` will break some systems, and defaulting to `systemd-resolved` means that it becomes part of the CLI contract. For now, make it explicit
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Terraform Cloud Plan Output |
ReactorScram
changed the title
FIREZONE_DNS_CONTROL mandatoryFIREZONE_DNS_CONTROL mandatory
|
The Gateway also uses code that runs through there, so this is blocked until I can remove that DNS control code from the Gateway's path https://github.com/firezone/firezone/actions/runs/9180192206/job/25244235294#step:10:30 I'm thinking if we did #2986, then the Linux Headless Client can pass the DNS control method to connlib there, other platforms (Windows) will keep their default DNS control, and the Gateway will not do any DNS control. But it's a sorta big change to connlib's API. |
ReactorScram
added a commit
that referenced
this pull request
May 21, 2024
…zone into refactor/debug-ipc-service
ReactorScram
changed the base branch from
main
to
refactor/move-linux-dns-control
ReactorScram
changed the title
FIREZONE_DNS_CONTROL mandatoryFIREZONE_DNS_CONTROL mandatory
… into feat/require-dns-control
Performance Test ResultsTCP
UDP
|
…control Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jun 3, 2024
… and up to the Client (#5111) Refs #3636 (This pays down some of the technical debt from Linux DNS) Refs #4473 (This partially fulfills it) Refs #5068 (This is needed to make `FIREZONE_DNS_CONTROL` mandatory) As of dd6421: - On both Linux and Windows, DNS control and IP setting (i.e. `on_set_interface_config`) both move to the Client - On Windows, route setting stays in `tun_windows.rs`. Route setting in Windows requires us to know the interface index, which we don't know in the Client code. If we could pass opaque platform-specific data between the tunnel and the Client it would be easy. - On Linux, route setting moves to the Client and Gateway, which completely removes the `worker` task in `tun_linux.rs` - Notifying systemd that we're ready moves up to the headless Client / IPC service ```[tasklist] ### Before merging / notes - [x] Does DNS roaming work on Linux on `main`? I don't see where it hooks up. I think I only set up DNS in `Tun::new` (Yes, the `Tun` gets recreated every time we reconfigure the device) - [x] Fix Windows Clients - [x] Fix Gateway - [x] Make sure connlib doesn't get the DNS control method from the env var (will be fixed in #5068) - [x] De-dupe consts - [ ] ~~Add DNS control test~~ (failed) - [ ] Smoke test Linux - [ ] Smoke test Windows ```
|
Out of date, breaks the CLI API, closing Just make |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #5063
systemd-resolvedon LinuxBlocked on failing integration tests, because the Gateway thinks it needs FIREZONE_DNS_CONTROL, which is being yak shaved in #5075
Almost all users are likely to have DNS resources, and it will be confusing if we silently don't allow those resources. Defaulting to
etc-resolv-confwill break some systems, and defaulting tosystemd-resolvedmeans that it becomes part of the CLI contract. For now, make it explicitBREAKING CHANGE: The Headless Client will now bail out on Linux if
FIREZONE_DNS_CONTROLis not set toetc-resolv-conforsystemd-resolvedTasks
FIREZONE_DNS_CONTROLfrom systemd service unit if it's redundant