Samba и rsync + OpenVPN (не стартуют демоны при включении)

Автор GNU Human, 05 апреля 2023, 22:45:41

« назад - далее »

0 Пользователи и 1 гость просматривают эту тему.

GNU Human

Эти два демона настроены на работу только с определённым OpenVPN-интерфейсом.

В конфиге rsync прописано: address = w.x.y.z

В конфиге самбы прописано:
interfaces = w.x.y.z/24
bind interfaces only = yes

Однако при включении сервера, ни один из демонов не стартует, потому что говорит, что нету интерфейса w.x.y.z. То есть, OpenVPN стартует позже них, и соответственно, позже поднимает нужный интерфейс.

Потом, когда VPN уже подключена, то вручную оба демона запускаются нормально.

Как можно разрешить эту ситуацию?

Нужно, чтобы оба демона "смотрели" только в VPN.

ogost

В настройках юнитов системды для rsync и samba нужно внести что-то вроде
Requires=<название сервиса>.service

GNU Human

Цитата: ogost от 06 апреля 2023, 03:34:22В настройках юнитов системды для rsync и samba нужно внести что-то вроде
Код Выделить Развернуть
Requires=<название сервиса>.service

Насколько я понимаю, это лишь означает, что при запуске одного сервиса, будет одновременно запущен и тот, который прописан в requires. При этом если requires-сервис не будет запущен, то и первый сервис будет деактивирован. Но о порядке запуска в этом случае речи не идёт.
Тогда возможна ситуация, что ОпенВПН не успеет поднять ВПН (для этого же нужно какое-то время), и соответственно Самба не стартанёт.

ogost

man systemd.unitВозможно вы правы, кажется я не так интерпретирую man.
Там есть ещё варианты Wants, After

Walter_322

#4
Я так понял, что проблема в том, что на момент старта демонов отсутствует сетевой интерфейс. Тут либо:
1) указывать в самбе вместо адреса конкретное имя интерфейса (например, tun1) и пытаться сделать бинд его (не знаю, можно ли ovpn так сконфигурировать, чтобы интерфейс существовал перманентно).

2) не ограничивать самбу интерфейсом, а адресами (подсетями) с помощью опций hosts allow и hosts deny. Судя по тому, что Вы пытаетесь и интерфейс определить по ip адресу, это именно то что Вам нужно

3) реализовать фильтрацию средствами фаерволла (правилами iptables)

4) посмотреть в сторону скриптов, выполняемых при подключении туннеля

GNU Human

#5
Цитата: ogost от 06 апреля 2023, 06:37:19man systemd.unitВозможно вы правы, кажется я не так интерпретирую man.
Там есть ещё варианты Wants, After

Да, After - ближе к цели. Однако и здесь есть загвоздка. Вроде как не рекомендуется изменять юниты, поставляемые в пакетах, во избежание труднодиагностируемых проблем. Например, что если в будущем будет удалён/изменён сервис с нужным ВПН, а юнит самбы, прочитав after, будет ждать именно этот сервис. Получается, опять не запустится.

06 апреля 2023, 07:42:27
Цитата: Walter_322 от 06 апреля 2023, 07:35:432) не ограничивать самбу интерфейсом, а адресами (подсетями) с помощью опций hosts allow и hosts deny. Судя по тому, что Вы пытаетесь и интерфейс определить по адресу, это именно то что Вам нужно

Вариант, заслуживающий внимания! Однако не лишённый недостатков. В этом случае Демоны будут слушать все интерфейсы, в том числе и ВАН. Да, соединения с неопознанных хостов будут отвергаться, но порт-то будет прослушиваться, а значит в него смогут ломиться извне, засоряя тем самым журналы, и создавая риски взлома, если будет найдена очередная уязвимость. Хотелось бы, чтобы демоны вообще не слушали ВАН.

Walter_322

#6
Все пакеты в рамках коннекшнов с состоянием new, прилетающие на wan, нужно по-умолчанию дропать. Самба - не единственный сервис, которому угрожает доступность из глобальной сети.
И лишь разрешать доступ по конкретным портам/протоколам, доступ к которым нужен извне.