systemd-resolved, resolvconf.service, resolvconf и openresolv. Почему, что и как?

12

Я использую VPN-клиент, который добавляет два сервера имен /etc/resolv.conf. Все мои соединения управляются Network-Manager.

Я должен использовать этот VPN-клиент для своей рабочей VPN, но после перехода на Ubuntu systemd-resolvedв 16.10 у меня возникли проблемы с подключением и DNS. Похоже, systemd-resolvedизменения /etc/resolv.confпо умолчанию возвращаются на серверы имен, что не разрешает внутренние страницы. Я посмотрел на это еще немного и в итоге заменил resolvconfна openresolv. Это очень помогло, но все еще systemd-resolvedсбрасывается /etc/resolv.confпосле того, как VPN некоторое время работал.

Это может быть так же, как соединение установлено или через несколько минут, а иногда и вовсе нет. Я тогда отключил systemd-resolvedи то systemd resolvconf.serviceи только бегаю openresolv. Кажется, все работает хорошо.

Однако все это очень запутанно. Есть ли причина для использования systemd-resolvedс одним из других? Он был включен в Ubuntu 16.10, так что я подумал, что для этого должна быть причина, но похоже, что бой окончен /etc/resolv.conf.

Было бы здорово, если бы я мог просто бежать operesolvи объяснить это. Я довольно много читал об этом, но я до сих пор не понимаю, почему /etc/resolv.confуправление происходит так, как есть, только то, что когда я использую systemdего, я не могу использовать свой VPN-клиент.

Кристиан
источник
FWIW resolvconf.service - это то, как systemd работает с resolvconf. Какой VPN-клиент вы используете? Если вы использовали systemd-resolved, он делает resolv.conf символической ссылкой на свой личный /run/systemd/resolve/resolv.confфайл. Возможно, вы захотите попробовать systemd-networkd управлять вашими соединениями.
pbhj

Ответы:

1

Мне удалось изменить скрипт, который обрабатывает эти элементы конфигурации в OpenVPN в Ubuntu (протестировано 18.04). Вот патч для этого:

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

Вам нужно будет добавить следующие элементы в файл конфигурации OpenVPN:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
Антон
источник
0

Какой VPN-клиент вы используете? У меня были проблемы с прямым OpenVPN, но установка клиентской версии NM устранила проблемы. Ну, большинство из них, я не мог предотвратить проталкивание маршрута, но это совершенно другая проблема.

Дело в том, что ваш VPN-клиент должен знать, как взаимодействовать с идеей systemd о том, как управлять службой DNS. Я не рекомендую этого, но вы можете попытаться отключить функцию resolvd ( systemctl disable systemd-resolved.service), чтобы посмотреть, улучшит ли это что-то, но в конечном итоге вам потребуется клиент, который понимает, как подчиняться капризам systemd :)

(Системный корабль давно отплыл, давайте не будем обсуждать, почему некоторые вещи были сделаны.)

JayEye
источник
Эта проблема была решена в обновлении VPN-клиента. Это был клиент OpenFortiGui для моей работы Fortinet VPN. Так что вы абсолютно правы, клиент теперь выучил systemd! :)
Кристиан
0

Обновление VPN-клиента, которое я использовал, решило проблему (каламбур). Это был клиент OpenFortiGui для Fortinet VPN.

Кристиан
источник