SSH no escolta després de reiniciar: l'adreça VPN arriba tard

Lligueu SSH a l'adreça del túnel durant la configuració, funciona, i després del següent reinici ningú no pot iniciar sessió fins que algú reinicia el servei a mà. Les credencials no són el problema. El dimoni va demanar al nucli una adreça que encara no existia, l'enllaç va fallar i el missatge va passar de llarg al registre d'arrencada. El que sembla un problema d'autenticació és un problema d'ordre d'inici.

Què diu realment l'error d'enllaç

Un sòcol d'escolta s'ha de crear en una adreça que existeixi en aquell moment. Quan la interfície VPN apareix més tard, un dimoni configurat per enllaçar-se només a l'adreça del túnel no té res a què connectar-se. La configuració continua sent sintàcticament vàlida; simplement l'entorn no estava a punt. Un servei que funciona des d'una arrencada manual no recorre mai el camí d'arrencada, i per això la fallada només apareix al següent reinici. Compareu la marca de temps de l'enllaç fallit amb la de l'assignació de l'adreça i l'ordre es fa evident.

La validesa de la configuració i la disponibilitat en temps d'execució són propietats separades. Proveu les dues, perquè una falla sense dir res.

Quin procés posseeix el port

El dimoni no sempre és el component que crea l'oient. L'activació de sòcols trasllada aquesta responsabilitat a una unitat, i llavors reiniciar el dimoni no canvia res.

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

El llistat de sòcols mostra quin procés té el port i en quina adreça, mentre que l'abocament de la unitat mostra si existeix alguna unitat de sòcol. Quan l'activació hi intervé, l'adreça pertany a la unitat de sòcol i el fitxer del dimoni no és autoritatiu. Llegiu el registre d'arrencada per trobar l'error d'enllaç real en lloc d'inferir-lo del símptoma. Una unitat de sòcol absent simplement significa la disposició clàssica, en què el dimoni s'enllaça directament.

Feu explícita la disponibilitat, no un son

Un retard fix és una conjectura que tracta igual el maquinari ràpid i les xarxes lentes. Expresseu la dependència en el seu lloc: espereu l'adreça i després inicieu.

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

Afegiu una ordre ExecStartPre que es repeteixi fins que aparegui l'adreça, o ordeneu la unitat després de l'objectiu de xarxa concret que posseeix la interfície. Tots dos enfocaments registren la dependència en algun lloc que el proper administrador pugui llegir. El bucle necessita un temps d'espera, o un VPN fallit deixa una unitat penjada en lloc d'informar d'una fallada. Després confirmeu que el dimoni enllaça l'adreça del túnel mentre la interfície ordinària continua regida per les vostres regles de filtratge.

Proveu una arrencada neta i una reconnexió

Un reinici manual quan tot és en línia no demostra res sobre l'ordre d'arrencada. Reinicieu la màquina amb el túnel configurat perquè pugi automàticament i observeu si l'oient apareix sense intervenció.

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

Llavors baixeu i torneu a establir el túnel, perquè una reconnexió pot canviar l'adreça i un enllaç codificat de forma fixa no la seguirà. Mantingueu un camí de recuperació fora de banda durant les proves, perquè un mal canvi d'ordre no us pugui deixar fora de l'amfitrió.

El criteri d'èxit és un oient que apareix sota la seva dependència documentada, no un que algú va recordar reiniciar.