systemd-resolved не работает с OpenVPN

Покажи /etc/resolv.conf и /etc/nsswitch.conf.

Алсо, правильный тег — «systemd». На тег «systemd-resolved» подписано ровно 0 человек.

Это давнишняя дыра, Поттеринг извивается как уж и говорит что всё нормально работает и мол not a bug.

Так-то надо в openvpn'ский скрипт up запихать невменяшку типа

busctl call org.freedesktop.resolve1 /org/freedesktop/resolve1 org.freedesktop.resolve1.Manager SetLinkDNS 'ia(iay)' 2 0.0.0.0

Оно удалит DNS со второго интерфейса. Можно сохранить что было, а потом при openvpn down скормить то же самое только вместо 0.0.0.0 IP сохранённого старого DNS

Пляски с /etc/resolv.conf мало помогают, тем более что непонятно, когда и как оно его перечитывает, да и systemd лазает в /etc/resolvconf/resolv.conf.d/ где может быть куча дополнительного барахла, а реально пользуется /run/resolvconf/resolv.conf который вроде как создаётся из кучи разных мест, в том числе и из вышеупомянутых.

Ещё возможно, DNSSEC «мешает», если на основном domain.net он включен, а на corp.domain.net — выключен.

Покажи /etc/resolv.conf и /etc/nsswitch.conf

Вот это я сделал потому что в мануале было написано:

$ ls -la /etc | grep resolv
lrwxrwxrwx  1 root root     37 May 31 21:20 resolv.conf -> /run/systemd/resolve/stub-resolv.conf

$ cat /etc/resolv.conf 
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0

$ cat /etc/nsswitch.conf 
# Name Service Switch configuration file.
# See nsswitch.conf(5) for details.

passwd: files mymachines systemd
group: files mymachines systemd
shadow: files

publickey: files

hosts: files mymachines myhostname resolve [!UNAVAIL=return] dns
networks: files

protocols: files
services: files
ethers: files
rpc: files

netgroup: files

Ещё возможно, DNSSEC «мешает», если на основном domain.net он включен, а на corp.domain.net — выключен.

Насколько я знаю оно у меня нигде не используется.

Оно удалит DNS со второго интерфейса.

Я вот не совсем понимаю как они DNS вешают на интерфейс? Ведь это же просто IP на который надо отправить запрос: разве интерфейс не от раутинга на этот IP зависит в данном случае?

Вот это я сделал потому что в мануале было написано

Да, всё правильно. Должно работать, у меня работает.

Насколько я знаю оно у меня нигде не используется.

DNSSEC setting: allow-downgrade

Используется.

Попробуй глобально отключить (resolved.conf).

Попробуй глобально отключить (resolved.conf).

Link 19 (tun0)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
DefaultRoute setting: yes
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: 10.90.0.1
         DNS Servers: 10.90.0.1
          DNS Domain: corp.domain.net

Сделал, все равно не работает.

Странно. Не воспроизвёл.

Сам внутренний DNS-сервер (10.90.0.1) отвечает правильно, если его напрямую nslookup’ом попросить? systemd-resolve server.corp.domain.net что-нибудь говорит? Логи самого resolved?

Напиши дистрибутив и версию, попробую поднять в контейнере и поковырять.

Я вот не совсем понимаю как они DNS вешают на интерфейс? Ведь это же просто IP на который надо отправить запрос: разве интерфейс не от раутинга на этот IP зависит в данном случае?

Разумеется, пока ещё, DNS никак не вешается, да и не связан вообще с интерфейсом. Просто почему-то создатель systemd считает, что у каждого интерфейса должна быть настройка DNS и это со всеми этими танцами вокруг всенепременного fallback DNS, приездом DNS при DHCP ACK и прочая вылилось в тонну завязанных в узел костылей, которые хрен поймёшь как работают. Если у тебя много интерфейсов и на каждый из них каким-либо образом приезжает информация о DNS, то проще отстранить systemd от руления сетью, чем заставить это работать так, как тебе нужно.

Я вот не совсем понимаю как они DNS вешают на интерфейс?

Очень просто: для этого запроса будут учитываться только те маршруты, которые уходят с этого интерфейса. Полезно, когда у тебя несколько default маршрутов.

