Samba на адрес във VPN: защо слушателят изчезва

Споделеният ресурс работи цяла сутрин, тунелът се свързва отново на обяд и същият път UNC вече изтича времето, докато ping към сървъра още отговаря. В дефиницията на ресурса нищо не се е променило и VPN работи. Променил се е локалният адрес, към който Samba беше вързан, и след пресъздаването на интерфейса той вече не съществува. Този режим на отказ е проблем на жизнения цикъл на слушателя, не проблем с правата.

Ресурсът работи, докато тунелът се рестартира

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

Ping може да успее, ако новият адрес отговаря на ICMP, и точно затова достижимостта изглежда наред, докато ресурсът е мъртъв. Този единствен подвеждащ успех насочва хората към защитната стена.

Достижимостта не е адрес за връзване

Тук се смесват три решения. Маршрутът решава дали пакетът на клиента ще пристигне. Слушащият сокет решава дали нещо ще го приеме на локалния адрес. Конфигурацията на ресурса и правата на файловата система решават какво следва. При пресъздаване на интерфейса се чупи само второто.

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

Дръжте тези собственици разделени и в документацията. Бъдеща промяна в пула на VPN не бива да изисква редактиране на Samba, а промяна в правата на ресурса не бива да изисква рестарт на тунела.

Вържете вместо това към стабилен адрес

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

Ако непременно трябва да се вържете към тунела, разберете договора на инсталираното издание. Параметрите interfaces и bind interfaces only не са едно и също, а документацията за връзване предупреждава за нестабилни интерфейси. Динамично управление на слушателя съществува на някои платформи, но това е възможност за проверка, а не за допускане. Прочетете таблицата преди и след трепване и сравнете двата изхода.

ss -ltnp | grep ':445'

Тествайте повторното свързване, не зелената лампа

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

smbclient -L //files.corp.example -U alice

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