SSH não escuta após reiniciar: o endereço VPN chega tarde

Você liga o SSH ao endereço do túnel durante a configuração, funciona, e após o próximo reinício ninguém consegue entrar até que alguém reinicie o serviço à mão. As credenciais não são o problema. O daemon pediu ao kernel um endereço que ainda não existia, a ligação falhou e a mensagem passou no log de arranque. O que parece um problema de autenticação é um problema de ordem de arranque.

O que o erro de ligação realmente diz

Um socket de escuta precisa ser criado num endereço que exista naquele momento. Quando a interface VPN surge mais tarde, um daemon configurado para se ligar apenas ao endereço do túnel não tem a que se agarrar. A configuração continua sintaticamente válida; o ambiente simplesmente não estava pronto. Um serviço que corre desde um arranque manual nunca percorre o caminho de arranque, e é por isso que a falha só aparece no reinício seguinte. Compare o carimbo de tempo da ligação falhada com o da atribuição do endereço, e a ordem torna-se óbvia.

A validade da configuração e a prontidão em tempo de execução são propriedades separadas. Teste as duas, porque uma delas falha sem dizer nada.

Que processo possui a porta

O daemon nem sempre é o componente que cria o ouvinte. A ativação por socket transfere essa responsabilidade para uma unidade, e então reiniciar o daemon não muda nada.

ss -ltnp 'sport = :22'
systemctl cat ssh.socket

A lista de sockets mostra que processo detém a porta e em que endereço, enquanto o dump da unidade mostra se existe uma unidade de socket. Quando a ativação está em jogo, o endereço pertence à unidade de socket e o ficheiro do daemon não é autoritativo. Leia o log de arranque para o erro de ligação real em vez de o inferir do sintoma. Uma unidade de socket ausente significa apenas a disposição clássica, em que o daemon se liga diretamente.

Torne a prontidão explícita, não uma espera

Um atraso fixo é um palpite que trata igual hardware rápido e redes lentas. Em vez disso, expresse a dependência: espere pelo endereço e depois inicie.

ip -4 addr show dev tun0
systemctl edit ssh.service

Adicione um comando ExecStartPre que se repita até o endereço aparecer, ou ordene a unidade após o alvo de rede específico a que pertence a interface. Ambas as abordagens registam a dependência num local que o próximo administrador possa ler. O ciclo precisa de um tempo limite, senão um VPN falhado deixa uma unidade pendurada em vez de reportar uma falha. Depois confirme que o daemon liga o endereço do túnel enquanto a interface comum continua regida pelas suas regras de filtragem.

Teste um arranque limpo e uma reconexão

Um reinício manual depois de tudo estar online não prova nada sobre a ordem de arranque. Reinicie a máquina com o túnel configurado para subir automaticamente e observe se o ouvinte aparece sem intervenção.

systemctl status ssh.service
ss -ltnp 'sport = :22'

Depois derrube e restabeleça o túnel, porque uma reconexão pode mudar o endereço e uma ligação codificada de forma rígida não a seguirá. Mantenha um caminho de recuperação fora de banda durante os testes, para que uma má alteração de ordem o não possa bloquear fora do anfitrião.

O critério de sucesso é um ouvinte que aparece sob a sua dependência documentada, não um que alguém se lembrou de reiniciar.