Локалният ресурс на Samba изчезна, след като OpenVPN наложи DNS

Samba губи локалните ресурси в момента, в който OpenVPN се свърже, а тунелът почти никога не е причината. Монтирането е наред, NAS работи, и резолверът, който тунелът инсталира, отговаря на въпроси за име, което никога не е виждал. Samba пита този резолвер рано в реда си на търсене, вярва на отговора и се свързва с адрес, където нищо не слуша. Поправянето на ресурса означава поправяне на отговора, а не на монтирането.

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

Кой отговаря за краткото име

Питайте операционната система, не файловия мениджър. resolvectl status показва DNS сървърите, прикачени към всяка връзка, и отбелязва коя връзка е маршрутът по подразбиране, а заявка за краткото име съобщава сървъра, който е отговорил. Изпълнете го веднъж за името на NAS и веднъж за име, за което знаете, че съществува в офис домейна. Ако двата отговора идват от различни сървъри, намерили сте разделянето.

Проверете дали отговорът е бил отрицателен отговор или адрес. Отрицателният отговор означава, че Samba е трябвало да премине към друг механизъм, и повредата е другаде. Адресът означава, че Samba се е свързала с реално място и не е получила нищо.

Защо Samba вярва на грешен отговор

Samba решава имена чрез фиксирана последователност, зададена от name resolve order. В повечето дистрибуции по подразбиране включва host, което означава DNS, и той се изпълнява преди механизмите само за локална мрежа, като broadcast на NetBIOS. Затова тунел, който налага резолвер, получава право на първи отказ за всяко име на ресурс, включително имена с един етикет, които никога не е трябвало да напускат сградата.

Обикновено неизвестното име връща отрицателен отговор и следващият механизъм получава ред. Някои резолвери, особено потребителски на доставчици и публични, отговарят на неизвестни имена със страница за търсене или рекламен адрес. Този отговор изглежда като успех за библиотеката на резолвера, затова Samba спира да търси и набира адрес, който няма нищо общо с вашата мрежа.

Резултатът е ресурс, който изчезва без диалог за грешка. Нищо в тази последователност не е отказ на VPN маршрутизация, затова ping към NAS още работи, а преглеждането му — не.

Две поправки с различен обхват

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

[global]
   name resolve order = wins lmhosts bcast
   dns proxy = no

Без host в този списък DNS излиза от пътя за търсене на ресурси и имената с един етикет остават в локалния сегмент. Офис имената все още се решават нормално за всяка друга програма, защото това променя само Samba. Цената е, че Samba вече изобщо не може да използва DNS, така че ресурс, адресиран с напълно квалифицирано офис име, става проблем.

Широката поправка премахва причината: спрете да налагате резолвер, който отговаря за имена, които не притежава, или наложете политика за разделен DNS, така че до офис резолвера да стигат само офис суфикси. Това е по-добрият дългосрочен отговор в управлявана мрежа, защото защитава и браузъра, и мениджъра на пакети, но изисква административен достъп от страна на сървъра и клиент, който се подчинява на наложените настройки.

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

Суфиксът може да обясни всичко

Ако клиентът налага и суфикс за търсене, краткото локално име се пренаписва в офис домейна, преди да бъде запитано. Тогава резолверът изобщо не лъже: зададен му е честен въпрос за офис име и той е дал верен отговор. Прочетете запитаното име в изхода на резолвера, за да различите това от случая с рекламен адрес, защото двете повреди изглеждат еднакво във файловия мениджър.

Поправката тук е или да използвате напълно квалифицираното локално име, или да добавите правило за разделен DNS, което притежава локалния суфикс. Нито едното не изисква да пипате Samba.

Докажете го след повторно свързване

Тествайте три имена в една сесия: локалния ресурс по кратко име, офис хост по име и обикновен уебсайт. Ако първото работи, а второто се счупи, поправката е преместила повредата, вместо да я премахне. Ако третото се счупи, промяната на резолвера е отишла по-далеч от предвиденото и всяко търсене вече е подозрително.

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

Ако ресурсът все още се проваля след всичките пет проверки, запишете точното запитване и точния отговор, преди да промените нещо друго. Тази двойка редове разграничава повреда в резолвера от име, което наистина не съществува, и това е най-бързата бележка за предаване, която можете да напишете.