résolu par systemd, resolvconf.service, resolvconf et openresolv. Pourquoi, lequel et comment?

J'utilise un client VPN qui ajoute deux serveurs de noms à /etc/resolv.conf. Toutes mes connexions sont gérées par Network-Manager.

Je dois utiliser ce client VPN pour mon travail VPN mais après qu'Ubuntu soit passé systemd-resolveden 16.10, j'ai des problèmes avec ma connexion et mon DNS. Ressemble à des systemd-resolvedmodifications apportées /etc/resolv.confaux serveurs de noms par défaut pour une raison quelconque, ce qui rend les pages internes non résolues. J'ai approfondi la question et j'ai fini par la remplacer resolvconfpar openresolv. Cela a beaucoup aidé, mais se systemd-resolvedréinitialise toujours /etc/resolv.confaprès que le VPN a été mis en place pendant un certain temps.

Cela peut être juste lorsque la connexion est établie ou après quelques minutes ou parfois pas du tout. J'ai ensuite désactivé systemd-resolvedet le systemd resolvconf.serviceseul et courir openresolv. Il semble que tout fonctionne bien.

Cependant, tout cela est très déroutant. Y a-t-il une raison d'utiliser systemd-resolvedavec l'un des autres? Il a été activé dans Ubuntu 16.10, donc je pensais qu'il devait y avoir une raison, mais cela semble provoquer un combat /etc/resolv.conf.

Ce serait formidable si je pouvais simplement courir operesolvet faire expliquer cela. J'ai fait pas mal de lecture à ce sujet mais je ne comprends toujours pas pourquoi /etc/resolv.confest géré tel qu'il est, seulement que lorsque je l'utilise systemd, je ne peux pas utiliser mon client VPN.

J'ai réussi à changer le script qui gère ces éléments de configuration dans OpenVPN dans Ubuntu (testé le 18.04). Voici un patch pour ça:

--- /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

Vous devrez ajouter les éléments suivants à votre fichier de configuration OpenVPN:

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

Quel client VPN utilisez-vous? J'avais des problèmes avec OpenVPN, mais l'installation de la version NM du client a résolu les problèmes. Eh bien, la plupart d'entre eux, je ne pouvais pas empêcher un itinéraire d'être poussé, mais c'est un problème complètement différent.

Le fait est que votre client VPN doit savoir comment interagir avec l'idée de systemd sur la façon de gérer le service DNS. Je ne le recommande pas, mais vous pouvez essayer de désactiver le service resolvd ( systemctl disable systemd-resolved.service) pour voir si cela améliore les choses, mais en fin de compte, vous devrez obtenir un client qui comprend comment se soumettre aux caprices de systemd :)

(Le vaisseau systemd a navigué il y a longtemps, n'ouvrons pas de discussion sur la raison pour laquelle certaines choses ont été faites.)

Une mise à jour du client VPN que j'ai utilisé a résolu (jeu de mots) le problème. C'était le client OpenFortiGui pour Fortinet VPN.