Closed markubiak closed 7 years ago
@markubiak in case you are interested, this is how I solve the issue (with NetworkManager):
#!/bin/bash
#/etc/NetworkManager/dispatcher.d/pia-vpn
interface="$1"
status=$2
case $status in
vpn-up)
if [[ $interface == "tun0" ]]; then
chattr -i /etc/resolv.conf
echo -e "nameserver 209.222.18.222\nnameserver 209.222.18.218" > /etc/resolv.conf
chattr +i /etc/resolv.conf
fi
;;
vpn-down)
if [[ $interface == "tun0" ]]; then
chattr -i /etc/resolv.conf
fi
;;
esac
In other words, as long as VPN is connected, the /etc/resolv.conf
contains only PIA DNS servers and is made readonly to naively protect the file from being overwritten. A bit hacky, but works well.
Huh, that chmod stuff is some bash black magic. I'm gonna go do research on why that works. It completely fixed DNS leaks for me though. Thank you! I'm leaving this issue open as it really should be mitigated.
I will have to look more into this.
@markubiak considering most scripts/changes would probably not change the attrib on the file from RO, it stands to reason that setting it to RO would mitigate some other application changing the DNS settings.
I wonder if it has something to do how https://github.com/masterkorp/openvpn-update-resolv-conf works. I'll have to look at this when I get back to my Linux box.
Running openvpn
directly doesn't appear to leak DNS. I have been using Connman though I have some issue with it not setting up the VPN properly.
Connecting through the Japan end point. The DNS leak test shows fine:
OpenVPN Config
client
dev tun
proto udp
remote japan.privateinternetaccess.com 1197
resolv-retry infinite
nobind
persist-key
persist-tun
cipher aes-256-cbc
auth sha256
tls-client
remote-cert-tls server
auth-user-pass /etc/private-internet-access/login.conf
comp-lzo
verb 1
reneg-sec 0
crl-verify /etc/openvpn/crl.rsa.4096.pem
ca /etc/openvpn/ca.rsa.4096.crt
disable-occ
auth-nocache
script-security 2
up /etc/openvpn/update-resolv-conf.sh
down /etc/openvpn/update-resolv-conf.sh
Conman Config
[global]
Name = Japan
Description = OpenVPN configuration
[provider_openvpn]
Type = OpenVPN
Name = Japan_VPN
Host = japan.privateinternetaccess.com
Domain = privateinternetaccess.com
OpenVPN.Port = 1197
OpenVPN.CACert = /etc/openvpn/ca.rsa.4096.crt
OpenVPN.CompLZO = yes
OpenVPN.RemoteCertTls = server
OpenVPN.AuthNoCache = 0
OpenVPN.ConfigFile = /etc/openvpn/Japan.conf
OpenVPN.Cipher = aes-256-cbc
OpenVPN.Auth = sha256
I can actually confirm that DNS is not leaking anymore, neither on "normal" nor on "strong" configurations (tested with NM). The hack I posted earlier is not required anymore.
I imagine the issue was somewhere else (perhaps in PIA's configs or in update-resolv-conf), and now it got fixed.
@maximbaz okay, then I'll close this. =D
I have just been able to observe the leak. Interestingly enough, when I re-run the same test, the leak is gone!
I think this is what happens. Without any extra hacks, the /etc/resolv.conf
looks like this:
# Generated by resolvconf
nameserver 209.222.18.222
nameserver 209.222.18.218
nameserver 192.168.1.1
Which means, whenever possible PIA's DNS take priority. But if for some reason those servers are unable to resolve an address, my provider's DNS kicks in and therefore leaks the location.
It's not reproducing 100% of the time, and I'm not exactly sure why. But in my mind inconsistent DNS leak is even worse than permanent leak, because you never know when it happened.
I'm returning back to using the hack that I posted earlier.
These are the websites which were able to detect the leak when the site was loaded for the first time: http://dnsleak.com/ https://whoer.net/
well shoot... I will look at it.
I'm not sure though that the changes needs to be done in this project.
We need to investigate why the line nameserver 192.168.1.1
appears in the /etc/resolv.conf
. Who is putting it there and why? Is it because of PIA's config? Is it because of the update-resolv-conf.sh
?
exactly... I will look in a bit
@maximbaz what doe /etc/resolv.conf
show before you activate the VPN? Are you using systemd?
Mine:
# Generated by Connection Manager
nameserver 127.0.0.1
nameserver ::1⏎
This is the contents of the /etc/resolv.conf
immediately after the system boot:
# Generated by resolvconf
nameserver 192.168.1.1
I don't know exactly what is the process behind generating it. I think I use systemd (I manage services using systemctl tool, which is the part of systemd, right?).
I use router, and 192.168.1.1 is the address of the router.
yes, it's managed by systemclt.
Can you do a systemctl list-units | grep enabled
? Post the results.
No matches.
Maybe let's switch to a chat, @flamusdiu? Let's try this one for example: https://niltalk.com/r/qwilX Password: 12345
that's odd ... it's always best to catch me on G+/HO -> https://bit.ly/AzuleOnyx
@maximbaz Is this still happening? I haven't noticed it on my end, yet. =(
Yep, still happens. Try this website again, it constantly shows the leak for me: https://whoer.net/
Yeah, I dislike that page. I feel it's pushing FUD.
1) It's shows "safe" or "None" as green. This honestly would cause people to think they are "fine" without VPNs.
2) I get 40% even after I disabled Flash. How the hell do I get the same score? Oh wait, they are using some "formula" which I have really no access to which changes the values.
3) Who the heck would change system times to match their VPN end point?
4) Apparently, a mid range hit for "knowing" you are using a VPN. Seriously? For most people this is even an issue.
5) No documentation on what their recommended fix for some of them. My biggest hit? IP Address is different. Probably something do with the VPN configuration. If you are providing this service, shouldn't you research and give information on how to fix the flaws you are talking about?
DNS appears to be fine for me here.
Agree on all points, the website is obscure, however it does show me a leak, and that's why I suggested it :)
As soon as I disable my "fix" mentioned above, in this column I begin to see my own country:
When the "fix" is enabled, as you can see, the DNS IP address matches my own IP address.
~> cat /etc/resolv.conf
# Generated by Connection Manager
nameserver 127.0.0.1
nameserver ::1
Here's mine. very odd.
FYI, I cannot set nameservers to localhost as you have in your /etc/resolv.conf
. If I do that, nothing gets resolved. I have to set some remote IP address, let it be PIA or something else.
Is it possible that you have some kind of a DNS resolver service running locally? Or how does that work in your case?
But I don't know, maybe the problem is with NetworkManager ¯\_(ツ)_/¯
I'm perfectly fine using the workaround, so it's up to you @flamusdiu, if you want, close the issue as "Won't fix", or make the workaround be installed as a part of python-pia
, or we keep investigating further.
Maybe it has to do with the diff between ConnMan and NM?
I don't know; I may play with it some more. I might have to do a clean install just with NM (maybe using Gnome DE or something) and see if it happens. ¯_(ツ)_/¯
@maximbaz are you running systemd-resolved?
Looks like it keeps using 8.8.8.8 and not my local DNS server. grr.
Also, see this -> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1449001
are you running systemd-resolved?
Apparently I do not, so that's how your localhost entries do resolve hosts for you. Good to know!
I think there's something (NetworkManager itself?) that adds extra records to /etc/resolv.conf
and that causes the leak. If we know a way to ensure that no extra entries are added, that would be the fix. Until then, a workaround is doing this for us.
Also good point is that systemd-resolved also falls back to 8.8.8.8, it's not cool, though I think not as vulnerable as using DNS of your own internet provider, which when is known basically tells your location pretty accurately.
Yes, just it's not using my local DNS for some dam reason. I just noticed this. Though, i don't mind them using it; It for the love of something holy, shouldn't be forcing configuring. I expect it to fail -- this isn't windows or ubuntu -- when things are not configured right. Not some blind work around.
NM automatically changes /etc/resolv.conf
if you don't tell it not to do that. Though, seems, NM without systemd-resolv (or maybe even with it) using dispatch scripts to mod the DNS entries.
FYI: this bug is also tracked in https://github.com/masterkorp/openvpn-update-resolv-conf/issues/14, however it is also closed there with a conclusion that it is probably NetworkManager that is doing all the trouble.
Using the default configuration, openvpn may use DNS servers that are not protected by the VPN, causing these DNS providers to possibly snoop on which sites you're browsing. Openvpn can mitigate this by adding the line "block-outside-dns" to the end of every file in /etc/openvpn/*.conf. This fixes the DNS leak and ensures nobody can snoop on you. You can test the leak and the fix using http://dnsleaktest.com
EDIT: This fix does not seem to work. I'm exploring other options. Will update.