systemd-resolved, resolvconf.service, resolvconf und openresolv. Warum, welches und wie?

Ich verwende einen VPN-Client, der zwei Nameserver hinzufügt /etc/resolv.conf. Alle meine Verbindungen werden von Network-Manager verwaltet.

Ich muss diesen VPN-Client für mein geschäftliches VPN verwenden, aber nachdem Ubuntu auf systemd-resolved16.10 umgestellt wurde, habe ich Probleme mit meiner Verbindung und meinem DNS. Es sieht so aus, als ob aus irgendeinem Grund systemd-resolvedÄnderungen /etc/resolv.confan Standard-Nameservern vorgenommen wurden, die dazu führen, dass interne Seiten nicht aufgelöst werden. Ich habe mir das noch genauer angesehen und am Ende ersetzt resolvconfdurch openresolv. Das half viel, aber immer noch systemd-resolvedzurücksetzt , /etc/resolv.confnachdem die VPN für eine Weile hat.

Es könnte sein, dass die Verbindung gerade besteht oder nach ein paar Minuten oder manchmal überhaupt nicht. Ich habe dann deaktiviert systemd-resolvedund das systemd resolvconf.serviceund nur laufen openresolv. Es funktioniert alles gut, wie es scheint.

Dies ist jedoch alles sehr verwirrend. Gibt es einen Grund für die Verwendung systemd-resolvedmit einem der anderen? Es wurde in Ubuntu 16.10 aktiviert, also dachte ich, dass es einen Grund dafür geben muss, aber es scheint einen Streit zu geben /etc/resolv.conf.

Es wäre großartig, wenn ich einfach rennen operesolvund mir das erklären lassen könnte. Ich habe viel darüber gelesen, aber ich verstehe immer noch nicht, warum /etc/resolv.confes so gehandhabt wird, nur dass ich systemdmeinen VPN-Client nicht verwenden kann , wenn ich es verwende.

Ich habe es geschafft, das Skript zu ändern, das diese Konfigurationselemente in OpenVPN in Ubuntu (getestet am 18.04) verarbeitet. Hier ist ein Patch dafür:

--- /etc/openvpn/update-resolv-conf.orig    2019-03-13 19:14:16.163914424 +0400
+++ /etc/openvpn/update-resolv-conf 2019-03-13 19:29:30.380420708 +0400
@@ -15,7 +15,7 @@
 #     foreign_option_3='dhcp-option DOMAIN be.bnc.ch'
 #

-[ -x /sbin/resolvconf ] || exit 0
+[ -x /usr/bin/systemd-resolve ] || exit 0
 [ "$script_type" ] || exit 0
 [ "$dev" ] || exit 0

@@ -43,16 +43,16 @@
        fi
    done
    R=""
-   [ "$SRCHS" ] && R="search $SRCHS
-"
+   for SRCH in $SRCHS ; do
+       R="${R}--set-domain=$SRCH "
+   done
    for NS in $NMSRVRS ; do
-           R="${R}nameserver $NS
-"
+       R="${R}--set-dns=$NS "
    done
-   echo -n "$R" | /sbin/resolvconf -a "${dev}.openvpn"
+   /usr/bin/systemd-resolve -i ${dev} ${R}
    ;;
   down)
-   /sbin/resolvconf -d "${dev}.openvpn"
+   echo "Doing nothing, interface disappears."
    ;;
 esac

Sie müssen der OpenVPN-Konfigurationsdatei die folgenden Elemente hinzufügen:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Welchen VPN-Client verwenden Sie? Ich hatte Probleme mit OpenVPN, aber die Installation der NM-Version des Clients behebt die Probleme. Nun, die meisten von ihnen konnten nicht verhindern, dass eine Route verschoben wurde, aber das ist ein ganz anderes Thema.

Der Punkt ist: Ihr VPN-Client muss wissen, wie er mit der Idee von systemd interagieren kann, wie der DNS-Dienst verwaltet wird. Ich empfehle dies nicht, aber Sie können versuchen, den Resolvd-Dienst zu deaktivieren (systemctl disable systemd-resolved.service ) zu sehen, ob er die Dinge verbessert, aber letztendlich müssen Sie einen Client finden, der versteht, wie man sich an die Launen von systemd richtet :)

(Das Systemschiff ist vor langer Zeit gesegelt. Lassen Sie uns keine Diskussion darüber eröffnen, warum einige Dinge getan wurden.)

Ein Update auf den VPN-Client, den ich verwendet habe, hat das Problem behoben (Wortspiel beabsichtigt). Es war der OpenFortiGui-Client für Fortinet VPN.