Как сохранить конфигурацию "systemd-resolver" для определенного сетевого интерфейса?

Я понимаю, что этот вопрос был здесь 2 месяца, но, возможно, вам все еще нужны ответы?

1) Systemd-networkd хранит сетевые конфигурации в (как минимум) 3 каталогах, может быть, больше. Наиболее подходящим для вас является:

/etc/systemd/network/ 

(он переопределяет другие 2, а именно /lib/s/n и /run/s/n.

Создайте текстовый файл, похожий на этот:

[Match]
Name=enp0s4

[Network]
DHCP=yes
DNS=192.168.1.1

Вы можете называть его так, как хотите, кажется, пока он находится в этом каталоге, мой называется enp0s4.network, правильное получение контента имеет решающее значение, если вы ошибаетесь, случаются плохие вещи, например, ваша сеть перестает работать, по крайней мере на этом интерфейсе, пока вы не восстановите рабочий конфиг. Что нелегко, я все испортил, и мне потребовался час, чтобы разобраться. Хорошо, что мой "сервер" находится в соседней комнате, а не в удаленном центре обработки данных!

Примеры того, как настроить мост, читайте здесь:

man systemd.network |grep -A 42 "Example 3"

Примеры, приведенные там, плюс мой фрагмент кода можно настроить:

Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 10.78.38.1

Не уверен, что синтаксис для домена DNS, это должно быть возможно, man-страница размером с 30 страниц! Если вы можете, пропустите это, попытавшись "Domain=" испортить мою систему, вот почему я знаю, что неправильно это неправильно, личный опыт.:-) Так что найдите правильный синтаксис или не вставляйте его, если вы не можете восстановить.

Восстановление это еще один пост, хотя я устал.

Вот ссылки, которые я использовал:

Как проверить, работает ли сеть: /questions/807633/kak-otlazhivat-systemd-networkd

Как включить, если он отключен: https://askubuntu.com/posts/681768/revisions

Перезапустите systemd-resolver без перезагрузки:

sudo systemctl restart systemd-resolved

К вашему сведению: существует способ сообщить systemd, что Network-Manager должен обрабатывать интерфейс, а также оставить его "неуправляемым" и работать с конфигурациями плоских файлов, такими как /etc/resolv.conf. Но я бы сделал так, как если бы я был на твоем месте. И я просто пытаюсь настроить различные интерфейсы для другой цели, но мне нужна была вся эта информация. выше, чтобы помочь себе, поэтому я думал, что поделюсь. Так как вы поделились, как временно его изменить, что тоже полезно.:-)

НТН

Это звучит правдоподобно, но, похоже, не имеет никакого эффекта:

Согласно связанной man-странице man 8 systemd-resolved.service, вы должны использовать файл конфигурации для каждой ссылки в /etc/systemd/network:

