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

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

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

Для настройки 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.