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

Потім виконайте одну дозволену операцію та один заборонений шлях з клієнта й повторіть після другого перепідключення. Якщо ресурс працює лише до першого смикання, прив’язка досі пов’язана з часом життя інтерфейсу, і проєкт не виправлено. Змініть прив’язку або адресу служби, і симптом перестане повертатися.