slingamn / namespaced-openvpn

Wrapper for OpenVPN on Linux solving various privacy issues

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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:

  1. The results of cat /etc/resolv.conf in the root namespace
  2. The results of dig @8.8.8.8 google.com in the root namespace (i.e. passing the desired resolver explicitly to dig)?

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.