systemd-resolved, resolvconf.service, resolvconf e openresolv. Por que, qual e como?

Estou usando um cliente VPN que adiciona dois servidores de nomes /etc/resolv.conf. Todas as minhas conexões são gerenciadas pelo Network-Manager.

Eu tenho que usar esse cliente VPN para o meu trabalho VPN, mas depois que o Ubuntu foi systemd-resolvedlançado em 16.10, eu estava tendo problemas com minha conexão e DNS. Parece que há systemd-resolvedmudanças /etc/resolv.confnos servidores de nome padrão por algum motivo, o que faz com que as páginas internas não sejam resolvidas. Eu olhei para isso um pouco mais e acabei substituindo resolvconfpor openresolv. Isso ajudou muito, mas ainda é systemd-resolvedredefinido /etc/resolv.confdepois que a VPN está ativa há um tempo.

Pode ser exatamente como a conexão está ativa ou após alguns minutos ou às vezes nem um pouco. Eu então desabilitei systemd-resolvede a systemd resolvconf.serviceúnica execução openresolv. Tudo funciona bem, parece.

No entanto, tudo isso é muito confuso. Existe uma razão para usar systemd-resolvedcom um dos outros? Ele foi ativado no Ubuntu 16.10, então pensei que deveria haver uma razão para isso, mas parece causar uma briga /etc/resolv.conf.

Seria ótimo se eu pudesse correr operesolve explicar isso. Eu já li bastante sobre isso, mas ainda não entendo por que /etc/resolv.confé gerenciado como é, apenas que, quando o uso systemd, não posso usar meu cliente VPN.

Consegui mudar o script que lida com esses itens de configuração no OpenVPN no Ubuntu (testado em 18.04). Aqui está um patch para isso:

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

Você precisará adicionar os seguintes itens ao seu arquivo de configuração do OpenVPN:

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

Qual cliente VPN você está usando? Eu estava tendo problemas com o OpenVPN direto, mas a instalação da versão NM do cliente resolveu os problemas. Bem, na maioria deles, não pude impedir que uma rota fosse empurrada, mas essa é uma questão completamente diferente.

O ponto é: seu cliente VPN precisa saber como interagir com a idéia do systemd de como gerenciar o serviço DNS. Eu não recomendo isso, mas você pode tentar desativar o serviço resolvd ( systemctl disable systemd-resolved.service) para ver se ele melhora as coisas, mas, no final das contas, você precisará obter um cliente que entenda como enviar aos caprichos do systemd :)

(O navio systemd navegou há muito tempo, não vamos abrir uma discussão sobre por que algumas coisas foram feitas.)

Uma atualização para o cliente VPN que usei resolveu (trocadilhos) o problema. Era o cliente OpenFortiGui da Fortinet VPN.