Я имею дело с известный выпуск в RHEL 7, в результате чего службы, указывающие адрес для привязки, не будут запускаться правильно. Я нашел несколько похожих отчетов, многие говорят, что они были устранены с помощью обновлений systemd, но я все еще сталкиваюсь с этой проблемой. Это влияет на все службы в моем ящике (sshd, sshd, vsftpd, nginx), которые не просто привязаны к 0.0.0.0.
Я нашел всевозможные обходные пути, но ни один из них не работает для меня постоянно. На примере sshd конфигурация выглядит так:
Port 22
ListenAddress 192.168.242.225
...
Вот что я пробовал, по отдельности и в комбинации:
Из https://bugzilla.redhat.com/show_bug.cgi?id=1352214#c4 (Я также пробовал sys-subsystem-net-devices-eth1.device на месте network-online.target но я подозреваю, что это не дожидается обращения.)
mkdir /etc/systemd/system/sshd.service.d
tee /etc/systemd/system/sshd.service.d/wait.conf << 'EOF'
[Unit]
After=network-online.target
EOF
Из https://bugzilla.redhat.com/show_bug.cgi?id=1352214#c11
mkdir /etc/systemd/system/sshd.service.d
tee /etc/systemd/system/sshd.service.d/wait.conf << 'EOF'
[Unit]
Wants=network-online.target
After=network-online.target
EOF
Из https://bugzilla.redhat.com/show_bug.cgi?id=1438749#c0
systemctl add-wants multi-user.target network.target
Откуда-то
mkdir /etc/systemd/system/sshd.service.requires
ln -s /usr/lib/systemd/system/network-online.target /etc/systemd/system/sshd.service.requires/
Независимо от того, что я пытаюсь, я обычно получаю сообщение «ошибка: сбой при привязке к порту 22 на 192.168.242.125: невозможно назначить запрошенный адрес». Иногда все запускается отлично, что, как я предполагаю, связано с проблемой времени.
При запуске Scientific Linux (RHEL) 7.5 и включенном сетевом менеджере все IP-адреса статические. Если есть другие подробности, которые могут помочь, дайте мне знать. Вот это результат journalctl после неудачного запуска, с After=network-online.target в файле модуля sshd. Соответствующий материал начинается около строки 1700. Надеюсь, кто-то столкнулся с этой проблемой и успешно ее решил!
Может быть лучше не настроить системные службы на прослушивание определенных IP-адресов и при необходимости управлять доступом к ним через брандмауэр хоста.
Если вам действительно нужно иметь возможность привязаться к определенным IP-адресам до того, как они будут настроены на сетевом интерфейсе, вы можете обойти проблему синхронизации, установив sysctl net.ipv4.ip_nonlocal_bind для IPv4 и sysctl net.ipv6.ip_nonlocal_bind для IPv6. Затем службы могут связываться с IP-адресами, не настроенными на каком-либо сетевом интерфейсе, но они не будут доступны, пока эти IP-адреса не будут настроены на интерфейсе.
Если вы используете NetworkManager, то для того, чтобы network-online.target чтобы работать как положено, вам нужно включить сервис NetworkManager-wait-online.service, который фактически ожидает, пока сеть будет подключена к сети, чтобы удовлетворить эту цель.
В network-online.target необходимо «подключить» к вашему сетевому менеджеру (поскольку NetworkManager - не единственная альтернатива, есть также systemd-networkd, который можно использовать для управления сетью.)
Для network-online.target для работы с NetworkManager вам необходимо иметь символическую ссылку под /etc/systemd/system/network-online.target.wants/ указывает на /usr/lib/systemd/system/NetworkManager-wait-online.service.
Что вы действительно можете создать, включив эту службу:
$ sudo systemctl enable NetworkManager-wait-online.service
Created symlink from /etc/systemd/system/network-online.target.wants/NetworkManager-wait-online.service to /usr/lib/systemd/system/NetworkManager-wait-online.service.
Как только это будет сделано, зависимости от network-online.target должен начать работать, ожидая, пока NetworkManager не завершит работу со всеми интерфейсами, которые он должен вызывать при загрузке.
Чтобы помочь диагностировать любые проблемы с этой настройкой, вы можете посмотреть на вывод systemctl status network-online.target и systemctl status NetworkManager-wait-online.service а также, поскольку они могут иметь больше подсказок о том, что происходит. (В частности, временные метки могут быть полезны, если демоны, зависящие от network-online.target начинаем перед NetworkManager-wait-online.service завершено, значит, у вас может быть проблема с вашей конфигурацией.)
Из перечисленных вами решений я бы порекомендовал это:
# mkdir /etc/systemd/system/sshd.service.d
# tee /etc/systemd/system/sshd.service.d/wait.conf << 'EOF'
[Unit]
Wants=network-online.target
After=network-online.target
EOF
поскольку network-online.target это тот, который вы действительно хотите (чтобы убедиться, что все IP-адреса включены и т. д.), и включая Wants= гарантирует, что его запуск будет запрошен.
Из других методов этот не сработает: systemctl add-wants multi-user.target network.target, поскольку он не создает никаких зависимостей между самими службами (демон SSH и т. д.) и полностью работающей сетью. Это просто говорит, что вы хотите, чтобы сеть работала ...
И тот, в котором участвует /etc/systemd/system/sshd.service.requires/ в каталоге отсутствует After= зависимость (которая, как я считаю, важна и не подразумевается просто наличием .requires/ на нем.) Если вы думаете Requires= лучше, чем Wants= (он сильнее, приводит к сбою модуля, если зависимость не работает), тогда я бы рекомендовал просто использовать это в /etc/systemd/system/sshd.service.d/wait.conf вместо этого файл переопределения, безусловно, является более гибким способом управления этой конфигурацией.
Добавление зависимости от sys-subsystem-net-devices-eth1.device тоже не помогает, поскольку это только указывает на то, что устройство существует (с точки зрения udev), что ничего не говорит о том, что оно еще настроено и настроено. Так что это тоже не вариант.