SSH lyttar ikkje etter omstart: VPN-adressa kjem for seint

Du bind SSH til tunneladressa under oppsettet, det verkar, og etter neste omstart kan ingen logge inn før nokon startar tenesta på nytt manuelt. Legitimasjonen er ikkje problemet. Daemonen bad kjernen om ei adresse som enno ikkje fanst, bindinga mislukkast, og meldinga rulla forbi i oppstartsloggen. Det som ser ut som eit autentiseringsproblem, er eit problem med oppstartsrekkjefølgja.

Kva bindingsfeilen faktisk seier

Ein lyttande socket må opprettast på ei adresse som finst i det augneblinken. Når VPN-grensesnittet dukkar opp seinare, har ein daemon som er konfigurert til å binde berre til tunneladressa, ingenting å feste seg til. Konfigurasjonen held fram med å vere syntaktisk gyldig; miljøet var rett og slett ikkje klart. Ei teneste som har køyrt sidan ein manuell start, går aldri gjennom oppstartsvegen, og difor viser feilen seg først ved neste omstart. Samanlikn tidsstempelet for den mislukka bindinga med tidsstempelet for tildelinga av adressa, og rekkjefølgja blir openber.

Konfigurasjonsgyldigheit og køyretidsberedskap er separate eigenskapar. Test begge, fordi ein av dei feilar utan å seie noko.

Kva prosess som eig porten

Daemonen er ikkje alltid komponenten som opprettar lyttaren. Socket-aktivering flyttar det ansvaret til ein unit, og då endrar ein omstart av daemonen ingenting.

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

Socket-lista viser kva prosess som held porten og på kva adresse, medan unit-dumpen viser om det i det heile finst ein socket-unit. Når aktivering er i spel, høyrer adressa til socket-uniten, og daemon-fila er ikkje autoritativ. Les oppstartsloggen for den eigentlege bindingsfeilen i staden for å utleie han frå symptomet. Ein manglande socket-unit betyr berre den klassiske ordninga, der daemonen bind direkte.

Gjer beredskapen eksplisitt, ikkje ein søvn

Ei fast forseinking er ei gjetting som behandlar rask maskinvare og trege nettverk likt. Uttrykk i staden avhengnaden: vent på adressa, start så.

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

Legg til ein ExecStartPre-kommando som blir gjenteken til adressa dukkar opp, eller ordne uniten etter det spesifikke nettverksmålet som eig grensesnittet. Begge tilnærmingane registrerer avhengnaden på ein stad den neste administratoren kan lese. Løkka treng ein timeout, elles etterlèt ein mislukka VPN ein unit som heng i staden for å rapportere ein feil. Stadfest deretter at daemonen bind tunneladressa medan det vanlege grensesnittet framleis blir styrt av filterreglane dine.

Test ein rein oppstart og ei gjentilkopling

Ein manuell omstart etter at alt er på nett beviser ingenting om oppstartsrekkjefølgja. Start maskinen på nytt med tunnelen konfigurert til å kome opp automatisk, og sjå om lyttaren dukkar opp utan inngrep.

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

Slepp deretter tunnelen og gjenopprett han, fordi ei gjentilkopling kan endre adressa, og ei hardkoda binding vil ikkje følgje henne. Hald ein ut-av-band-gjenopprettingsveg under testing, slik at ei dårleg rekkjefølgjeendring ikkje kan låse deg ute frå verten.

Suksesskriteriet er ein lyttar som dukkar opp under sin dokumenterte avhengnad, ikkje ein som nokon hugsa å starte på nytt.