search

jamesmcm / vopono

Run applications through VPN tunnels with temporary network namespaces
GNU General Public License v3.0
816 stars 45 forks source link

DNS leaks can't be solved. #89

Open Ergus opened 3 years ago

Ergus commented 3 years ago

Hi:

I am using vopono to connect to protonvpn and I have tried everything but https://www.dnsleaktest.com/ shows my isp in spite of protonvpn has protection to prevent that. So it seems like vopono is not setting the dns in the namespace.

--dns option does not change the dns

and adding block-outside-dns to the .ovpn hangs when trying to connect.

When I use openvpn normally without vopono there is not any leak.

jamesmcm commented 3 years ago

Can you check the content of /etc/netns/NAMESPACENAME/resolv.conf when running?

I remember having issues with the ProtonVPN DNS when writing the sync code - https://github.com/jamesmcm/vopono/blob/master/src/providers/protonvpn/openvpn.rs#L39

Ergus commented 3 years ago

Hi:

The file content seems to be fine at least the values seems to be set, but I am not sure if they are fine...

With vopono I get:

image

But when using network Manager I get:

image

In this case I use the same server (Config nl-free-09.protonvpn.com.tcp.ovpn) but I get very different inets and subnets... Is this intended??

jamesmcm commented 3 years ago

That inet stuff is fine, and it seems alright using the internal DNS server (i.e. that will only be accessible within the tunnel).

Just to check if you run bash within the namespace and then run dig google.com for example - what DNS servers does it use?

Ergus commented 3 years ago

Interesting, bash seems to show the right dns server with dig... But dnsleaktest.com from firefox (from the namespace of course) still shows the one from my ISP. It is using the vpn because the ip is one from proton, not my public one but the Standard test shows the same than without the namespace.

