search

jonathanio / update-systemd-resolved

Helper script for OpenVPN to directly update the DNS settings of a link through systemd-resolved via DBus.
Other
761 stars 94 forks source link

Ubuntu 20.04 - DNS pushed by the ovpn server shown in status, but not reflecting in resolv.conf #80

Closed vishnus closed 1 year ago

vishnus commented 4 years ago

Hi there,

The ovpn server's DNS push is reflecting fine in systemd-resolved --status:

`Link 17 (tun0)
      Current Scopes: DNS        
DefaultRoute setting: yes        
       LLMNR setting: yes        
MulticastDNS setting: no         
  DNSOverTLS setting: no         
      DNSSEC setting: no         
    DNSSEC supported: no         
  Current DNS Server: 192.168.0.2
         DNS Servers: 192.168.0.2

Link 3 (enx8c04ba783dde)
      Current Scopes: none
DefaultRoute setting: no  
       LLMNR setting: yes 
MulticastDNS setting: no  
  DNSOverTLS setting: no  
      DNSSEC setting: no  
    DNSSEC supported: no  

Link 2 (wlo1)
      Current Scopes: DNS    
DefaultRoute setting: yes    
       LLMNR setting: yes    
MulticastDNS setting: no     
  DNSOverTLS setting: no     
      DNSSEC setting: no     
    DNSSEC supported: no     
  Current DNS Server: 1.1.1.1
         DNS Servers: 1.1.1.1
          DNS Domain: ~.`

But the /etc/resolv.conf still shows only 127.0.0.53. and dig to an internal domain doesnt work.

Symlink is to stub-resolv.conf: /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf

I've disabled the dns in NetworkManager.conf also, and set the vpn's dns priority as -42. Still doesnt seem to work.

Finally I disabled systemd-resolved service and switched to coredns, but then the connection itself is failing with this error: WARNING: Failed running command (--up/--down): external program exited with error status: 1 Exiting due to fatal error

How can we solve this in Ubuntu 20.04 without having to disable this service? What could be the issue here?

audetto commented 4 years ago

I think the issue is different. The problem for me is that the tun0 DNS does not have

DNS Domain: ~.`

and so it is not used. If you try to connect via NetworkManager, then the DNS Doman of the tunnel is set. I am not sure how it works, but it makes it the "default" or something similar.

This script sets the DNS for the tunnel, but does not make them the default.

mihneadb commented 4 years ago

I also have trouble getting this working with 20.04.

piotr-dobrogost commented 3 years ago

If you try to connect via NetworkManager, then the DNS Doman of the tunnel is set. I am not sure how it works, but it makes it the "default" or something similar.

This is the effect of not checking “Use this connection only for resources on its network” option for VPN link in NetworkManager. For more details see https://fedoramagazine.org/systemd-resolved-introduction-to-split-dns/

This script sets the DNS for the tunnel, but does not make them the default.

To make it the default you have to add the following line to your .ovpn config file for vpn:

dhcp-option DOMAIN-ROUTE .

However, the same might be already set for other links in which case DNS queries would be send to all DNS servers specified for links with this setting. See https://github.com/jonathanio/update-systemd-resolved/issues/59 for a script removing ~. from all other links to make sure all DNS queries are being routed through VPN link only.

TinCanTech commented 3 years ago

OpenVPN does not support dhcp-option DOMAIN-ROUTE

piotr-dobrogost commented 3 years ago

@TinCanTech Why do you think so? See https://github.com/jonathanio/update-systemd-resolved/issues/28

TinCanTech commented 3 years ago

Openvpn --dhcp-option is primarily intended for Windows. However .. It turns out that OpenVPN for Windows does not allow dhcp-option DOMAIN-ROUTE OpenVPN for Linux does not check the option strings in use and will allow anything. eg. dhcp-option PHEASANT PLUCKER .. So I guess you can use anything as a --dhcp-option so long as you do not use Windows -- Until today, I was unaware of this difference in behaviour -- So, Hack away!

tomeon commented 1 year ago

@vishnus @audetto @mihneadb -- does the tip about DOMAIN-ROUTE and/or the NetworkManager script from #59 address your issues?

tomeon commented 1 year ago

NetworkManager release 1.26.6 no longer assigns the ~. routing domain to all managed interfaces (see its NEWS file).

Closing this issue; please reopen if upgrading NetworkManager and/or setting dhcp-option DOMAIN-ROUTE . does not solve the problem.