DNS-серверы, с которыми установлено соединение, определяются из глобальных настроек в /etc/systemd/resolved.confстатические настройки для каждой ссылки в /etc/systemd/network/*.network файлы, динамические настройки для каждой ссылки, полученные через DHCP, и любая информация DNS-сервера, доступная другим системным службам.

Чтобы сделать вашу конфигурацию постоянной, вы должны создать файл /etc/systemd/network/lxdbr0.conf:

[Match]
Name=lxdbr0

[Resolve]
DNS=10.78.38.1
Domains=lxd

На этот вопрос до сих пор нет принятого ответа, и, поскольку у меня также были огромные проблемы с разрешением имен контейнеров на хосте, я подумал, что должен предоставить свое решение. Я также делаю это, поскольку эта страница является первым результатом поиска Google при поиске постоянных изменений в sytemd-resolved.service. Наконец, я хочу отметить, что эта проблема Ubuntu >= 18.04 и это версия systemd-resolved.service,

Итак, man - страница systemd-resolved.service уже упоминалась. В случае LXD, однако, из этого были сделаны вводящие в заблуждение выводы. Интерфейс LXD не нужно определять в /etc/systemd/network/<iface>.{conf|network}, Интерфейс уже работает, и поэтому его не нужно определять для администратора сети systemd. По умолчанию у LXD уже есть работающий DNS-сервер, который прослушивает в своих сетях адрес первого хоста. Все, что нам нужно сделать, это получить systemd-resolved.service распознать этот сервер.

На странице руководства (ссылка выше) упоминается это для /etc/systemd/resolved.conf:

Конфигурация по умолчанию определяется во время компиляции, поэтому файл конфигурации необходим только тогда, когда необходимо отклониться от этих значений по умолчанию. По умолчанию файл конфигурации в /etc/systemd/ содержит закомментированные записи, показывающие значения по умолчанию в качестве руководства для администратора. Этот файл можно редактировать для создания локальных переопределений.

Я хочу выделить этот файл, который можно редактировать для создания локальных переопределений. @quat на самом деле вы также ссылаетесь на это в своем актуальном вопросе:

Чтобы сделать это выше, я просмотрел man-страницу systemd-resolver http://manpages.ubuntu.com/manpages/bionic/man8/systemd-resolved.service.8.html. Предлагает создать /etc/systemd/resolved.conf.d/lxd.conf файла, но нет доступных параметров, которые позволили бы мне сделать такую ​​конфигурацию специфичной для одного конкретного сетевого адаптера.

1. Добавление службы lxd dnsmasq в глобальные настройки dns systemd-resolved.service:
Однако я не понимаю ваше последнее предложение. Вам не нужно указывать NIC. Вам просто нужно указать адрес LXD DNS-сервера. Используя информацию о вашей сети, рабочий конфиг для /etc/systemd/resolved.conf будет выглядеть так (раскомментируйте, чтобы изменить значения по умолчанию):

[Resolve]
DNS=10.78.38.1
#OBFallbackDNS=
Domains=LXD
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes

После сохранения файла либо перезагрузите сервер, либо просто systemctl restart systemd-resolved.service Для меня это отлично работало на новой установке Ubuntu-18.04.02. Если это не работает для вас, я предполагаю, что вы либо установили lxd не по умолчанию, либо у вас возникли проблемы / конфликты из-за обновления ОС.

2. ОБНОВЛЕНИЕ (настройка NIC):
Согласно блогу Simos, единственный способ сохранить $ sudo systemd-resolve --interface lxdbr0 --set-dns 10.78.38.1 --set-domain lxd создает специальную службу systemd, инициализирующую конкретную конфигурацию сетевого адаптера при запуске системы. Этот способ в настоящее время является "принятым" подходом на "полуофициальных" linuxcontainers.org

Пример, упомянутый в блоге:
Сценарий оболочки, включающий специфические днс с помощью systemd-resol (lxdhostdns_start.sh)

$ cat /usr/local/bin/lxdhostdns_start.sh 
#!/bin/sh

LXDINTERFACE=lxdbr0
LXDDOMAIN=lxd
LXDDNSIP=`ip addr show lxdbr0 | grep -Po 'inet \K[\d.]+'`

/usr/bin/systemd-resolve --interface ${LXDINTERFACE} \
                         --set-dns ${LXDDNSIP} \
                         --set-domain ${LXDDOMAIN}

Сценарий оболочки, отключающий ник специфичные днс через systemd-resol (lxdhostdns_stop.sh)

$ cat /usr/local/bin/lxdhostdns_stop.sh 
#!/bin/sh

LXDINTERFACE=lxdbr0

/usr/bin/systemd-resolve --interface ${LXDINTERFACE} --revert

Создание службы systemd для управления двумя сценариями и их инициализации при запуске системы:

$ sudo cat /lib/systemd/system/lxd-host-dns.service 
[Unit]
Description=LXD host DNS service
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/local/bin/lxdhostdns_start.sh
RemainAfterExit=true
ExecStop=/usr/local/bin/lxdhostdns_stop.sh
StandardOutput=journal

[Install]
WantedBy=multi-user.target

Последнее, но не менее важное systemctl enable lxd-host-dns.service и перезагрузите хост, чтобы проверить постоянство изменений, запустив systemd-resolve --status, lxbr0 интерфейс теперь должен находиться в области видимости (Current Scopes: DNS). Учитывая вашу сеть, это должно выглядеть так:

Link 3 (lxdbr0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 10.78.38.1
          DNS Domain: lxd

Мне хорошо известно, что это не идеальное решение, и технически оно все еще не дает ответа на ваш вопрос о сохранении этой конфигурации в systemd-resolv. Однако проблема с его сохранением заключается в том, что интерфейс lxbr0 управляется не netplan, а systemd в Ubuntu18.04. Поскольку netplan не знает об интерфейсе, вы не можете использовать вышеупомянутые *.network конфигурации интерфейса для добавления DNS и настроек домена в lxbr0,

Этот ответ - длинная длинная стена текста, но я надеюсь, что она хотя бы немного прояснит проблему. Оба решения разрешают имена контейнеров на хосте Ubuntu. Второй вариант более точен, но если единственным требованием является разрешение имен на хосте, то сделать сервис lxd dnsmasq глобально доступным через /etc/systemd/resolved.conf является жизнеспособной альтернативой, тем более что требуется всего два изменения в файле конфигурации.

Для пользователей Ubuntu (18.04, 18.10, 19.04, 19.10)

Я следовал часам советов по обходу, над, под, сквозь и за systemd-resolve, в том числе постукивал поверх него несколько веселых джигов, пока он ворчал на меня.

Что в итоге сработало для меня, так это

1) оставьте в покое systemd-resolve. Не пытайтесь его модифицировать, не отключайте, не пытайтесь удалить, не отсоединяйте... Не надо... В противном случае бесконечные страдания будут вашим постоянным спутником. "Но я хочу сэкономить место..." Поверьте, просто примите лишние килобайты и двигайтесь вперед...

2) Затем (пере) установите resolvconf sudo apt install resolvconf. Он будет танцевать с systemd-решимостью, как будто они созданы друг для друга.

3) после перезагрузки при необходимости внесите изменения, как раньше, с помощью механизмов resolvconf, таких как добавление содержимого в /etc/resolv.conf.d/resolv.conf/head или иным образом.

Я обнаружил, что музыка, которую эти две системы создают вместе, без моего участия, была... расслабляющей.

Во-вторых... возможно, вы пришли из ifupdown, где вы могли объявить свои DNS-серверы в /etc/network/interfaces вместе с другими настройками IP, и они действительно работали. Но теперь, будучи подорванным netplan и systemd-resolve, вы пытаетесь пролететь через новые волшебные кольца, тратя свои драгоценные ограниченные минуты, часы, ища новую магическую последовательность, чтобы сеть снова заработала...

Если это так, еще раз примите несколько лишних килобайт (я знаю, это смешно!!); просто (пере) установить ifupdown **sudo apt install ifupdown** и снова поработайте через /etc/network/interfaces.

Обе устаревшие системы полностью и без проблем интегрируются в новые системы, которые не работают для вас и многих других людей. И все по цене нескольких лишних килобайт (и оно того стоит).

Было бы действительно любезно, если бы Uber-Powers разместили образовательные комментарии о природе своих новых подсистем во время (как и раньше) установки новой системы, вместо того, чтобы заставлять пользователя узнавать, что что-то не работает, и начинаются долгие поиски решения. (Почему на ум приходит Microsoft...?)