OTOH I still tried to add block-outside-dns to the config and vopono hangs during startup.... So we are missing something here :(.

The hang happens in the call to start ip netns exec vopono_proton_japan openvpn --config /home/user/.config/vopono/proton/openvpn/japan-jp-free.ovpn --machine-readable-output --log /etc/netns/vopono_proton_japan/openvpn.log --auth-user-pass /home/user/.config/vopono/proton/openvpn/auth.txt

It uses the 100 of the cpu and I can't stop ip with C-c ... So I have to close the terminal. In that case the interface is not deleted and I have to remove it manually.

jamesmcm commented 3 years ago

Apparently block-outside-dns should only affect Windows clients anyway. It might be blocking on missing credentials?

In any case, can you try with Chromium or another browser? In case it's due to Firefox doing DNS over HTTPS or some other setting?

Ergus commented 3 years ago

Apparently block-outside-dns should only affect Windows clients anyway. It might be blocking on missing credentials?

But in any case it shouldn't block vopono right?

In any case, can you try with Chromium or another browser?

I just tried Chromium and midori with exactly the same result: right ip wrong dns in the test.

In case it's due to Firefox doing DNS over HTTPS or some other setting?

I actually disabled DNS over HTTPS on firefox; same result. And also tried with private windows (just in case)

jamesmcm commented 3 years ago

I just tested this with the Japan free OpenVPN server and it worked fine for me with google-chrome-stable:

Japanese DNS

Ergus commented 3 years ago

I just tested this with the Japan free OpenVPN server and it worked fine for me with google-chrome-stable:

Hi is this from proton? or someone else?

If it is a proton one. Did you do anything special? Because I can't solve this. I have the same issue with any browser I use except lyx and elinks. So maybe there is something wrong in my environment?? Something that should be documented maybe?

jamesmcm commented 3 years ago

Yeah, I just used vopono sync, chose the free one and logged in. Then ran google-chrome-stable with vopono.

Maybe try to check if anything is overriding the DNS somehow?

Ergus commented 3 years ago

Yeah, I just used vopono sync, chose the free one and logged in. Then ran google-chrome-stable with vopono.

Maybe try to check if anything is overriding the DNS somehow?

I just tried with google-chrome-stable and I have the same result. I am starting to think that maybe this is related with networkmanager?

Are you using networkmanager??

Ergus commented 3 years ago

I found another hint. I rebooted the system to an old debian installation and there vopono seems to work very fine and there are not dns leaks....

The debian installation uses the same environment I have (i3wm+networkmanager and even the same .bashrc and all home files .) so maybe this has nothing to do with network manager. The only difference is the os (Debian vs Arch). So probably there is something in arch that makes the gui applications to bypass the terminal environment during dns search for requests...

jamesmcm commented 3 years ago

It's strange, I use NetworkManager myself, and have openresolv installed but it's not an issue at all.

I don't see anything weird on the Wiki page either - https://wiki.archlinux.org/title/Domain_name_resolution

Ergus commented 3 years ago

I had systemd-resolvconf but I just switched to openresolv, restarted and the issue is still there... I ran out of ideas

Ergus commented 3 years ago

BTW In firefox I tried about:networking#dns but there is not info about how firefox searches for a DNS either

ghost commented 3 years ago

I'm experiencing the same issue with mullvad.

However only with Firefox. No issue when I use dig to check which DNS server I'm using.

fosspill commented 2 years ago

I'm having this issue as well. Both with ungoogled-chromium and firefox. If I use the config files and connect with wg myself it works fine, however.

niki-on-github commented 2 years ago

Maybe it has something to do with the nsswitch.conf setting. See dns-leaks-with-network-namespaces. Since vopono does not generate a custom nsswitch.conf config the default file will be used. Depending on the configuration of the distributions this could maybe cause such problems.

jamesmcm commented 2 years ago

Thanks, I can try to test it by switching to systemd-resolved.

jamesmcm commented 2 years ago

If you're using systemd-resolved, it'd be great if you could try vopono 0.9.0 now thanks to PR #144 from @niki-on-github

masaeedu commented 10 months ago

For posterity (in case this debugging information ever gets turned into a FAQ) the issue in my case turned out to be a running instance of nscd, as suggested in the excellent Stack Exchange answer here:

nscd

If you are not using systemd-resolved, there is one other way in which glibc may apparently ignore your /etc/resolv.conf and /etc/nsswitch.conf setup. This is when nscd is running. glibc will try to reach nscd at /var/run/nscd/socket before it starts loading NSS modules. In NixOS, this is used to avoid needing to pollute the global state configuration of NSS modules into the direct runtime environment of every process; it relies on nscd loading all of the NSS modules and other processes resolving via nscd. In some other systems, nscd may be used to provide caching of resolution.

There are several workarounds:

  1. You can unshare the filesystem namespace and bind mount something, e.g. /var/empty, over /var/run/nscd. This will disable nscd for just one process. Note that this has to be done separately from the netns configuration; it will not persist merely by calling ip netns exec.

  2. You can use firejail to leverage the power of seccomp-bpf to disallow access to /var/run/nscd/socket. This might look something like this:

    firejail --noprofile --blacklist=/var/run/nscd/socket --netns=${NAMESPACE} --dns=${NAMESERVER} [command]

  3. In many cases, you can just disable nscd globally, as it is not generally needed. This is not generally recommended on NixOS, but is reasonable on most Linux based operating systems.

For my purposes I just turned off nscd, and I suspect (but have not confirmed) that these days this workaround is acceptable even for people using NixOS (see edit below). If not, it might be necessary to do the unshare FS namespace + replace /var/run/nscd gymnastics proposed in solution 1.

EDIT: It turns out I was wrong, nscd is still essential for for Nix-based tools to be able to resolve mDNS queries. See output below:

~ via 🐍 v3.10.12
❯ sudo systemctl stop nscd

~ via 🐍 v3.10.12
❯ # try resolving with normal getent

~ via 🐍 v3.10.12
❯ getent hosts xyz.local
192.168.1.105   xyz.local

~ via 🐍 v3.10.12
❯ # try resolving with nixpkgs getent

~ via 🐍 v3.10.12
❯ , getent hosts xyz.local
Warning: Nix-index database is older than 30 days, either obtain a prebuilt database from https://github.com/Mic92/nix-index-database or try updating with `nix run 'nixpkgs#nix-index' --extra-experimental-features 'nix-command flakes'`.

~ via 🐍 v3.10.12 took 2s
❯ echo $?
2

~ via 🐍 v3.10.12
❯ systemctl start nscd

~ via 🐍 v3.10.12 took 8s
❯ , getent hosts xyz.local
Warning: Nix-index database is older than 30 days, either obtain a prebuilt database from https://github.com/Mic92/nix-index-database or try updating with `nix run 'nixpkgs#nix-index' --extra-experimental-features 'nix-command flakes'`.
192.168.1.105   xyz.local

So I guess I need to go back to running nscd (or their new and improved nsncd) on the host system but simultaneously obscure it within the namespace created by vopono.