This repository has been archived by the owner on Jan 22, 2020. It is now read-only.
Switch away from openresolv #20
Merged
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
I was wrong in thinking we should do this. It turns out that support for it has bitrotted in Ubuntu. Fixes: #19
|
We can make a upload to the PPA to include resolvconf package with the patch for wireguard. |
|
No. Please do not do that. Instead, simply merge this commit. |
jlund
pushed a commit
to StreisandEffect/streisand
that referenced
this pull request
May 25, 2017
This patch is untested, and won't really be easily testable until EggieCode/wireguard-ppa#20 is merged and uploaded. However, without testing, several observations struck me: - resolvconf doesn't need real interface names. A bogus name will work just fine. - Prefixing an arbitrary name with 'tun' moves it to the top-ish of the list. - Debian's resolvconf ignores arguments after the first, so we can still continue to supply the openresolv flags for implementations that support it. Thus, we give resolvconf tun.%i, and this should work good enough. There are a few limitations, however: - The DNS server is not _exclusive_, which means that if it doesn't reply in time, the resolver might choose to try other servers. This is a security feature limitation of Debian's resolvconf. Not our problem, perhaps? - This doesn't handle anything with the convoluted --enable-updates/ disable-updates logic, which may or may not be in use, in which case, who knows what to do. - Building on that last point, I'm still uncertain exactly how Ubuntu's use of dnsmasq interacts with --enable-updates/disable-updates and resolvconf in general. So, all and all this might be a bug-fix improvement over before, but still not perfect. Incremental baby steps. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
cpu
pushed a commit
to cpu/streisand
that referenced
this pull request
May 25, 2017
This patch is untested, and won't really be easily testable until EggieCode/wireguard-ppa#20 is merged and uploaded. However, without testing, several observations struck me: - resolvconf doesn't need real interface names. A bogus name will work just fine. - Prefixing an arbitrary name with 'tun' moves it to the top-ish of the list. - Debian's resolvconf ignores arguments after the first, so we can still continue to supply the openresolv flags for implementations that support it. Thus, we give resolvconf tun.%i, and this should work good enough. There are a few limitations, however: - The DNS server is not _exclusive_, which means that if it doesn't reply in time, the resolver might choose to try other servers. This is a security feature limitation of Debian's resolvconf. Not our problem, perhaps? - This doesn't handle anything with the convoluted --enable-updates/ disable-updates logic, which may or may not be in use, in which case, who knows what to do. - Building on that last point, I'm still uncertain exactly how Ubuntu's use of dnsmasq interacts with --enable-updates/disable-updates and resolvconf in general. So, all and all this might be a bug-fix improvement over before, but still not perfect. Incremental baby steps. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
jlund
pushed a commit
to StreisandEffect/streisand
that referenced
this pull request
May 27, 2017
* Adds end-to-end Wireguard client test. This commit updates the Vagrant test environment to provision the streisand-client machine as a Wireguard client. The connection to the streisand-server is tested, along with the changes to the client DNS. * Correct "WireGuard" capitalization. * Trims whitespace for resolv test * resolvconf: support Debian's broken resolvconf This patch is untested, and won't really be easily testable until EggieCode/wireguard-ppa#20 is merged and uploaded. However, without testing, several observations struck me: - resolvconf doesn't need real interface names. A bogus name will work just fine. - Prefixing an arbitrary name with 'tun' moves it to the top-ish of the list. - Debian's resolvconf ignores arguments after the first, so we can still continue to supply the openresolv flags for implementations that support it. Thus, we give resolvconf tun.%i, and this should work good enough. There are a few limitations, however: - The DNS server is not _exclusive_, which means that if it doesn't reply in time, the resolver might choose to try other servers. This is a security feature limitation of Debian's resolvconf. Not our problem, perhaps? - This doesn't handle anything with the convoluted --enable-updates/ disable-updates logic, which may or may not be in use, in which case, who knows what to do. - Building on that last point, I'm still uncertain exactly how Ubuntu's use of dnsmasq interacts with --enable-updates/disable-updates and resolvconf in general. So, all and all this might be a bug-fix improvement over before, but still not perfect. Incremental baby steps. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> * Review feedback * Fixes wireguard resolv.conf expected value
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
I was wrong in thinking we should do this. It turns out that support for it has bitrotted in Ubuntu.
After merging this, there should probably be a revbump and propagation to the version branches.
@cryptofuture