ip netns exec и DNS: почему имена не работают внутри пространства имён

Команда доходит до 10.8.0.5 внутри пространства имён VPN без единой жалобы, а та же команда отказывает в тот момент, когда использует имя хоста. У пространства имён есть свои интерфейсы, маршруты и сокеты; своего файла распознавателя у него нет. Если что-то не положит один туда, процесс внутри читает /etc/resolv.conf хоста и спрашивает сервер, который может быть недоступен из этого сетевого стека.

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

Проверьте представление распознавателя, которое процесс действительно получает

Не предполагайте, что использованная оболочка эквивалентна процессу, который вы отлаживаете. Графическое приложение, юнит systemd и контейнер могут каждый войти в иной контекст монтирования или сети. Выполните запрос тем же путём запуска и напечатайте файл распознавателя изнутри.

Для пространства имён, созданного с помощью ip netns add, проверка только на чтение коротка:

ip netns exec vpn cat /etc/resolv.conf

Обратите внимание, называет ли результат доступный адрес, заглушку loopback или символьную ссылку, указывающую в место с другой доступностью.

Что на самом деле монтирует помощник exec

Инструмент ip-netns документирует конфигурацию для каждого пространства имён в /etc/netns/NAME/. Когда он запускает процесс, помощник создаёт пространство имён монтирования и монтирует эти файлы поверх их обычных путей, поэтому процесс видит копию, специфичную для пространства имён. Это удобство именно этого запускающего средства. Вход в сетевое пространство имён другим путём, например через unshare или среду выполнения контейнеров, не воспроизводит это автоматически.

Здесь ловушка — распознаватель на loopback: 127.0.0.53 означает собственный loopback пространства имён, а не заглушку хоста. Заглушка, слушающая только в пространстве имён хоста, не становится службой в новом.

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

Какой бы сервер ни называл файл, ему всё ещё нужен маршрут из этого пространства имён. Публичный распознаватель может отвечать на публичные имена и всё равно отказывать для внутренней зоны, потому что частная служба доступна только через туннель. Проверяйте маршрут одновременно с адресом, а не после того, как запрос уже отказал.

Приложения со своим распознавателем, например использующее DNS over HTTPS, могут полностью игнорировать файл. Если у инструмента есть собственная настройка DNS, изменение resolv.conf на неё не повлияет, и пространство имён никогда не было проблемой.

Запишите файл в правильное место

Создайте файл для пространства имён в /etc/netns/NAME/resolv.conf и позвольте запускающему средству его представить. Держите его минимальным: один или два доступных сервера и домены поиска, нужные задаче. Не редактируйте сгенерированный файл распознавателя хоста, чтобы исправить представление, предназначенное для одной группы процессов, потому что это меняет каждое приложение на машине. Если хост использует менеджер распознавателя, настройте путь пространства имён через этот менеджер, а не боритесь с ним.

Запишите содержимое файла в runbook. Иначе следующий человек проверит распознаватель хоста, увидит работающий ответ и заключит, что пространство имён в порядке.

Проверьте весь путь заново

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

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