Э-э-э... Кагбе, чтобы понять какой маршрут будет, надо сначала узнать IP. Чтобы узнать IP надо сначала отправить запрос на DNS. Т.е. до отправки запроса DNS совершенно неизвестно какой будет маршрут. Поэтому как-то привязывать DNS к интерфейсам совершенно бессмысленно и вредно. Получить адреса DNS при поднятии интерфейсов - это нормально. Но как-то в процессе решать за юзера, каким из полученных DNS пользоваться, и тем более выдумывать какие-то fallback DNS - это совершенно никуда не годится.

Кагбе, чтобы понять какой маршрут будет, надо сначала узнать IP

Маршрут до DNS-сервера, а не до ответа.

Маршрут до DNS-сервера, а не до ответа.

До какого из них? Есть 10 DNS на 10 интерфейсах. Как systemd-resolved решает каким из них пользоваться и с какого перепугу он вообще это делает?

Сам внутренний DNS-сервер (10.90.0.1) отвечает правильно

Да, разумеется. Это рабочая система VPN.

если его напрямую nslookup’ом попросить?

$ systemd-resolve server.corp.domain.net
server.corp.domain.net: resolve call failed: Invalid argument

Кстати говоря, когда поднимаю OpenVPN вижу вот такие строки:

UN/TAP device tun0 opened
TUN/TAP TX queue length set to 100
do_ifconfig, tt->did_ifconfig_ipv6_setup=0
/usr/bin/ip link set dev tun0 up mtu 1500
/usr/bin/ip addr add dev tun0 10.90.0.2/16 broadcast 10.90.255.255
/etc/openvpn/scripts/update-systemd-resolved tun0 1500 1555 10.90.0.2 255.255.0.0 init
<14>Jun  1 09:41:57 update-systemd-resolved: Link 'tun0' coming up
<14>Jun  1 09:41:57 update-systemd-resolved: Adding IPv4 DNS Server 10.90.0.1
<14>Jun  1 09:41:57 update-systemd-resolved: Adding DNS Domain corp.overlap.net
<14>Jun  1 09:41:57 update-systemd-resolved: SetLinkDNS(20 1 2 4 10 90 0 1)
<14>Jun  1 09:41:57 update-systemd-resolved: SetLinkDomains(20 1 corp.domain.net false)
/usr/bin/ip route add 172.16.1.0/24 metric 1 via 10.90.0.1

Логи самого resolved?

Из интересного только это:

$ sudo journalctl -u systemd-resolved
Jun 01 09:41:57 crow systemd-resolved[8615]: Flushed all caches.
Jun 01 09:42:18 crow systemd-resolved[8615]: Failed to send hostname reply: Invalid argument

Но это похоже вывод когда nslookup делаю.

Напиши дистрибутив и версию, попробую поднять в контейнере и поковырять.

$ sudo uname -a
Linux crow 5.0.13-arch1-1-ARCH #1 SMP PREEMPT Sun May 5 18:05:41 UTC 2019 x86_64 GNU/Linux
$ sudo systemctl --version
systemd 242 (242.19-1-arch)
+PAM +AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid

До какого из них?

До рассматриваемого.

Есть 10 DNS на 10 интерфейсах. Как systemd-resolved решает каким из них пользоваться

Всеми одновременно.

и с какого перепугу он вообще это делает?

Потому что такая семантика адекватнее, чем историческая «рандомно выберем один сервер из resolv.conf».

resolve call failed: Invalid argument

Failed to send hostname reply: Invalid argument

А вот это уже интересно.

А вот это уже интересно.

Ну вот да, я подтверждаю что это появляется когда я делаю nslookup.

С другой стороны есть еще более интересная деталь, а именно:

Jun 01 10:08:56 crow systemd-resolved[8615]: Using degraded feature set (TCP) for DNS server 10.90.0.1.
Jun 01 10:08:56 crow systemd-resolved[8615]: Using degraded feature set (UDP) for DNS server 10.90.0.1.
Jun 01 10:08:56 crow systemd-resolved[8615]: Failed to send hostname reply: Invalid argument

То есть все таки 10.90.0.1 таки используется.

Разумеется, пока ещё, DNS никак не вешается, да и не связан вообще с интерфейсом. Просто почему-то создатель systemd считает, что у каждого интерфейса должна быть настройка DNS

