Improve DNS handling? #600
Comments
|
Additionally I believe we need to always support all of |
|
I have tried to create a list of
Most notably
|
|
Supporting I'm a bit hesitating about the movement of the decision from configure time to the runtime. Programs running with elevated privileges should call other programs with an absolute path. If this decision can not be detected at configure time, we may end up with checking several possibilities at runtime and expectations e.g. about how trustworthy directories below So, shall we check a couple of locations which we think are safe at runtime? Or shall we rely on a mechanism of the OS to locate the right executable (use $PATH and sanitize it somehow), anything else? Whatever we chose, it should also be portable. One could argue, openfortivpn needs to run as root anyway, so the user who is allowed to use it must be trustworthy in some sense, but I'm sure some admins provide their users with sudo privileges, the privilege to control network manager, or a systemd service that opens the vpn tunnel on request by the otherwise less trusted employee. I feel a bit uncomfortable with the idea of putting too much automatism to runtime. |
|
I absolutely agree, we should not let openfortivpn search the PATH or anything else to find a way to modify DNS parameters. Paths need to be hardcoded. That's why I have researched the location of the executables for various distributions. Therefore by default we should attempt to run only the following executables in directories controlled by the system:
Note that the broken systemd alias We should also allow for additional/alternative paths to these executables at build-time, for obscure distributions that use different paths or end-users who build & install themselves in different locations. Finally we should examine the exit status of the executables to catch errors. Will have to experiment with exit status values a little bit. |
|
A relevant pull request has just appeared: #615 @da-x Can you please help understand the pull request and comment with respect to other solutions above?
|
|
Here are the services provided by @da-x You seem to be calling methods SetLinkDNS, SetLinkDomainsand also SetLinkDNSSEC. Is the last one required? I'm not very familiar with DNSSEC |
|
@DimitriPapadopoulos this bash script code is based on code from https://github.com/jonathanio/update-systemd-resolved, which does similar stuff but for OpenVPN. You can check with them. Now, there's also a hidden assumption that |
|
@da-x Right, on Fedora |
|
@DimitriPapadopoulos No, there's an assumption that it's enabled and |
|
@da-x Then I suspect it might be much better to rewrite the script directly in C (since openfortivpn is already linked with systemd). Then:
|
|
If
Or:
Where Also, I used the script as a stop-gap. I'm not sure I can dedicate the time now to implement it in C. So feel free to close that PR for now, or go about implementing it in C. |
|
On Ubuntu 18.04: On Fedora 31: The order you are referring to is for DNS resolution which is not really relevant here. What we are after is the order of the tools to try to modify the parameters of DNS resolution. I believe these are two different things. |
|
Important to note is that if |
|
It's getting more and more complicated:
Still investigating... |
|
Note that |
|
This ArchWiki OpenVPN page is quite interesting:
|
That's why I implemented that same approach for openfortivpn - running an external user-configured script. Looking at this I got the feel that the variety of DNS configurations and methods may be too wide for openfortivpn to guess what's preferred for the current system, especially if you want to support old systems. There isn't yet a widespread acceptable default across all distributions. |
|
hi, This would make extremely easy to share script with friend and colleague |
On the other hand such scripts usually need to run with |
|
yes permission should be dropped to user if run from user folder, is a problem of the admin to give right permission to user (i believe some systemd stuff will ask for password if a GUI is running, at least systemctl does) |
|
Since Fedora33 went GA, we now have |
|
Actually, one needs to manually call resolvconf to inject the search-dns
I presume you meant to say resolvectl instead.
As in case somebody else needs this, the exact invocation is:
resolvectl dns ppp0 1.2.3.4
resolvectl domain ppp0 example.com
|
|
@peterhoeg on fedora you can also inject them using |
|
The problem with As far as I know At the same time we need to modify openfortivpn so that NetworkManager can use it more efficiently as a plugin. |
|
Another option is to simply make it configurable and remove the guess-work.
|
|
@peterhoeg That's an excellent idea. While that's of course orthogonal to your suggestion, note that there are additional benefits to moving routing/DNS to a shell script outside of the C core:
Do you have suggestions which DNS configurations are required to support all Linux distributions? I have been struggling for years to find a clear explanation of the different DNS configurations. Here my current understanding:
|
|
"Just" have an option for DNS handling with one of the following:
- systemd-resolve (I will suggest doing a dbus call instead of calling a binary, but I obviously don't know how keen you are on adding dependencies)
- network-manager (again, dbus would be preferred or nmcli alternatively)
- modify resolv.conf
- none
- custom (pass a binary/script to run on up/down)
As for routing, openvpn recently gained support for setting up routing via netlink: https://github.com/OpenVPN/openvpn/blob/release/2.5/Changes.rst
That really is a separate issue though, but an approach similar to DNS might be worth considering.
And thank you for openfortivpn. It works brilliantly!
|
|
@peterhoeg Thanks for the list. I think it's OK to have a D-Bus dependency nowadays, isn't it? I wasn't really aware of Netlink - just had noticed |
I tend to disagree. It is the distro's (or on Arch the user's) responsibility to have a consistent system configuration. For example, when using Also, you haven't mentioned yet that dnsmasq can be used as a local DNS cache. That's also supported by NetworkManager ( Please provide some mechanism to pass the DNS information to NetworkManager so that it can pass the information on to whatever is configured in Adding a parameter so that a custom script is called instead of I vaguely recall writing a script that passed DNS information to NetworkManager via dbus. But I fail to remember the details or why I actually needed it. I assume it was for my Gentoo system, which I deleted. I am using Arch now. |
|
Can't you copy what networkmanager-pptp is doing? That's another PPP-based VPN. I have setup a PPTP server real quick, and Networkmanager is informed about the DNS servers that my server sends. Also, https://gitlab.gnome.org/GNOME/NetworkManager-pptp/-/blob/master/src/nm-pptp-pppd-plugin.c#L209 |
|
Pull requests are welcome. |
|
In the very short term, we need to re-enable Also read this document: |
|
Is there any workaround for Fedora 36? |
|
My workaround is a |
|
Tks @peterhoeg ! It's like I've been doing. For those using Fedora 36 and close, this should work: # start vpn
sudo openfortivpn vpn.mydomain.com:443 --username=MY_USER --set-dns=0 -v
# get VPN network interface name
resolvectl dns
# or
ip -br -c a
# manually add dns in interface
sudo resolvectl dns ppp0 10.41.1.1 10.41.1.2
# manually add search domain
sudo resolvectl domain ppp0 mydomain.comNow the name resolution should work. ps: for those who have |
|
Fedora 36 and issues with this. And the new lines added to resolv.conf are not picked up by OS. |
|
If you’re using resolved, I will strongly recommend running `openfortivpn' with `--set-dns=0' and then manually call `resolvectl' in order to set search domain and dns servers on the given connection.
|
|
I believe I'm using resolved? I use whatever ships with the distro and try not to do anything custom. :) But out of the blue openfortivpn stopped working - well stopped giving the correct DNS's to the system. Without vpn With openfortivpn connected with set-dns = 0 With openfortivpn connected with set-dns = 0 and pppd-use-peerdns = 1 With ipsec connected |
|
With `set-dns = 0', you need to manually assign the search domains and dns servers on the link. So something like this:
┌────
│ sudo resolvectl dns ppp0 1.2.3.4
│ sudo resolvectl domain ppp0 some.domain.tld
└────
Obviously only until `openfortivpn' gets native support.
|
|
Perhaps #1092 (previously #615) can help with systems based on systemd-resolved. I haven't tested yet, but you can start testing the systemd-resolved branch. |
@skoehler I am not claiming we need to take care of all subsystems on a given machine. But we do need to support all kinds of subsystems to support different machines: those based on As I said, pull requests are welcome. Maintainers usually do not lack good ideas, but time to implement them. You could start by looking into #1092 (previously #615), testing and improving. |
I'm not sure what have happened. But everything worked perfectly some time ago. Actually it have worked perfectly for the last 7 months (atleast, that's how long I've had this workstation and OS install) So I have to disagree. One does not have to manually set the dns records. Or atleast should not have to. Now I must, but previously I did not have to. The set-dns=0 was my testing as I felt that setting the resolv.conf -file may not be the wanted behaviour. I also tested all combinations of set-dns & pppd-use-peerdns with no luck. |
|
@Hount By modifying
|
|
We should probably let vpnc-scripts handle routing and DNS, see #678. |
|
I've had success on Ubuntu using a pppd #!/usr/bin/bash -eu
resolvectl default-route "$IFNAME" false
resolvectl domain "$IFNAME" '~your.company.com'
resolvectl dns "$IFNAME" "$DNS1" "$DNS2"And then when connecting use |
Rationale
Setting DNS parameters has been raising different issues:
resolvectlfrom systemd is often available at run-time on Fedora machines but is not available at build-time by default)resolvconffrom systemd does not work as expected on Fedora as seen in openfortivpn 1.12 / DNS configuration problems #555)Especially Fedora and CentOS have been challenging so far. Short of interacting with NetworkManager directly when NetworkManager is installed and used, I suspect the official way to modify DNS parameters on CentOS >= 8 and Fedora is running
resolvectlwhich has been part of the systemd package since CentOS >= 8 (not CentOS 7 which is probably whybusctlis used in #615).Proposal for setting DNS parameters
Is it worth trying to further improve the DNS configuration mechanism when
--set-dns=1? Perhaps using the following mechanisms and other ones you can think of?nmcli?resolvectlfrom systemd is available run it to modify DNS parameters.resolvconfis available and works properly (either openresolv or resolvconf but not resolvectl), run it to modify DNS parameters./etc/resolv.confdirectly.NetworkManager is a special case: I am not sure about supporting NetworkManager because NetworkManager already supports openfortivpn through NetworkManager-fortisslvpn. It's the other way round.
Documentation
Man pages:
Hopefully we can get some info from this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1815605
The text was updated successfully, but these errors were encountered: