DNS appears to be broken in root namespace
AmateurECE opened this issue · comments
Hey, there! When I'm using namespaced-openvpn
, it seems like it breaks my DNS configuration outside of the protected namespace. ping 8.8.8.8
works fine, but nslookup google.com
hangs (so does dig and curl when a hostname is specified). All networking inside of the protected
namespace appears to work as I expect, and is correctly routed through my VPN. I'm running Arch Linux, kernel 5.17.5-arch1-1
.
Is this an unfortunate side effect of namespaced-openvpn
, or a bug? Thank you for taking the time to look at this!
This is surprising. Could you check the following:
- The results of
cat /etc/resolv.conf
in the root namespace - The results of
dig @8.8.8.8 google.com
in the root namespace (i.e. passing the desired resolver explicitly todig
)?
Sure thing, thank you for getting back to me!
[~]$ cat /etc/resolv.conf
# Generated by resolvconf
nameserver 10.17.0.1
dig
with an explicit nameserver works though. I suppose I don't know for sure, but I would guess that the 10.17.0.1 nameserver is only reachable from the VPN connection, which is why any DNS query fails in the root namespace, unless another nameserver is specified?
That's interesting. So it seems like the root cause is that resolvconf
is rewriting /etc/resolv.conf
in the root namespace, possibly in response to the new VPN connection, possibly for some other reason. (You can check the file modification time to try and narrow it down. You could also see if resolvconf
is logging anything to the system journal.)
Is 10.17.0.1
the nameserver being pushed from the VPN side? At verb 1
or higher, you should be able to see it on a line like this: PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway def1,route-ipv6 [redacted],dhcp-option DNS 10.0.0.243,route-gateway [redacted],topology subnet,ping 10,ping-restart 60,ifconfig [redacted],peer-id [redacted],cipher AES-128-GCM'
I'm not sure how resolvconf
would be picking up the value, though, since namespaced-openvpn
has no automatic integration with resolvconf
. (Are you passing any additional script options, e.g. --up
, that might try to talk to resolvconf?)
Ah, that looks like it! Looking through my scrollback buffer, I see a message very similar to the one you provided (PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 10.17.0.1,...
).
I'm not passing any additional options on the command line, but I do see these two lines in the OpenVPN config downloaded from my VPN provider:
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
I have to imagine those scripts do exactly that. Comforting at least, that it seems like there are no DNS leaks with my current setup. If I were to remove those two lines from my OpenVPN config, would there be another mechanism in place to prevent DNS leaks?
Ah, yes, you should remove those lines when using namespaced-openvpn --- that will solve your immediate problem.
Unfortunately, with a dynamically maintained /etc/resolv.conf
(as is typical with resolvconf
or NetworkManager
) it is challenging to eliminate all possibility of DNS leaks. This is because if /etc/resolv.conf
is replaced in the root mount namespace, bind mounts in child namespaces will disappear. See discussion here:
https://github.com/slingamn/namespaced-openvpn#dns-hardening
Depending on the environments in which you are using namespaced-openvpn, you may want to create /etc/resolv.conf
as a static file that is not updated (possibly pointing to a "smart" local resolver like dnsmasq
running on 127.0.0.1:53
--- this in itself does not create a leak concern, since every namespace has its own separate loopback adapter). Or you may find that your current setup with resolvconf
is adequate. I personally haven't found a satisfactory solution yet for portable devices / devices using WiFi.