-
Notifications
You must be signed in to change notification settings - Fork 280
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(headless-client/linux)!: make FIREZONE_DNS_CONTROL
mandatory
#5068
Conversation
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
|
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. |
…zone into refactor/debug-ipc-service
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>
… 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 |
Closes #5063
systemd-resolved
on 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-conf
will break some systems, and defaulting tosystemd-resolved
means 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_CONTROL
is not set toetc-resolv-conf
orsystemd-resolved
Tasks