Oh, understood. Then it is specific problem to Fedora, because I think
other distributions do not use systemd's implementation of resolvconf
binary.
I think original Debian resolvconf package does not use -a interface
parameter for anything serious. It just uses the same interface
identifier to pair -a and -d for the same connection.
On the other hand systemd's resolvconf tracks settings per interface and
it requires it to point to the real interface on the system. Of course
F5 client should use a real interface name it is going to use. I am not
sure what can be done for it on side of systemd. Perhaps systemd could
allow configuration of aliases, so it would allow to map eth0.f5 to tun0
interface. But that seems a mere workaround, F5 client should be
modified to call resolvconf once it knows used interface name, not
before that. It would be nice to issue a bug on F5 site. I haven't found
issue matching your description. It would be worth filling.
https://support.f5.com/csp/bug-tracker
On 11/2/22 16:20, Thomas HUMMEL wrote:
On 10/31/22 12:19, Petr Menšík wrote:
Hello, thank you and Barry as well for your answers
I would suggest using strace to find what exactly it does and what it
tries to modify. I expect sources for that client are not available.
Well, digging a little deeper, here's what I've found out:
1) in the default case (described in my initial post), i.e.
/etc/resolv.conf symlinked to systemd-resolved
/run/systemd/resolve/stub-resolv.conf
no dns nor rc.manager directives in NM config
no F5 client NM profile
The vpn client:
a) backs up /etc/resolv.conf to /etc/resolv.conf.fp-saved
b) readlinks the symlink
c) execve's /sbin/resolvconf providing nameservers (thus trying to
play along with systemd-resolved) but on the wrong interface on my
Fedora (eth0.f5 instead of tun0) [besides with a deprecated and not
used arg (-m)]
execve("/sbin/resolvconf", ["/sbin/resolvconf", "-a", "eth0.f5",
"-m 0"], 0x7ffd13bf8568 /* 30 vars */ <unfinished ...>
d) set up tun0 interface and bring it up
-> hence we end up with:
a) /etc/resolv.conf.fp-saved as a regular file, copy of
/run/systemd/resolve/stub-resolv.conf
b) NM managed tun0 interface without and dns property in its
profile nor any disk persistent profile
c) unchanded /etc/resolv.conf (still linked to
/run/systemd/resolve/stub-resolv.conf
so, systemd-resolved not knowing about vpn nameservers and vpn
nameresolution fails without workaround (like resolvectl dns adding
the tun0 nameserver for instance)
2) with NM handling /etc/resolv.conf as a regular file, i.e.
/etc symlink rm-ed
dns=default
rc.manager=file
the F5 client consider it a 'legacy' setting and overwrite (which is
wrong to me) NM managed /etc/resolv.conf regular file
it restores it when stopped by copying back /etc/resolv.conf.fp-saved
That is exactly what it should do for a VPN, unless it knows a more
proper way to configure system DNS. Some packages like dnssec-trigger
prevents that by setting additional parameter to /etc/resolv.conf,
making it non-writeable even by root process. There is not a generic and
better way other than resolvconf. On Fedora resolvconf is provided just
for systemd-resolved in default installation. But it needs precise
interfaces used, unlike original implementation.
So, basically I'd say there are 2 bugs :
1) legacy handling which seems to consider pre-NM era legacy
2) resolvconf call when systemd-resolved is used (at least on Fedora)
In any case, I don't understand why it does not set the NM profile
ipv4.dns property, which would let much more chances for NM and/or
resolved to work
Does "nmcli c" command show F5 profile in green, when it is connected?
"nmcli c show <connection-name>" would provide all details it knows. I
am not sure how information obtained from VPN plugins should work. I
think network manager list has to be used for qualified response. It
seems to me only VPNs configured by NM plugin know configuration details.
Anyway, this leaves 2 unanswered questions, the first of which was my
initial one:
1) how could, when all resolv.conf-as-a-file-by-NM conf has been
removed (by me) and symlink to stub has been restored (by me)
systemd-resolved, with *no trace* of the vpn nameservers in its own
/run/systemd/resolv/resolv.conf nor seemingly nowhere else, can be
still aware of the vpn nameservers (as described in my initial post
scenario) ?
-> is there a persistent systemd-resolved cache on disk somewhere?
I don't think any persistent cache were ever on disk or that it would be
a good idea. Most dns caches are able to dump contents of cache
somewhere on request, but I haven't found a way to do that with resolvectl.
2) when running resolvconf by hand (resolvconf <int>) providing
specific interface specific nameservers (on stdin), it seems to update
the **global** /run/systemd/resolve/resolv.conf (hence making those
nameservers available for all interfaces ?)
-> Is there any other place where the specific ns <-> interface is
persited or stored or is this global updating all there is ?
resolvconf might have some hacks to configure rules just for some
subdomains. openresolv can do something similar. But usually resolvconf
changes just global set of servers if the interface configured has
higher priority than previous. Returns them back when such interface is
stopped. resolvectl layer ignores -m parameter, but it pairs dns
configuration with real interface. AFAIK none such information is
persistent and is lost when systemd-resolved is restarted. But Network
Manager's plugins configures it from NM interfaces again. I doubt
external services unrelated to NM are handled, I think they have to
reconfigure systemd-resolved again after its restart. Nothing is stored
permanently.
Thanks for your help
--
Thomas HUMMEL
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
