Утечки DNS с использованием сетевых пространств имен

Вопрос или проблема

Я использую Ubuntu 22.04.

Я пытаюсь запустить клиент WireGuard VPN внутри сетевого пространства имен.

Я могу подключиться к VPN и перенаправлять соединения, но у меня возникают утечки DNS.

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

systemctl disable --now systemd-resolved.services
systemctl disable --now NetworkManager

и аналогично для службы сетевого менеджера. Таким образом, в теории, на этом этапе у меня нет ничего, что бы управляло resolv.conf.

После этого я создаю файл /etc/netns//resolv.conf только с одной строкой ‘nameserver’.

Затем я создаю устройство WireGuard в начальном сетевом пространстве имен и перемещаю его в вновь созданное пространство имен (и я проверил, что /etc/resolv.conf правильно связывается с DNS, который я ему предоставил).

Затем я настраиваю устройство WireGuard, и я могу устанавливать соединения, и также, когда я выполняю nslookup wikipedia.org, я вижу, что используется правильный DNS, тот, который от провайдера VPN.

Проблема в том, что когда я открываю браузер в этом пространстве имен и перехожу на https://www.dnsleaktest.com/, я могу увидеть DNS моего провайдера. Но общий трафик проходит через туннель VPN.

Кто-нибудь знает, почему эта конфигурация не работает после отключения systemd-resolved и сетевого менеджера? Я думал, что это не работает из-за какого-то управления, которое они осуществляли, но даже после деактивации я не знаю, почему все еще используется неправильный DNS. Что еще может быть причиной того, что привязка resolv.conf не работает так, как я ожидал?

Ответ: Это происходило потому, что работал nscd. Отключение его решило проблему.

  1. Убедитесь, что весь ваш браузер работает внутри этого сетевого пространства имен. Большинство крупных браузеров являются программами “одиночного экземпляра”; запуск chrome https://foo просто подключится к уже работающему экземпляру и попросит его открыть этот URL.

  2. Glibc имеет дополнительный уровень абстракции над DNS: интерфейс ‘системы переключения имен’, настраиваемый через /etc/nsswitch.conf, который может загружать разные модули для поиска имен хостов. (Например, у него есть модуль libnss_resolve, который общается с systemd-resolved более напрямую, чем “DNS на 127.0.0.53”.) Убедитесь, что у него не включено что-то неожиданное.

    Используйте getent (или socket.getaddrinfo() из Python или других языков) для тестирования этого:

    getent hosts example.com
    getent -s dns hosts example.com
    getent -s $module hosts example.com
    
  3. Кроме того, Glibc также имеет своего собственного “демона кэширования имен”, nscd (или иногда unscd). Большинство дистрибутивов больше не используют его, но если он работает, программы будут обращаться к нему через сокет Unix в /run – что игнорирует сетевые пространства имен – и демон кэширования, конечно, будет использовать resolv.conf из своего собственного (т.е. начального) сетевого пространства имен, что приведет к той же проблеме, что и с systemd-resolved.

Ответ или решение

Проблема утечек DNS при использовании пространств сетей в Ubuntu 22.04

При работе с WireGuard VPN в пространстве сетей на Ubuntu 22.04 часто возникает проблема утечек DNS. Несмотря на то, что трафик корректно проходит через VPN, DNS-запросы могут идти через DNS-серверы вашего интернет-провайдера, что нарушает целостность конфиденциальности. Давайте подробно рассмотрим, как можно устранить эту проблему.

Включение пространств сетей и некорректное управление DNS

Вы правильно отметили, что после отключения systemd-resolved и NetworkManager необходимо самостоятельно управлять resolv.conf. Однако, даже после этого, вы столкнулись с утечками DNS. Распознавание правильного DNS-сервера в терминале (nslookup) не означает, что браузер использует этот сервер для DNS-запросов.

Основные причины утечек DNS

  1. Работа браузера вне пространства сетей:
    Большинство современных браузеров, таких как Chrome и Firefox, не создают отдельные процессы для каждого экземпляра. Если браузер запущен в одном пространстве, а сам процесс работает в другом, это может привести к утечкам. Убедитесь, что весь процесс браузера запущен внутри вашего пространства сетей.

  2. Механизм переключения служб (nsswitch.conf):
    Glibc имеет абстракцию над DNS, которая управляется через файл /etc/nsswitch.conf. Этот файл определяет, как система выполняет запросы DNS. Нужно убедиться, что там нет настроек, которые могут использовать другие механизмы разрешения имен, которые могут игнорировать ваш resolv.conf. Используйте команды типа getent, чтобы протестировать различные модули.

    getent hosts example.com
    getent -s dns hosts example.com
    getent -s <ваш_модуль> hosts example.com
  3. Запуск nscd:
    Daemon nscd (Name Service Caching Daemon) может кэшировать DNS-запросы и взаимодействовать через сокет Unix, что также игнорирует пространства сетей. Это приводит к проблемам с разрешением имен. Проверьте, запущен ли этот демон:

    systemctl status nscd

    Если он активен, отключите его:

    systemctl disable --now nscd

Рекомендации по устранению утечек DNS

  1. Создание отдельного пространства сетей: Не забудьте создать и настроить свое пространство сетей, а также убедиться, что ваше WireGuard соединение работает именно там, где вы это ожидаете.

  2. Проверка DNS-запросов: После отключения nscd и управления resolv.conf, проверьте, какие DNS-серверы используются с помощью команды dig или nslookup.

  3. Используйте iptables: С помощью этого инструмента можно настроить правила для блокировки DNS-трафика, который уходит не через VPN, тем самым обеспечивая дополнительный уровень защиты.

  4. Тестирование: Для проверки утечек DNS можно использовать сервисы, такие как dnsleaktest.com, чтобы удостовериться, что ваш DNS-запрос проходить через VPN.

Заключение

Подводя итог, утечки DNS при использовании WireGuard VPN в Ubuntu 22.04 в пространствах сетей могут быть решены благодаря отключению ненужных служб, правильной настройке nsswitch.conf и контроля DNS-запросов через службы кэширования. Эта работа требует внимательности к деталям, поскольку даже незначительная настройка может повлиять на безопасность и конфиденциальность ваших данных.

Оцените материал
Добавить комментарий

Капча загружается...