Os servidores não conseguem ligar a endereços no arranque

Question

Estou lidando com um conhecido problema no RHEL 7, pelo qual os serviços que especificam um endereço para o qual se ligar não serão iniciados corretamente. Eu encontrei um número de relatórios semelhantes, muitos dizem que foram resolvidos com atualizações para o systemd, mas ainda enfrento esse problema. Isso afeta todos os serviços da minha caixa (sshd, sshd, vsftpd, nginx) que não se limitam a 0.0.0.0.

Eu encontrei todos os tipos de supostas soluções, mas nenhuma delas funciona para mim de forma consistente. Tomando o sshd como exemplo, config se parece com isto:

Port 22
ListenAddress 192.168.242.225
...

Veja o que eu tentei, sozinho e em combinações:

Do link (também testei sys-subsystem-net-devices-eth1.device no lugar de network-online.target mas eu suspeito que isso não espere que isso aconteça.)

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

De link

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

De link

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

De algum lugar

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

Não importa o que eu tente, eu geralmente acabo com "error: bind to port 22 on 192.168.242.125 failed: Não é possível atribuir o endereço solicitado". Às vezes, tudo começa perfeitamente, o que eu acho que está relacionado a um problema de tempo.

Executando o Scientific Linux (RHEL) 7.5 e o gerenciador de rede está ativado, todo o endereçamento IP é estático. Se houver algum outro detalhe que possa ajudar, por favor me avise. Aqui é a saída de journalctl após uma inicialização com falha, com After=network-online.target no arquivo de unidade sshd. Coisas relevantes começam na linha 1700. Esperando que alguém tenha se deparado com esse problema e resolvido com sucesso!

    

Answer 1

Se você estiver usando o NetworkManager, para que network-online.target funcione como esperado, é necessário ativar o serviço NetworkManager-wait-online.service , que é o que na verdade espera que a rede seja online para satisy esse alvo.

O network-online.target precisa ser "conectado" ao seu gerenciador de rede (como o NetworkManager não é a única alternativa, há também o systemd-networkd que pode ser usado para gerenciar a rede.)

Para que network-online.target trabalhe com o NetworkManager, você precisa ter um link simbólico em /etc/systemd/system/network-online.target.wants/ apontando para /usr/lib/systemd/system/NetworkManager-wait-online.service .

O que você pode realmente criar ativando esse serviço:

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

Uma vez que isso esteja em vigor, as dependências de network-online.target devem começar a funcionar, esperando até que o NetworkManager termine a criação de todas as interfaces que devem ser exibidas na inicialização.

Para ajudar a diagnosticar problemas com essa configuração, convém ver também a saída de systemctl status network-online.target e systemctl status NetworkManager-wait-online.service , pois eles podem ter mais pistas sobre o que está acontecendo. (Em particular, os timestamps podem ser úteis, se os daemons que dependem de network-online.target estiverem iniciando antes de NetworkManager-wait-online.service ter terminado, então você pode ter um problema com sua configuração.)

Das soluções listadas, eu recomendaria essa:

# 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

Como network-online.target é o que você realmente quer (para garantir que todos os IPs estejam ativos, etc.) e incluir Wants= garante que sua inicialização seja solicitada.

Dos outros métodos, este não funcionará: systemctl add-wants multi-user.target network.target , já que não está criando nenhuma dependência entre os serviços em si (daemon SSH, etc.) e a rede está totalmente ativa. É só dizer que você quer que a rede esteja ativa ...

E o que envolve o diretório /etc/systemd/system/sshd.service.requires/ está sem a dependência After= (que eu acredito ser essencial, e não implícito por ter apenas um .requires/ .) Se você acha que Requires= é melhor que Wants= (é mais strong, faz com que a unidade falhe se a dependência falhar), então eu recomendo usar isso apenas em /etc/systemd/system/sshd.service.d/wait.conf , o arquivo de substituição é definitivamente uma maneira mais flexível de gerenciar essa configuração.

A adição de uma dependência em sys-subsystem-net-devices-eth1.device também não ajuda, já que isso indica apenas que o dispositivo existe (do ponto de vista do udev), o que não diz nada sobre ele estar configurado e configurado ainda. Então isso não é uma opção.

    

Answer 2

Talvez seja melhor não configurar os serviços do sistema para ouvir endereços IP específicos e controlar o acesso a eles por meio do firewall do host, se necessário.

Se você realmente precisar se vincular a endereços IP específicos antes de configurá-los em uma interface de rede, poderá solucionar o problema de tempo configurando o sysctl net.ipv4.ip_nonlocal_bind para IPv4 e o sysctl net.ipv6.ip_nonlocal_bind para IPv6. Os serviços podem, então, ligar-se a endereços IP não configurados em qualquer interface de rede, mas eles não estarão acessíveis até que esses endereços IP sejam configurados em uma interface.