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

Затым выканайце адну дазволеную аперацыю і адзін забаронены шлях з кліента і паўтарыце пасля другога перападлучэння. Калі рэсурс працуе толькі да першага вагання, прывязка ўсё яшчэ звязана з жыццём інтэрфейсу, і дызайн не выпраўлены. Змяніце прывязку або адрас службы, і сімптом больш не вернецца.