NetworkManager в Ubuntu допускает утечку DNS-трафика

Не новость, но факт. Может на форум перенести. И не 1.5 года, а лет 5 как минимум на всех версиях Ubuntu/Debian, которые приходилось юзать. Что через консоль OpenVPN, что через NM - есть утечка DNS.

Лечится покупкой нормального ВПН'а со своим собственным клиентом под Linux, например, ProtonVPN. ;)

Баг кстати подтвердил еще в том году, но смотрю нихрена не сделано, супер.

Помимо понижения версии NetworkManager можно его попросту не использовать — есть и другие варианты настройки сети.

Должен быть исправлено в 18.10 (nm 1.12)

Также исправлено в апстриме nm 1.10.14 ( https://github.com/NetworkManager/NetworkManager/pull/235 )

Задача с бэкпортом в bionic: https://bugs.launchpad.net/ubuntu/bionic/ source/network-manager/ bug/1754671

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

Внимание, вопрос: каким образом вообще «NM может отправлять DNS-запросы»? И тем более каким образом NM может выбирать, через какой интерфейс их отправлять?

Я что-то пропустил и NM обзавёлся собственной реализацией DNS-ресолвера и вообще всего стека TCP/IP?

Помимо понижения версии NetworkManager можно его попросту не использовать — есть и другие варианты настройки сети

«Диды пускали wpa_supplicant и dhcpcd руками и мы тоже будем»? Смешно, чесслово.

Тем временем комбинация NetworkManager и systemd-resolved — единственный в GNU/Linux на конец 2018 года способ корректно работать с DNS-серверами внутри VPN, обслуживающими (только) домены в интранете.

Кстати, были исследования, большинство VPN провайдеров принадлежит Китаю ;)

комбинация NetworkManager и systemd-resolved — единственный в GNU/Linux на конец 2018 года способ корректно работать с DNS-серверами внутри VPN, обслуживающими (только) домены в интранете.

А мужики-то и не знали.

Предлагайте ваши предложения.

Дано: DNS-сервер 1.1.1.1 прилетает по DHCP, DNS-сервер 10.10.10.10 прилетает как push "dhcp-option DNS 10.10.10.10" по OpenVPN. DNS-сервер 10.10.10.10 отвечает только на {foo,bar}.company.tld, DNS-сервер 1.1.1.1 про них ничего не знает.

Найти: чтобы работало. Автоматически.

Тем временем комбинация NetworkManager и systemd-resolved — единственный в GNU/Linux на конец 2018 года способ корректно работать с DNS-серверами внутри VPN, обслуживающими (только) домены в интранете.

Чо вот ща за бред такой я только что прочитал ваще? Или это чисто про тупых вендузятников, неспособных dnsmasq какой себе настроить? Ты б когда такие прогоны постишь, уточнял бы, о какой аудитории речь, а то можно дураком навечно прослыть.

server=/company.tld/10.10.10.10 в dnsmasq.conf

Или это чисто про тупых вендузятников, неспособных dnsmasq какой себе настроить?

Да, про них.

Про 1% от 1% речь не идёт, уж извини. Элитаризм свой можешь в жопу себе засунуть.

Автоматически

Особенно без фактчекинга

убил бы Розенталем блеать

man openvpn на предмет up и down скриптов.

С каких пор элементарные знания о том как устроена и работает используемая тобой система являются элитаризмом и почему его надо совать в жопу? Это типа современный дискурс такой? «О, эти яйцеголовые сделали себе систему, давайте туда всей вендузятной кодлой залезем и насрём везде, чтобы не умничали, сцуки, а то ишь...».

Что в Debian, что в Ubuntu, что в $твой_любимый_дистрибутивчик openvpn комплектуется парой скриптов, который правят resolv.conf при установке/разрыве VPN-соединения. Если твой конфиг корявый, то это никак не является чей-либо проблемой.

комбинация NetworkManager и systemd-resolved — единственный в GNU/Linux на конец 2018 года способ корректно работать с DNS-серверами внутри VPN

https://github.com/systemd/systemd/issues/6076

not-our-bug