Ты спрашиваешь «зачем вообще нужно сопоставлять DNS-серверы интерфейсам». Ответ: потому что DNS-серверы прилетают с автонастройки какого-то конкретного интерфейса. Исторически, на каждом запросе из всех известных системе DNS-серверов выбирается один, а на остальные кладётся хер. Это банально неудобно. systemd-resolved раскладывает DNS-серверы по группам, которые называются «интерфейсами». Внутри «интерфейса» DNS-сервер выбирается по кругу, и запрос отправляется со всех «интерфейсов» одновременно.

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

Ну вот получается, что строго наоборот.

Я тебе приведу пример, почему это может быть удобно: например, я подключен к нескольким провайдерам, foo и bar. Каждый провайдер предоставляет доступ к одному и тому же Интернету + своему собственному интранету (foonet и barnet). Делается это через свои собственные DNS-сервера (основной и резервный), которые умеют отвечать соответственно на запросы foonet.foo.ru и barnet.bar.ru. Теперь я пытаюсь зайти на foonet.foo.ru. Классический линуксовый DNS-ресолвер выберет из четырёх серверов один, отправит запрос на него и с вероятностью 50% я получу хер, потому что запрос о foonet.foo.ru уйдёт в сервер провайдера bar.

systemd-resolved решает эту проблему автоматически, т. к. он разделяет эти 4 DNS-сервера на две группы и отправит запрос одновременно в обе, а вернёт тот ответ, который завершился успешно.

Понимаешь? systemd-resolved — это автоматический инструмент, который автоматически решает стандартную пользовательскую проблему. Если у тебя сложный сетап

Теперь ты приведи пример, почему такое поведение якобы плохо и неправильно.

Получается, что логика выбора DNS-сервера работает правильно, а ломается уже на этапе отправки запроса/получения ответа. Я не смог воспроизвести это на своём арчике. Могу предложить разве что запустить resolved с SYSTEMD_LOG_LEVEL=debug:

mkdir -p /etc/systemd/system/systemd-resolved.service.d
echo -e '[Service]\nEnvironment=SYSTEMD_LOG_LEVEL=debug' >> /etc/systemd/system/systemd-resolved.service.d/override.conf
systemctl daemon-reload
systemctl restart systemd-resolved

Потом сделать это ещё раз и посмотреть в логи. Но я смотрю в код и что-то там очень мало отладочной распечатки вокруг этой функции. Возможно, придётся зарепортить баг в апстрим.

и отправит запрос одновременно в обе, а вернёт тот ответ, который завершился успешно.

Интересное решение. Но что же делать если ответили обе группы, но при этом разными ответами?

Ну то есть опять же, банальный пример, VPN через другую страну. Запрос о google.com вернет два разных IP.

Но что же делать если ответили обе группы, но при этом разными ответами?

Объединить.

VPN через другую страну. Запрос о google.com вернет два разных IP.

Этот юзкейс и эта проблема описывается в «DNS Leakage» в мануале того плагина, на который ты сослался. В таких случаях нужно форсировать отправку запросов только через VPN.

Могу предложить разве что запустить resolved с SYSTEMD_LOG_LEVEL=debug

Да не вопрос. Сейчас сделаю.

А пока что такой вопрос: пинг на хост 10.90.0.1 проходит. Есть ли какая то утилита чтобы конкретно на этот хоть отправить DNS запрос и посмотреть способен ли он ответить? Спрашиваю, потому что не силен в nslookup и не уверен что он именно на этот хост запрос отправляет.

Может там реально udp по какой то причине блочится, а я тут на systemd гоню.

Есть ли какая то утилита чтобы конкретно на этот хоть отправить DNS запрос и посмотреть способен ли он ответить?

nslookup server.corp.domain.net 10.90.0.1

В таких случаях нужно форсировать отправку запросов только через VPN.

Да, действительно. Так и есть.

nslookup host.domain.tld 10.90.0.1

Во. Точно.

$ nslookup server.corp.domain.net 10.90.0.1
;; connection timed out; no servers could be reached

Так. СТОП.

По ходу я что то перемудрил с конфигурацией. Если сделать nslookup на «реальный» адрес сервера, а именно 172.16.1.2, то ответ приходит.

$ nslookup io.corp.domain.net 172.16.1.2
Server:         172.16.1.2
Address:        172.16.1.2#53

Name:   io.corp.domain.net
Address: 172.16.1.101

Теперь вопрос, почему наш админ решил что IP DNS сервера должно быть в ранге адресов отдаваемых OpenVPN (10.90.xxx.yyy).

Поменяв конфиг в моем ccd файле на 172.16.1.2 DNS отлично работает.

Надо бы отметить что тема решена.

Потому что такая семантика адекватнее, чем историческая «рандомно выберем один сервер из resolv.conf».

Не надо придумывать какие-то левые семантики которых никогда не было. Семантика была - «рандомно выбираем один сервер из помещённых с дозволения пользователя в resolv.conf и никакой другой».

А вот то, чем занимается systemd - как раз совершенно неадекватно.

Поменяв конфиг в моем ccd файле на 172.16.1.2 DNS отлично работает.

Через resolved тоже?

Не надо придумывать какие-то левые семантики которых никогда не было

С чего бы это? Конечно, надо.

Семантика была - «рандомно выбираем один сервер из помещённых с дозволения пользователя в resolv.conf и никакой другой».

Это бестолковая семантика. Она не решает реальные пользовательские задачи. А systemd-resolved решает. Я достаточно подробно описал, как именно.

А вот то, чем занимается systemd - как раз совершенно неадекватно.

Разумное обоснование будет или как всегда?

Теперь ты приведи пример, почему такое поведение якобы плохо и неправильно.

Тебе уже привели примеры. Какие-то DNS могут выдавать правильные, годные ответы, а какие-то находятся, например, в РФ. А Поттерингу с его systemd-resolved на это совершенно насрать, и его поделка выдаст пользователю первый пришедший адрес, который, очевидно будет вовсе не от годного DNS, а от того, который тупо физически ближе, т.е. в РФ.

И да - это нынче, стараниями законотворцев в РФ и не только, совершенно стандартная пользовательская проблема.

Она не решает реальные пользовательские задачи.

Ты в курсе что пользовательская задача - это чтобы компьютер делал только то, что приказал пользователь, а не то, что придумал Поттеринг.

А systemd-resolved решает.

Лучше бы он вообще ничего не делал, чем решать так как он «решает».

в твоем случае рандомного выбора - будет тоже самое. Не надо всякий шлак писать в резолф.конф

Классический линуксовый DNS-ресолвер выберет из четырёх серверов один, отправит запрос на него и с вероятностью 50% я получу хер, потому что запрос о foonet.foo.ru уйдёт в сервер провайдера bar.

а какой-нибудь кеширующий днс-сервер тут разве не поможет?

ну у тебя и подгорает, офигеть, уже десяток лет!

Тебе уже привели примеры.

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

Во-вторых, «традиционная» семантика resolv.conf этот юзкейс тем более не решает.

Лучше бы он вообще ничего не делал, чем решать так как он «решает».

«плохо, потому что мне не нравится, а мне не нравится, потому что плохо»

Ну всё, началось. А я думал, что ты поумнел и способен к разумному разговору с аргументацией. Ладно, проехали, вопрос снят.

Через resolved тоже?

Ну видимо да. Я поменял IP в ccd файле на стороне сервера и все заработало.

а какой-нибудь кеширующий днс-сервер тут разве не поможет?

Поможет. Например, resolved :)

Не очень понял, что ты хочешь этим сказать.

в твоем случае рандомного выбора - будет тоже самое.

С какого перепугу, если я туда положу только годные DNS, а то что прислал провайдер пусть где-нибудь в /var/lib/dhcpcd полежит и не отсвечивает.

Не надо всякий шлак писать в резолф.конф

Не будет у вас resolv.conf скоро, не переживайте. Поттеринг за вас решит, каким DNS пользоваться.

Семантика была - «рандомно выбираем один сервер из помещённых с дозволения пользователя в resolv.conf и никакой другой».

Извините, но не могу с вами согласиться. А что если мне нужно не рандомно, а какой то конкретный сервер на определенный домен?

Я не настолько знаток системного программирования чтобы осуждать работу того же Поттеринга, но его поделие (каким бы плохим/хорошим оно не являлось) все таки решает эту задачу из коробки.

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

если я туда положу только годные DNS, а то что прислал провайдер пусть где-нибудь в /var/lib/dhcpcd полежит и не отсвечивает

А resolved выбирает адреса DNS-серверов из астрала, что ли? Если ты считаешь себя умнее автоматики, ну так и не передавай туда неправильные адреса (UseDomains=false), какие проблемы-то?

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

