SSH lytter ikke etter omstart: VPN-adressen kommer for sent

Du binder SSH til tunneladressen under oppsettet, det virker, og etter neste omstart kan ingen logge inn før noen starter tjenesten på nytt manuelt. Legitimasjonen er ikke problemet. Daemonen ba kjernen om en adresse som ennå ikke fantes, bindingen mislyktes, og meldingen rullet forbi i oppstartsloggen. Det som ser ut som et autentiseringsproblem, er et problem med oppstartsrekkefølgen.

Hva bindingsfeilen faktisk sier

En lyttende socket må opprettes på en adresse som finnes i det øyeblikket. Når VPN-grensesnittet dukker opp senere, har en daemon som er konfigurert til å binde bare til tunneladressen, ingenting å feste seg til. Konfigurasjonen forblir syntaktisk gyldig; miljøet var rett og slett ikke klart. En tjeneste som har kjørt siden en manuell start, går aldri gjennom oppstartsveien, og derfor vises feilen først ved neste omstart. Sammenlign tidsstempelet for den mislykkede bindingen med tidsstempelet for tildelingen av adressen, og rekkefølgen blir åpenbar.

Konfigurasjonsgyldighet og kjøretidsberedskap er separate egenskaper. Test begge, fordi en av dem feiler uten å si noe.

Hvilken prosess eier porten

Daemonen er ikke alltid komponenten som oppretter lytteren. Socket-aktivering flytter det ansvaret til en unit, og da endrer en omstart av daemonen ingenting.

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

Socket-listen viser hvilken prosess som holder porten og på hvilken adresse, mens unit-dumpen viser om det i det hele tatt finnes en socket-unit. Når aktivering er i spill, hører adressen til socket-uniten, og daemon-filen er ikke autoritativ. Les oppstartsloggen for den egentlige bindingsfeilen i stedet for å utlede den fra symptomet. En manglende socket-unit betyr bare den klassiske ordningen, der daemonen binder direkte.

Gjør beredskap eksplisitt, ikke en søvn

En fast forsinkelse er en gjetning som behandler rask maskinvare og trege nettverk likt. Uttrykk i stedet avhengigheten: vent på adressen, start så.

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

Legg til en ExecStartPre-kommando som gjentas til adressen dukker opp, eller ordne uniten etter det spesifikke nettverksmålet som eier grensesnittet. Begge tilnærmingene registrerer avhengigheten et sted den neste administratoren kan lese. Løkken trenger en timeout, ellers etterlater en mislykket VPN en unit som henger i stedet for å rapportere en feil. Bekreft deretter at daemonen binder tunneladressen mens det vanlige grensesnittet fortsatt styres av filterreglene dine.

Test en ren oppstart og en gjentilkobling

En manuell omstart etter at alt er på nett beviser ingenting om oppstartsrekkefølgen. Start maskinen på nytt med tunnelen konfigurert til å komme opp automatisk, og se om lytteren dukker opp uten inngrep.

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

Slipp deretter tunnelen og gjenopprett den, fordi en gjentilkobling kan endre adressen, og en hardkodet binding vil ikke følge den. Behold en ut-av-bånd-gjenopprettingsvei under testing, slik at en dårlig rekkefølgeendring ikke kan låse deg ute fra verten.

Suksesskriteriet er en lytter som dukker opp under sin dokumenterte avhengighet, ikke en som noen husket å starte på nytt.