Не вчитывался, что там произошло, но УМВР.

not-our-bug

Да кто-бы спорил. «Это не наша проблема, кто-то должен сказать systemd-resolved, через какие интерфейсы какие домены ресолвить». Кто-то должен сделать

busctl call org.freedesktop.resolve1 /org/freedesktop/resolve1 \
org.freedesktop.resolve1.Manager SetLinkDomains <iface-number> <domain>

И, конечно, кто-то должен озаботиться тем, чтобы вместе с добавлением домена на интерфейс VPN снять DNS Domain: ~. с интерфейса провайдера, иначе systemd будет обращаться к обоим DNS, допуская утечку.

А уж если VPN начнет просто сбоить, и потеряет парочку UDP DNS ответов, от утечки уже ничто не спасет, поскольку https://github.com/systemd/systemd/issues/5755

Лечат большинство по старинке:

• Изменить NetworkManager.conf
  dns=dnsmasq rc-manager=resolvconf
• sudo systemctl disable systemd-resolved
• sudo systemctl stop systemd-resolved
• sudo systemctl restart NetworkManager

УМВР

А что говорит https://www.dnsleaktest.com/ ?

С каких пор элементарные знания о том как устроена и работает используемая тобой система являются элитаризмом и почему его надо совать в жопу?

Знания элитаризмом не являются. А вот предложение отказываться от удобных средств автоматизации того, что автоматизируется, и делать работу машины за неё — является.

Это типа современный дискурс такой? «О, эти яйцеголовые сделали себе систему, давайте туда всей вендузятной кодлой залезем и насрём везде, чтобы не умничали, сцуки, а то ишь...».

Ну как я и сказал — элитаризм. «Диды писали скрипты на каждый чих и мы будем».

man openvpn на предмет up и down скриптов.

Зачем ты мне тычешь маном? Я эти маны помню лучше тебя.

И, конечно, кто-то должен озаботиться тем, чтобы вместе с добавлением домена на интерфейс VPN снять DNS Domain: ~. с интерфейса провайдера, иначе systemd будет обращаться к обоим DNS, допуская утечку.

Ну... да? libastral ещё не изобрели, или я что-то упустил в этой жизни?

Лечат большинство по старинке

Странно, но каждый раз, когда я вижу бубунту, мне приходится «лечить» глюкавость прослойки NM-dnsmasq строго обратным рецептом.

А что говорит https://www.dnsleaktest.com/ ?

Всё в порядке.

Ну... да? libastral ещё не изобрели, или я что-то упустил в этой жизни?

Не изобрели. Просто раньше всё как-то работало через resolv.conf, но это же NIH, нужно всем срочно переделать софт и звать D-Bus. Вот и рождаются монструозности с вызовом скриптов и сбросом кешей.

А самое смешное, это до первых проблем на VPN канале, после которых systemd-resolved начинает снова использовать удобные ему, а не админу DNS.

Собственно, Поттеринг так и пишет:

“However, in contrast to classic nss-dns we have memory: when we noticed that a DNS server didn't respond or for some other reason wasn't working for us, and we skip to the next, then we remember that and the next lookup is attempted with the new one.

If you want to route lookups in specific zones to specific DNS servers, then resolved doesn't really offer a nice way for that”

Всё в порядке.

Я раз за твоё УМВР.

Но люди продолжают жаловаться, что в правильно сконфигурированной системе начинают утекать DNS запросы, которые должны были бы идти в VPN, а им снова объясняют:

“DNS server didn't respond to our query with transaction ID 29131. Why it didn't respond isn't known: somehow no UDP response packet was received. Either way, resolved will retry but use a different DNS server, in the hope that works better.”

И приплыли. Вывод: “falling back to ISP’s DNS server once a custom one ‘stopped working’ is bad and probably unwanted in most cases… So sometimes my connection breaks and systemd-resolved switches to ISP’s DNS, which is very annoying.”

“As Poettering does not give the impression that they will change it or allow customization, the only way to get around it, is to de-install systemd-resolved. A pitty…”

Не изобрели. Просто раньше всё как-то работало через resolv.conf

