Ваше монтування 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 — це проблема брандмауера або слухача на тому боці. Нерозв’язане ім’я — проблема резолвера. А монтування, яке проходить автентифікацію, але повертає помилки прав, — ні те ні інше, тому не відкривайте мережеве питання знову, коли сесію вже встановлено.

Тримайте висновок таким вузьким, як докази. Коли адреса працює, а ім’я ні, тунель робить свою роботу, і виправлення належить до порядку резолвера, домену пошуку або власної конфігурації контейнера.

Схожі статті