DNS leakage on Ubuntu 18.10. #59
Comments
|
I guess it is due to |
|
Thanks for the reply @piotr-dobrogost. I'm not sure what the I don't know why This doesn't seem like a problem with |
|
My current configuration is: As you can see, I do not have any |
That's interesting as it's Network Manager which likes to set |
|
I haven't manually configured Thank you for explaining the purpose of the |
|
I have never been a fan of NetworkManager - much like systemd at times, it tries to do too much with a number of questionable decisions under the surface which often result in difficult to detect and resolve failure modes. There is, as in this example, absolutely no reason to demand for Ultimately, and as you suspected, the reason why it works in your case with I'm uncertain how to remove |
|
If have written a Bash-Script to get rid of Save the following code at: #!/bin/bash
# Process only TUN (i.e. VPN) devices!
if [[ $1 == tun* ]]; then
case $2 in
up)
logger -t "check-dns-domain" "TUN up: $1"
# Remove from all but the current TUN interface the default domain search flag '~.'...
for device in $(nmcli -t device | cut -d: -f1 | sort | grep -vx "$1"); do
# Get current domain entries...
domain=$(resolvectl domain "$device" | cut -d: -f2 | sed -e 's/^\s//')
# Check for an '~.' entry (surrounded by spaces or at begin/end of string)...
if echo "$domain" | grep -qE '(^|\s)~\.(\s|$)'; then
# Remove '~.', trim whitespace...
domain=$(echo "$domain" | sed -E -e 's/(^|\s)~\.(\s|$)/ /g' -e 's/^\s+//' -e 's/\s+$//')
logger -t "check-dns-domain" "Setting domain for '$device': '$domain'"
if [ -z "$domain" ]; then
# Domain is now empty...
resolvectl domain "$device" ""
else
# Set new domain value(s). Hint: don't quote last argument, we need individual arguments...
resolvectl domain "$device" $domain
fi
fi
done
;;
down)
logger -t "check-dns-domain" "TUN down: $1"
# Get device name of default route...
device=$(ip route ls | perl -ne 'do {print $1; last} if /^default\s.*\sdev\s(\S+)/')
# Get current domain entries...
domain=$(resolvectl domain "$device" | cut -d: -f2 | sed -e 's/^\s//')
# Append '~.', separated by space. If domain was empty, just set value (without space)...
domain=${domain:+$domain }~.
logger -t "check-dns-domain" "Setting domain for '$device': '$domain'"
# Set new domain value(s). Hint: don't quote last argument, we need individual arguments...
resolvectl domain "$device" $domain
;;
esac
fiTo check the log, you can use |
|
Thanks @bohlstry for sharing the script, works great for me. I tried every possible way to get rid of Using this method seems like the only way to fix DNS leakage... EDIT: The script handles the case of a single VPN well, however I'm normally connected to multiple VPNs, so when I disconnected from just one it pushes back EDIT 2: slightly revised version of @bohlstry's script, works in case there are multiple VPN connections: #!/bin/bash
function remove_default_search_flag() {
# Remove from all but the current TUN interface the default domain search flag '~.'...
for device in $(nmcli -t device | cut -d: -f1 | sort | grep -vx "$1"); do
# Get current domain entries...
domain=$(resolvectl domain "$device" | cut -d: -f2 | sed -e 's/^\s//')
# Check for an '~.' entry (surrounded by spaces or at begin/end of string)...
if echo "$domain" | grep -qE '(^|\s)~\.(\s|$)'; then
# Remove '~.', trim whitespace...
domain=$(echo "$domain" | sed -E -e 's/(^|\s)~\.(\s|$)/ /g' -e 's/^\s+//' -e 's/\s+$//')
logger -t "check-dns-domain" "Setting domain for '$device': '$domain'"
if [ -z "$domain" ]; then
# Domain is now empty...
resolvectl domain "$device" ""
else
# Set new domain value(s). Hint: don't quote last argument, we need individual arguments...
resolvectl domain "$device" $domain
fi
fi
done
}
function add_default_search_flag() {
# Get device name of default route...
device=$(ip route ls | perl -ne 'do {print $1; last} if /^default\s.*\sdev\s(\S+)/')
# Get current domain entries...
domain=$(resolvectl domain "$device" | cut -d: -f2 | sed -e 's/^\s//')
# Append '~.', separated by space. If domain was empty, just set value (without space)...
domain=${domain:+$domain }~.
logger -t "check-dns-domain" "Setting domain for '$device': '$domain'"
# Set new domain value(s). Hint: don't quote last argument, we need individual arguments...
resolvectl domain "$device" $domain
}
# Process only TUN (i.e. VPN) devices!
if [[ $1 == tun* ]]; then
case $2 in
up)
logger -t "check-dns-domain" "TUN up: $1"
remove_default_search_flag "$1"
;;
down)
logger -t "check-dns-domain" "TUN down: $1"
# Check if there are other active TUN devices
active_tuns=$(nmcli connection show --active|grep -q tun && echo 0 || echo 1)
if [ $active_tuns -eq 0 ]; then
logger -t "check-dns-domain" "Other TUN devices are active"
remove_default_search_flag "$1"
else
logger -t "check-dns-domain" "No additional active TUN devices"
add_default_search_flag
fi
;;
esac
fi |
|
Hello, you just need to use the following option in your .network file: The "leakage" that you're getting is because if you don't specify that option, the DNS servers received from the DHCP server will be used and take precedence over any statically configured ones. See https://www.freedesktop.org/software/systemd/man/systemd.network.html#%5BDHCP%5D%20Section%20Options |
|
Thank you both for your scripts. It's still a shame that NetworkManager has not looked into this and doesn't seem to be any closer to resolving this regression. I'm much more a fan of systemd-networkd, despite even its issues at times. Nonetheless, I'll keep this open waiting for a resolution from NetworkManager. In the meantime, I've added into the documentation notes about the issue of leakage when using NetworkManager, and linked to this issue. |
|
I don't understand what have to be network-manager in a script for systemd-resolved... network-manager provides their own DNS resolver implementation, nothing to be with systemd-resolved. |
|
How do I go about removing the |
i.e. link 2 here Run The |
|
Have the NetworkManager bugs been fixed? Another approach is to use nftables rules to block all non-VPN traffic. @jonathanio what do you think of this option? |
|
I have had the same issue with a Fritz!box, because these seem to push DNS settings via DHCP and that is where the I was able to track this further down and found in the Arch-Wiki a way to disable Domains from the Fritz!Box altogether (this may not be what you want, but for me its okay, because I can still use With the following two configuration files I got it working for me :) How to get it workingOn my client I have now two
and then restarted FYI: "how to remove ~. from a specific interface"With the configuration above |
|
Wouldn't removing "~." from my hardware interface, cause DNS resolution to fail (or at least not use those resolvers) if the VPN isn't active? Is there a way to remove the ~. from other interfaces only while the vpn is active? or at least tell systemd-resolved to try the dns resolvers for tun0 before any other interfaces? |
|
It also looks like update-systemd-resolved doesn't call |
|
Users of NetworkManager might be interested in the recent fix regarding this issue – dns: fix handling default routing domains with systemd-resolved (https://github.com/freedesktop/NetworkManager/commit/ee9fab03613e30f818d56217a968d1fabd5ea8d7) |
Any idea how to install newest NM (network manager) on Ubuntu. I'm using 20.04 LTS, but maybe there is a universal way to do it? It would seem that I need to build it from source and somehow seamlessly replace apt-installed system NM with newly built version, but I'm unsure how to do replacing step. |
|
Given #59 (comment), is it time to close this issue? |
tomeon
added
the
Query Routing
|
The NetworkManager fix mentioned above landed in NetworkManager release 1.26.6. |
|
Also, AFAICT, the latest Ubuntu LTS ships a version of NetworkManager that contains the fix: |
I'm experiencing DNS leakage using this script in which the IP addresses of my ISP's DNS servers are visible. Strangely, the IP addresses of my VPN's DNS servers are also visible. I'm running an OpenVPN server connected to a Comcast router.
From DNS Leak Test:
systemd-resolve --status reports that everything is fine with the tunnel, so I assume I'm leaking traffic to some other interface:
OpenVPN client configuration:
I know very little about networking, so I apologize if this is a trivial issue. Any insight would be greatly appreciated.
The text was updated successfully, but these errors were encountered: