Монтирование CIFS через VPN срывается из-за порядка в nsswitch

Ресурс отвечает по адресу и зависает по имени, поэтому поиск умирает ещё до старта SMB. Сравните getent с host, а затем прочитайте строку hosts по порядку.

Туннель поднят. Файловый сервер отвечает на ping по адресу. Затем mount.cifs с именем хоста висит некоторое время и сообщает, что хост недоступен, и вы начинаете пересобирать профиль VPN, который никогда не был проблемой. В Linux имя разрешается glibc ещё до появления любого пакета SMB, и порядок в этом резолвере может завершить поиск раньше, чем DNS вообще будет спрошен. Вот путь, которым я иду, начиная с команды, которая не сработала, а не с клиента.

Читайте ошибку в правильном месте

Два инструмента идут разными путями к одному имени, и сравнение стоит одной команды. getent проходит по настроенному стеку служб имён; host и dig спрашивают DNS напрямую и игнорируют этот стек. Если прямой запрос возвращает адрес, а getent — ничего, DNS-сервер доступен, и виновата ваша конфигурация резолвера.

getent hosts fileserver.corp.example
host fileserver.corp.example 10.61.0.1
getent -s dns hosts fileserver.corp.example

Третья команда — решающая: она принудительно выбирает источник DNS и пропускает остаток стека. Когда она работает, а обычный getent нет, вы доказали, что виноват порядок, а не туннель и не сервер.

Строка hosts — это последовательность, которая останавливается рано

Резолвер glibc читает /etc/nsswitch.conf и проходит запись hosts: слева направо. Многие дистрибутивы поставляют строку, в которой multicast-поиск идёт первым с прикреплённым действием раннего возврата. Это действие не украшение: когда mDNS отвечает “not found”, [NOTFOUND=return] завершает весь поиск, поэтому корпоративное имя никогда не отправляется резолверу, который навязал VPN. Ничто это не логирует, потому что не было отправлено ни одного запроса, который резолвер мог бы отклонить. Поэтому монтирование выглядит зависшим, а затем сообщает о недоступном хосте.

cat /etc/nsswitch.conf | grep '^hosts:'
# illustrative repair: dns before the early-return action
hosts: files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4

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

Резолвер — это не домен поиска

Для разрешения нужно ещё, чтобы имя было опробовано. Неквалифицированное имя вроде fileserver становится fileserver.corp.example только когда к интерфейсу, несущему запрос, привязан домен поиска. VPN, навязывающий DNS-сервер без списка поиска, даёт очень специфическое разделение: полное имя разрешается, а каждое короткое имя терпит неудачу.

Проверьте обе формы перед правкой профиля, потому что две ошибки указывают в разные стороны. На хосте с systemd-resolved у туннельного линка свои серверы и домены маршрутизации, поэтому читайте линк, а не глобальный файл.

resolvectl status
resolvectl query fileserver.corp.example
resolvectl dns
resolvectl domain

Если запрос приписан линку, который не несёт туннель, домен маршрутизации отсутствует, хотя адрес DNS есть. Это проблема политики в конфигурации resolved, а не проблема маршрутизации в туннеле.

Контейнеры несут свою копию ответа

Контейнер, собранный из общего образа, обычно поставляет фиксированный resolv.conf. Изменения резолвера на хосте до него не доходят, как и домен поиска, поэтому задача сборки, которая монтирует ресурс через туннель, срывается, а та же команда вне контейнера работает. Дайте контейнеру собственные настройки DNS и поиска в compose-файле или в аргументах run, а не только в профиле хоста.

Проверьте внутри контейнера, прежде чем винить образ. Две команды воспроизводят всю диагностику за несколько секунд, а вторая доказывает, какой резолвер на самом деле ответил.

Только потом смотрите на ресурс и фильтр

Когда имя разрешается, оставшиеся сбои — обычные сетевые проблемы. SMB нужен TCP 445 до сервера, а просмотр списка рабочей группы зависит от служб имён, которые туннель, вероятно, не пересылает. Подключайтесь по имени хоста вместо ожидания заполнения списка и позвольте клиенту сказать, на каком этапе он остановился. Отказ в соединении и тихий timeout тоже стоит разделять: первый обычно означает, что кто-то ответил, а второй — что никто.

getent hosts fileserver.corp.example
nc -vz fileserver.corp.example 445
mount -t cifs //fileserver.corp.example/share /mnt/share \
  -o vers=3.1.1,username=svc_mount,uid=1000

Разрешённый адрес с отказанным или истёкшим портом 445 — это проблема брандмауэра или слушателя на той стороне. Неразрешённое имя — проблема резолвера. А монтирование, которое проходит аутентификацию, но возвращает ошибки прав, — ни то ни другое, поэтому не открывайте сетевой вопрос заново, когда сессия уже установлена.

Держите вывод таким же узким, как доказательства. Когда адрес работает, а имя нет, туннель делает свою работу, и исправление относится к порядку резолвера, домену поиска или собственной конфигурации контейнера.

Похожие статьи