LINUX.ORG.RU
ФорумTalks

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

 , , , ,


0

4

Уже на протяжении полутора лет NetworkManager в Ubuntu, при использовании OpenVPN-подключения, отправляет DNS-запросы напрямую (через DNS-сервер, адрес которого получен по DHCP), а не через VPN-туннель. Чаще всего, это DNS-сервер провайдера.

Это достаточно серьёзное нарушение безопасности, позволяющее интернет-провайдеру видеть и собирать информацию о посещённых сайтах.

К сожалению, баг (которому присвоен высокий приоритет) не исправлен на протяжении уже полутора лет.

Судя по сообщениям пользователей, проблема сохранилась и в Ubuntu 18.04.

В качестве обходного пути пользователям приходится понижать версию NetworkManager до 1.2.2.

anonymous

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

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

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

anonymous ()

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

Vsevolod-linuxoid ★★★★★ ()

Должен быть исправлено в 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

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

Mixail ()
Последнее исправление: Mixail (всего исправлений: 3)

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

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

intelfx ★★★★★ ()
Ответ на: комментарий от Vsevolod-linuxoid

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

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

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

intelfx ★★★★★ ()
Ответ на: комментарий от anonymous

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

grim ★★★☆ ()
Ответ на: комментарий от intelfx

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

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

Meyer ★★★★★ ()
Ответ на: комментарий от Meyer

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

Дано: 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 про них ничего не знает.

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

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

Stanson ★★★★★ ()
Ответ на: комментарий от Stanson

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

Да, про них.

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от Mixail

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

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

dikiy ★★☆☆☆ ()
Ответ на: комментарий от intelfx

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

Stanson ★★★★★ ()
Последнее исправление: Stanson (всего исправлений: 2)
Ответ на: комментарий от anonymous

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

Deleted ()
Ответ на: комментарий от intelfx

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

baka-kun ★★★★★ ()
Ответ на: комментарий от Stanson

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

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

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

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

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

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

intelfx ★★★★★ ()
Ответ на: комментарий от baka-kun

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

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

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

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

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

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

Ну... да? 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…”

baka-kun ★★★★★ ()
Ответ на: комментарий от baka-kun

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

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

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

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

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

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

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

Ты невнимательно читаешь. 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.

baka-kun ★★★★★ ()
Последнее исправление: baka-kun (всего исправлений: 1)

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

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

Deleted ()
Ответ на: комментарий от intelfx

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

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

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

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

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

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

Stanson ★★★★★ ()
Последнее исправление: Stanson (всего исправлений: 2)
Ответ на: комментарий от intelfx

В 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

ValdikSS ★★★★★ ()
Ответ на: комментарий от ValdikSS

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

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

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

:)

intelfx ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.