SSH lytter ikke efter genstart: VPN-adressen kommer for sent

Du binder SSH til tunneladressen under opsætningen, det virker, og efter den næste genstart kan ingen logge ind, før nogen genstarter tjenesten manuelt. Legitimationsoplysningerne er ikke problemet. Daemonen bad kernen om en adresse, der endnu ikke fandtes, bindingen mislykkedes, og meddelelsen rullede forbi i opstartsloggen. Det, der ser ud som et godkendelsesproblem, er et problem med opstartsrækkefølgen.

Hvad bindingsfejlen faktisk siger

En lyttende socket skal oprettes på en adresse, der findes i det øjeblik. Når VPN-grænsefladen dukker op senere, har en daemon, der er konfigureret til kun at binde til tunneladressen, intet at hænge sig på. Konfigurationen forbliver syntaktisk gyldig; miljøet var simpelthen ikke klar. En tjeneste, der har kørt siden en manuel start, gennemgår aldrig opstartsvejen, og derfor viser fejlen sig først ved den næste genstart. Sammenlign tidsstemplet for den mislykkede binding med tidsstemplet for tildelingen af adressen, og rækkefølgen bliver indlysende.

Konfigurationsgyldighed og kørselsklarhed er separate egenskaber. Test begge, fordi en af dem fejler uden at sige noget.

Hvilken proces ejer porten

Daemonen er ikke altid den komponent, der opretter lytteren. Socket-aktivering flytter det ansvar til en unit, og derefter ændrer en genstart af daemonen intet.

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

Socket-oversigten viser, hvilken proces der holder porten og på hvilken adresse, mens unit-dumpet viser, om der overhovedet findes en socket-unit. Når aktivering er i spil, hører adressen i socket-uniten, og daemon-filen er ikke autoritativ. Læs opstartsloggen for den egentlige bindingsfejl i stedet for at udlede den af symptomet. En manglende socket-unit betyder blot den klassiske ordning, hvor daemonen binder direkte.

Gør klarhed eksplicit, ikke et hvil

En fast forsinkelse er et gæt, der behandler hurtigt hardware og langsomme netværk ens. Udtryk i stedet afhængigheden: vent på adressen, og start så.

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

Tilføj en ExecStartPre-kommando, der gentages, indtil adressen dukker op, eller ordn uniten efter det specifikke netværksmål, der ejer grænsefladen. Begge tilgange registrerer afhængigheden et sted, hvor den næste administrator kan læse den. Løkken har brug for en timeout, ellers efterlader en mislykket VPN en unit, der hænger i stedet for at rapportere en fejl. Bekræft derefter, at daemonen binder tunneladressen, mens den almindelige grænseflade fortsat styres af dine filterregler.

Test en ren opstart og en genopkobling

En manuel genstart, efter at alt er online, beviser intet om opstartsrækkefølgen. Genstart maskinen med tunnelen konfigureret til at komme op automatisk, og se, om lytteren dukker op uden indgriben.

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

Slip derefter tunnelen og genopret den, fordi en genopkobling kan ændre adressen, og en hårdkodet binding vil ikke følge den. Bevar en ud-af-bånd-genopretningsvej under test, så en dårlig rækkefølgeændring ikke kan låse dig ude af værten.

Succeskriteriet er en lytter, der dukker op under sin dokumenterede afhængighed, ikke en, som nogen huskede at genstarte.