Pull to refresh

Дружим Docker и dnscrypt-proxy

*nixVirtualization
Tutorial

DNSCrypt — довольно популярный вариант защиты обычно не шифруемого DNS-трафика от внешних лиц. Клиентский резолвер dnscrypt-proxy поддерживает в том числе протокол DNS-over-HTTPS, позволяя разрешать доменные имена через DoH.


Все бы ничего, только при использовании dnscrypt-proxy с настройками по умолчанию контейнеры Docker перестают корректно резолвить адреса. Исправим это, не включая слушатель DNS на публичных интерфейсах.


TL;DR поста
  1. Создаем dummy-адаптер, вешаем ему IP из частного диапазона.
  2. Заставляем dnscrypt-proxy слушать на этом IP, меняем настройки DNS соответственно.
  3. PROFIT

Суть проблемы


Для настройки DNS Docker копирует настройки DNS с хоста, копируя файл /etc/resolv.conf с хостовой машины.


При использовании dnscrypt-proxy и других кастомных резолверов обычно их запускают на 127.0.0.1:53, записывая этот адрес как nameserver в resolv.conf, эта же настройка приходит контейнеру. Так как контейнер находится в другом сетевом пространстве имен, 127.0.0.1 у хоста и контейнера разные.


Как исправить


Самым простым вариантом решения является запуск dnscrypt-proxy на публичном адресе хоста и добавление этого же адреса в /etc/resolv.conf. Однако в таком случае мы выставляем в сеть DNS-резолвер, чего хочется избежать.


Вместо этого мы создадим сетевой адаптер-затычку, через который не идет трафик, но на который можно повесить IP-адрес из частного диапазона; он будет роутабелен из контейнера, поскольку Docker-контейнеры с сетью через бридж используют в качестве шлюза по умолчанию хост. В Linux такой адаптер называется dummy.


Создаем адаптер


Если в вашей системе не загружен модуль ядра dummy (lsmod | grep dummy не показывает этот модуль), загрузите его и включите его загрузку на постоянной основе:


# modprobe dummy
# echo "dummy" >> /etc/modules-load.d/net_dummy.conf

Для того, чтобы создать и настроить dummy-адаптер, в современной Linux-системе с iproute2 достаточно выполнить две следующие команды:


# ip link add type dummy name dummy0
# ip addr add dev dummy0 10.0.197.1/24

Создание адаптера для его использования на постоянной основе будет разниться в зависимости от используемого вами сетевого конфигуратора. Например, для systemd-networkd понадобятся два конфигурационных файла:


/etc/systemd/network/50-dummy0.netdev:


[NetDev]
Name=dummy0
Kind=dummy
Description=Dummy network for dnscrypt-proxy

/etc/systemd/network/50-dummy0.network:


[Match]
Name=dummy0

[Network]
DHCP=no
Address=10.0.197.1/24
DefaultRouteOnDevice=false

Изменяем настройки DNS


Для того, чтобы заставить dnscrypt-proxy слушать на новом адресе, потребуется отредактировать /etc/dnscrypt-proxy/dnscrypt-proxy.toml. Отредактируем директиву listen_addresses и приведем ее к следующему виду:


listen_addresses = ['127.0.0.1:53', '[::1]:53', '10.0.197.1:53']

Перезапустим dnscrypt-proxy, после чего в /etc/resolv.conf (либо где в вашем сетевом конфигураторе находятся настройки DNS) оставим в списке серверов имен один: nameserver 10.0.197.1.


Проверяем


Запускаем контейнер:


% docker run -it --rm alpine:3.12
# cat /etc/resolv.conf
nameserver 10.0.197.1
# ping -c 1 ya.ru

Дополнительно


Если вы используете файрволл, разрешите входящий трафик на 10.0.197.1:53 из подсетей, из которых Docker выдает адреса контейнерам.


В случае, если вы используете в качестве локального резолвера systemd-resolved, направленный на dnscrypt-proxy (например, для кэширования или для использования разных DNS-серверов для разных интерфейсов), тот факт, что systemd-resolved слушает исключительно на 127.0.0.53 и не позволяет изменение этого адреса, вас смущать не должен: Docker определяет использование systemd-resolved и вместо содержимого /etc/resolv.conf копирует содержимое /run/systemd/resolve/resolv.conf, генерируемое из настроек systemd-resolved.

Tags:dockerdnscrypt-proxylinux
Hubs: *nix Virtualization
Total votes 3: ↑3 and ↓0+3
Views1.7K

Popular right now