Повторяю: покажи мне, как ты «через resolv.conf» сделаешь вот это.

В общем, не работало оно «через resolv.conf». Через dnsmasq — может быть, но интеграция NM-dnsmasq, когда я на неё смотрел, была сломана. А потом появился systemd-resolved и всё заработало.

<куча баттхёрта поскипана>

По-моему, налицо прищемление яиц дверью.

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

Люди дебилы. В правильно сконфигурированной системе ничего никуда не утекает. Ты уже упомянул крутилки SetLinkDomains — так вот, они там не просто так, я повторяю, libastral ещё не изобрели. Если их сетевой менеджер конфигурирует resolved неправильно, им нужно добиваться изменения поведения сетевого менеджера, а не жаловаться в багтрекер systemd, просто потому что во всём виноват systemd.

Повторяю: покажи мне…

Ты невнимательно читаешь. dns=dnsmasq rc-manager=resolvconf

Вообще resolvconf умеет работать с dnsmasq, named, pdnsd и unbound. Твои хотелки уже давно реализованы и работают, но это же NIH, systemd принципиально не хочет использовать готовые решения. Нужно ведь переизобретать велосипед, вынуждая всех переписывать код и использовать D-Bus.

<куча баттхёрта поскипана>

Это ты про цитату из Поттеринга? “If you want to route lookups in specific zones to specific DNS servers, then resolved doesn't really offer a nice way for that”.

Если их сетевой менеджер конфигурирует resolved неправильно

Он настраивает правильно, все костыли уже написали. Не его вина, что resolved так спроектирован, что когда теряет ответ от серверов в VPN, начинает использовать другие. Да ещё и запоминает из как предпочитаемые. Но это «не проблема resolved», not-our-bug, ага. Загляни в код /src/resolve/resolved-dns-*. Он так написан, что когда DNS в VPN не отвечают, начинает перебирать остальные интерфейсы. Речь в частности и о твоем случае, когда VPN должен обслуживать только корпоративные домены, то есть DNS Domain: ~. висит на интерфейсе ISP, а в VPN только company.tld.

Стоило ожидать. В местах, где vpn для блокировок актуален, получение DNS по DHCP вообще стоит отключать.

Помню, еще была тема про MAC-адреса на wifi интерфейсе. Что, якобы, в NM была встроена фича, позволяющая избежать трекинга девайса через разные wifi сети, которая заменяет реальный мак рандомным для разных сетей. Вот это, похоже, тоже не работает.

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

Неконтролируемая автоматизация - это полный звездец.

Ну как я и сказал — элитаризм. «Диды писали скрипты на каждый чих и мы будем».

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

Зачем ты мне тычешь маном? Я эти маны помню лучше тебя.

Ну тогда не предлагал бы людям, которые не хотят утечек DNS связку NM+systemd-resolved, да и вообще systemd-resolved в любом виде для этого, и не называл бы это единственным решением. Оно ж написано не как надо, а чтоб как-нибудь работало, даже когда этого делать категорически нельзя. Это, видимо, неизлечимая болезнь системды такая. Та же самая херня, что и с автоматическими перезапусками упавших демонов - лишь бы как-нибудь, пусть через жопу, но чтобы шевелилось, даже если это недопустимо.

В Ubuntu NetworkManager используется в связке с dnsmasq: в /etc/resolv.conf прописано 127.0.0.53, dnsmasq запущен и слушает 127.0.0.53, а NetworkManager ему по dbus новые DNS-серверы сообщает, при новых подключениях. Для OpenVPN-подключений что-то идёт не так, и настройки DNS не применяются. Если отключить поддержку dnsmasq в NetworkManager, то всё работает корректно.

Баг очень старый, ему не менее 5 лет: https://bugs.launchpad.net/ubuntu/ source/network-manager-openvpn/ bug/1169437

Это была претензия к терминологии.

А теперь расскажи это господам выше, а то они не верят, что

Тем временем комбинация NetworkManager и systemd-resolved — единственный в GNU/Linux на конец 2018 года способ корректно работать с DNS-серверами внутри VPN, обслуживающими (только) домены в интранете.

:)