Совместное использование сети контейнера VPN: что происходит с DNS

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

Шаг 1: Проверяйте из приложения, а не с хоста

Выполните поиск внутри контейнера, у которого проблема, а не на хосте и не в браузере. docker exec app-container getent hosts db.internal отвечает на единственный важный вопрос: что возвращает резолвер этого процесса.

Если хост разрешает имя, а контейнер нет, вы нашли неисправность. Всё дальнейшее — выбор поддерживаемого способа её исправить.

Шаг 2: Прочитайте поддерживаемую модель среды выполнения

Документация Docker по сетям фиксирует ограничения на флаги DNS для контейнеров, которые используют сетевой режим другого контейнера. В Compose network_mode: service:vpn привязывает приложение к пространству имён контейнера VPN, а для каждой службы dns настройки ведут себя не так, как в обычной службе. Решение, которое вы получаете, — это то, что есть у общего пространства имён.

Определяемые пользователем мостовые сети тоже используют встроенный DNS Docker иначе, чем мост по умолчанию. Поэтому dns блок, скопированный из рабочего примера моста, может вообще ничего не делать в общем стеке. Проверьте схему, прежде чем копировать блок.

Адрес петли всегда относится к соответствующему сетевому контексту. Внутри общего пространства имён 127.0.0.1 не является резолвером хоста.

Шаг 3: Проследите запрос до его получателя

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

Страница проверки IP в браузере не может сказать, куда ушли запросы имён. Она говорит, куда ушло одно HTTP-соединение.

Шаг 4: Исправляйте два класса сбоев по-разному

Если имена служб не работают, а публичные имена работают, проблема в обнаружении служб внутри сети контейнеров, а не в списке публичных резолверов. Изменение каждого публичного адреса DNS не создаст записи, о которых механизм обнаружения сети никогда не просили.

Если сбоят оба класса, начните с доступности резолвера. Если сбоит только один, начните с механизма обнаружения. У них разные владельцы, поэтому одно исправление никогда не покрывает оба.

Шаг 5: Повторно проверьте после пересоздания

Измените конфигурацию через поддерживаемый механизм среды выполнения, затем пересоздайте контейнеры, а не редактируйте файлы внутри работающего. Проверьте новое частное имя, новое публичное имя и запрос приложения, следующий за поиском. Изменение в /etc/resolv.conf внутри контейнера исчезает при пересоздании и убедит вас, что исправление сработало, когда оно не сработало.

Запишите владельца резолвера и ожидаемое пространство имён рядом с определением общей сети. Следующему человеку понадобится и то и другое.