Server können beim Booten nicht an Adressen gebunden werden

Ich habe es mit einem bekannten Problem in RHEL 7 zu tun, bei dem Dienste, die eine zu bindende Adresse angeben, nicht korrekt gestartet werden. Ich habe eine Reihe ähnlicher Berichte gefunden, viele sagen, dass sie mit Updates für systemd behoben wurden, aber ich bin immer noch mit diesem Problem konfrontiert. Dies betrifft alle Dienste auf meiner Box (sshd, sshd, vsftpd, nginx), die nicht nur an 0.0.0.0 gebunden sind.

Ich habe alle möglichen vermeintlichen Problemumgehungen gefunden, aber keine davon funktioniert konsequent für mich. Am Beispiel von sshd sieht die Konfiguration folgendermaßen aus:

Port 22
ListenAddress 192.168.242.225
...

Folgendes habe ich alleine und in Kombinationen versucht:

Von https://bugzilla.redhat.com/show_bug.cgi?id=1352214#c4 (Ich habe es auch sys-subsystem-net-devices-eth1.deviceanstelle von versucht, network-online.targetaber ich vermute, dass dies nicht auf die Adressierung wartet.)

mkdir /etc/systemd/system/sshd.service.d
tee /etc/systemd/system/sshd.service.d/wait.conf << 'EOF'
[Unit]
After=network-online.target
EOF

Von 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

Von https://bugzilla.redhat.com/show_bug.cgi?id=1438749#c0

systemctl add-wants multi-user.target network.target

Von irgendwo

mkdir /etc/systemd/system/sshd.service.requires
ln -s /usr/lib/systemd/system/network-online.target /etc/systemd/system/sshd.service.requires/

Egal was ich versuche, ich erhalte normalerweise "Fehler: Bindung an Port 22 auf 192.168.242.125 fehlgeschlagen: Angeforderte Adresse kann nicht zugewiesen werden". Manchmal fängt alles perfekt an, was meiner Meinung nach auf ein Timing-Problem zurückzuführen ist.

Wenn Sie Scientific Linux (RHEL) 7.5 ausführen und der Netzwerkmanager aktiviert ist, ist die gesamte IP-Adressierung statisch. Wenn es weitere Details gibt, die helfen könnten, lassen Sie es mich bitte wissen. Hier ist die Ausgabe von journalctlnach einem fehlgeschlagenen Start mit After=network-online.targetin der sshd-Einheitendatei. Relevante Dinge beginnen um Zeile 1700. Ich hoffe, jemand ist auf dieses Problem gestoßen und hat es erfolgreich gelöst!

Wenn Sie NetworkManager verwenden, network-online.targetmüssen Sie den Dienst aktivieren NetworkManager-wait-online.service, der tatsächlich darauf wartet, dass das Netzwerk online ist, um dieses Ziel zu erreichen, damit es wie erwartet funktioniert.

Die network-online.targetmüssen in Ihren Netzwerkmanager "eingebunden" werden (da NetworkManager nicht die einzige Alternative ist, gibt es auch systemd-networkd, mit dem das Netzwerk verwaltet werden kann.)

Um network-online.targetmit NetworkManager arbeiten zu können, benötigen Sie einen Symlink unter /etc/systemd/system/network-online.target.wants/Zeigen auf /usr/lib/systemd/system/NetworkManager-wait-online.service.

Was Sie tatsächlich erstellen können, indem Sie diesen Dienst aktivieren:

$ 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.

Sobald network-online.targetdies geschehen ist, sollten die Abhängigkeiten von funktionieren und warten, bis NetworkManager alle Schnittstellen aufgerufen hat, die beim Booten aufgerufen werden sollen.

Um Probleme mit diesem Setup zu diagnostizieren, sollten Sie sich auch die Ausgabe von systemctl status network-online.targetund ansehen systemctl status NetworkManager-wait-online.service, da diese möglicherweise mehr Hinweise darauf enthalten, was gerade passiert. (Insbesondere die Zeitstempel können hilfreich sein. Wenn die Dämonen, von denen abhängig ist, vor demnetwork-online.target Start gestartet werden, ist möglicherweise ein Problem mit Ihrer Konfiguration aufgetreten.) NetworkManager-wait-online.service

Von den von Ihnen aufgelisteten Lösungen würde ich diese empfehlen:

# 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

Da network-online.targetist diejenige, die Sie tatsächlich wollen (um sicherzustellen, dass alle IPs aktiv sind usw.) und einschließlich Wants=stellt sicher, dass der Start angefordert wird.

Bei den anderen Methoden funktioniert diese Methode nicht: systemctl add-wants multi-user.target network.targetda keine Abhängigkeiten zwischen den Diensten selbst (SSH-Daemon usw.) und dem Netzwerk hergestellt werden, das vollständig aktiv ist. Es heißt nur, dass das Netzwerk aktiv sein soll ...

Und demjenigen, der das /etc/systemd/system/sshd.service.requires/Verzeichnis betrifft, fehlt die After=Abhängigkeit (was meiner Meinung nach wesentlich ist und nicht dadurch impliziert wird, dass nur ein Verzeichnis vorhanden ist .requires/). Wenn Sie der Meinung Requires=sind, dass dies besser ist als Wants=(es ist stärker, führt zum Ausfall der Einheit, wenn die Abhängigkeit fehlschlägt), dann Ich würde empfehlen, /etc/systemd/system/sshd.service.d/wait.confstattdessen nur das zu verwenden. Die Überschreibungsdatei ist definitiv eine flexiblere Möglichkeit, diese Konfiguration zu verwalten.

Das Hinzufügen einer Abhängigkeit von sys-subsystem-net-devices-eth1.devicehilft auch nicht, da dies nur darauf hinweist, dass das Gerät vorhanden ist (aus Sicht von udev), was noch nichts darüber aussagt, dass es aktiv und konfiguriert ist. Das ist also auch keine Option.

Es ist möglicherweise besser, Systemdienste nicht so zu konfigurieren, dass sie bestimmte IP-Adressen abhören und bei Bedarf den Zugriff auf diese über die Host-Firewall steuern.

Wenn Sie wirklich in der Lage sein müssen, sich an bestimmte IP-Adressen zu binden, bevor diese auf einer Netzwerkschnittstelle konfiguriert werden, können Sie das Timing-Problem umgehen, indem Sie sysctl net.ipv4.ip_nonlocal_bindfür IPv4 und sysctl net.ipv6.ip_nonlocal_bindfür IPv6 festlegen . Dienste können dann an IP-Adressen gebunden werden, die auf keiner Netzwerkschnittstelle konfiguriert sind. Auf sie kann jedoch erst zugegriffen werden, wenn diese IP-Adressen auf einer Schnittstelle konfiguriert sind.