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

Затем выполните одну разрешённую операцию и один запрещённый путь с клиента и повторите после второго переподключения. Если ресурс работает только до первого дёрганья, привязка всё ещё связана со временем жизни интерфейса, и проект не исправлен. Измените привязку или адрес службы, и симптом перестанет возвращаться.