Ну задай метаданные для случая трёх интерфейсов, когда DNSами приехавшими на первый пользоваться можно только для .ru и то, только когда других интерфейсов нету, DNSами приехавшими на второй пользоваться только если нет третьего, а то, что ходит через DNSы третьего вообще никогда ни при каких условиях не должно попадать в DNSы перовго. И все эти интерфейсы могут в произвольном порядке и комбинациях появляться и исчезать.

Если ты считаешь себя умнее автоматики, ну так и не передавай туда неправильные адреса (UseDomains=false), какие проблемы-то?

Угу. А чтобы это делать динамически - надо невменяемые и толком нигде не документированые заклинания busctl в портянки на баше писать. Портянки на баше плохо, говорили они, декларативщина решит все проблемы, говорили они. Ага....

отправит запрос одновременно в обе
приведи пример, почему такое поведение якобы плохо и неправильно

Нарушение приватности. Если я пользуюсь DNS VPN сервера, на кой мне надо, чтобы он одновременно отправлялся на гугловский и провайдеровский?

Ты не заметил, что у тебя в процессе разговора слегка поменялись требования?

«Примеры, которые мне привели,» решаются заданием метаданных на интерфейсе. Твоя вот эта портянка — ну извините, отключаешь resolved, ставишь свой любимый скриптуемый stub resolver и скриптуешь.

Извините, но не могу с вами согласиться. А что если мне нужно не рандомно, а какой то конкретный сервер на определенный домен?

Вообще это элементарно делается посредством dnsmasq или даже bind можно поднять. Ну объясняешь своему собственному DNS форвардеру что спрашивать про этот домен можно только вон у того DNS и всё. А теперь вот это вот лезет и пихает запросы во все DNS подряд.

все таки решает эту задачу из коробки.

На самом деле он решает задачу тупенького хомячка, чтобы как угодно, где угодно добыть для него IP адрес для запрошенного домена.

толком нигде не документированые заклинания busctl

https://www.freedesktop.org/wiki/Software/systemd/resolved/

Портянки на баше плохо, говорили они, декларативщина решит все проблемы, говорили они.

Если ты не заметил, конфигурация resolved полностью декларативна. А как её туда отправить — вопрос второй, компьютеры всё-таки в конечном счёте императивны.

В третий раз отвечаю на один и тот же вопрос: это решается заданием правильных метаданных на интерфейсах.

Разве в resolv.conf рандомно выбирается? По моим наблюдением старается использовать первый в списке.

https://www.freedesktop.org/wiki/Software/systemd/resolved/

И где там про то, что если хочется снести DNS у интерфейса то в SetLinkDNS надо отправить нуль?

Если ты не заметил, конфигурация resolved полностью декларативна. А как её туда отправить — вопрос второй, компьютеры всё-таки в конечном счёте императивны.

Ну так если компьютеры императивны - зачем тогда эта прослойка в виде декларативщины, если всё равно для любого шага в сторону от линии партии надо имеративщину писать? Не, я ничего против среднестатистического хомячка не имею, их большинство, в конце-концов, но и хомячкам скоро понадобится чтобы DNS запросы не утекали.

И где там про то, что если хочется снести DNS у интерфейса то в SetLinkDNS надо отправить нуль?

А тебе обязательно нужна пошаговая инструкция для дебилов? Это документация на DBus API. Документация на синтаксис busctl в другом месте.

https://www.freedesktop.org/wiki/Software/systemd/resolved/:

The SetLinkDNS() method sets the DNS servers to use on a specific interface. <…> It takes a network interface index as well as an array of DNS server IP address records

https://www.freedesktop.org/software/systemd/man/busctl.html#Parameter%20Formatting:

For arrays, a numeric argument for the number of entries followed by the entries shall be specified.

Два и два предлагается сложить самому.

зачем тогда эта прослойка в виде декларативщины, если всё равно для любого шага в сторону от линии партии надо имеративщину писать?

Очевидно — чтобы её не приходилось писать, если шаг в сторону от линии партии не требуется.

И я не очень понимаю, на что конкретно ты сейчас жалуешься? Если ты настраиваешь сеть руками, тебе в любом случае нужно куда-то эти DNS-сервера положить: либо в resolv.conf, либо в дбас.

и хомячкам скоро понадобится чтобы DNS запросы не утекали

В чётвёртый раз: хомячку с его VPN автоматически прилетит push "dhcp-option DOMAIN .", а если нет, то хомячку достаточно нажать «Do not use DNS servers from this connection» в нужном окне.