Монтирането на 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 файла или в аргументите за стартиране, а не само в профила на хоста.

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

Едва тогава погледнете споделения ресурс и филтъра

След като името се разпознае, останалите откази са обикновени мрежови. 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 е проблем на защитна стена или на слушател от другата страна. Неразпознато име е проблем на резолвера. А монтиране, което се автентикира, но връща грешки за права, не е нито едното, нито другото, затова не отваряйте отново мрежовия въпрос, след като сесията е установена.

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

Подобни статии