Почему ваша запись в /etc/hosts не доходит до DNS VPN

Вы добавили имя в /etc/hosts, подключились к VPN и ожидали, что запись появится у всех. Этого не происходит, и удивление обычно приходит со вторым симптомом: имя разрешается на вашей машине и не разрешается у коллеги, что выглядит как сломанная служба DNS VPN, а на самом деле файл hosts делает ровно то, для чего он создан. Файл hosts — это локальная конфигурация разрешения имён, а не обновление зоны, и ничто в обычном подключении VPN его не выгружает.

Hosts — это локальное переопределение, а не обновление зоны

Файл — это список сопоставлений, к которым библиотеки службы имён обращаются до запроса к DNS-серверу или вместо него. Строка вроде 10.40.0.20 build.corp.example меняет то, к чему приходят приложения на этой одной машине. Она не создаёт запись, не проходит через туннель, и DNS-сервер, на который указывает туннель, понятия не имеет о её существовании.

Поэтому сбой асимметричен. Ваш клиент получает ответ из файла. Другой клиент спрашивает DNS-сервер VPN, который ничего не возвращает, и приложение сообщает, что имени не существует. Обе машины ведут себя правильно; лишь у одной есть переопределение, которого другая никогда не видела.

Две команды, два разных компонента

Самый быстрый способ прекратить спор — сделать разницу видимой в двух командах, обе выполняются на клиенте, где есть запись hosts:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

Первая спрашивает собственный путь поиска системы, который в типичной системе glibc читает локальные файлы до DNS. Вторая отправляет DNS-запрос напрямую серверу по этому адресу и вообще не обращается к локальным файлам. Когда первая возвращает вашу запись, а вторая возвращает NXDOMAIN, вы доказали, что записи нет в DNS и что ваша машина отвечает из локального переопределения.

Порядок настраивается, и его стоит проверить, прежде чем делать какие-либо выводы о конкретном дистрибутиве. Посмотрите на строку hosts: в /etc/nsswitch.conf; hosts: files dns сначала обращается к файлам. Не копируйте этот пример на работающую конфигурацию только ради смены порядка, потому что реальные системы часто перечисляют дополнительные источники и условные записи служб, которых в примере нет.

systemd-resolved размывает тест

В системе с systemd-resolved локальный stub также обслуживает имена из базы hosts. Поэтому запрос к 127.0.0.53 не является независимым тестом удалённого сервера, хотя выглядит как DNS-запрос и ведёт себя так же. Что знает резолвер и к каким серверам он обратился бы, можно проверить так:

resolvectl query build.corp.example
resolvectl status

Вывод status называет DNS-серверы для каждого соединения, и так вы узнаёте, получило ли соединение VPN вообще резолвер. Этот вопрос отдельный от записи hosts, и именно его стоит задавать, когда частное имя не разрешается у всех пользователей, а не у одного.

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

Что на самом деле разделяет имя через VPN

Если частное имя должно работать для всех, ему нужен владелец, до которого дотянется резолвер каждого. Чистый ответ — опубликовать запись в управляемой зоне и сделать эту зону разрешаемой по предусмотренному пути DNS в VPN. Тогда у записи есть один источник истины, аудиторский след и жизненный цикл, и никому не нужно помнить, на каком ноутбуке есть локальное переопределение.

Распространение файлов hosts — законная альтернатива, и это управление конечными точками, а не служба имён. Если вы выберете его, файл должен развёртываться, версионироваться и удаляться тем, что управляет парком, и именно так это должно быть описано в проекте. «VPN этим занимается» — не описание этого процесса.

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

Разрешённое имя — не маршрут

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

Поэтому когда в отчёте сказано «имя разрешается, но служба недоступна», сравните системный поиск с явным запросом к DNS-серверу VPN, а затем проверьте полученный адрес с тем, который служба действительно использует. Справочник systemd-resolved документирует локальные источники, к которым он обращается, и это та карта, которая нужна для такого сравнения.

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