SSH nu ascultă după repornire: adresa VPN sosește târziu

În timpul configurării legați SSH de adresa tunelului, funcționează, iar după următoarea repornire nimeni nu se poate conecta până când cineva repornește serviciul manual. Acreditările nu sunt problema. Daemonul a cerut nucleului o adresă care încă nu exista, legarea a eșuat, iar mesajul a trecut prin jurnalul de pornire. Ceea ce pare o problemă de autentificare este o problemă de ordine a pornirii.

Ce spune de fapt eroarea de legare

Un socket de ascultare trebuie creat pe o adresă care există în acel moment. Când interfața VPN apare mai târziu, un daemon configurat să se lege doar de adresa tunelului nu are la ce să se atașeze. Configurația rămâne sintactic validă; mediul pur și simplu nu era pregătit. Un serviciu care rulează de la o pornire manuală nu parcurge niciodată calea de pornire, de aceea defecțiunea apare doar la următoarea repornire. Comparați marcajul de timp al legării eșuate cu marcajul de timp al atribuirii adresei, iar ordinea devine evidentă.

Validitatea configurației și disponibilitatea la rulare sunt proprietăți separate. Testați-le pe amândouă, pentru că una dintre ele eșuează fără să spună nimic.

Ce proces deține portul

Daemonul nu este întotdeauna componenta care creează ascultătorul. Activarea prin socket mută această responsabilitate către o unitate, iar atunci repornirea daemonului nu schimbă nimic.

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

Lista de socketuri arată ce proces deține portul și pe ce adresă, în timp ce dumpul unității arată dacă există deloc o unitate socket. Când activarea este în joc, adresa aparține unității socket, iar fișierul daemonului nu este autoritar. Citiți jurnalul de pornire pentru eroarea reală de legare în loc să o deduceți din simptom. O unitate socket lipsă înseamnă pur și simplu aranjamentul clasic, în care daemonul se leagă direct.

Faceți disponibilitatea explicită, nu o așteptare

O întârziere fixă este o presupunere care tratează la fel hardware-ul rapid și rețelele lente. În schimb, exprimați dependența: așteptați adresa, apoi porniți.

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

Adăugați o comandă ExecStartPre care se repetă până când adresa apare, sau ordonați unitatea după ținta de rețea specifică căreia îi aparține interfața. Ambele abordări înregistrează dependența undeva unde următorul administrator o poate citi. Bucla are nevoie de un timeout, altfel un VPN eșuat lasă o unitate blocată în loc să raporteze o defecțiune. Apoi confirmați că daemonul leagă adresa tunelului în timp ce interfața obișnuită rămâne sub regulile dumneavoastră de filtrare.

Testați o pornire curată și o reconectare

O repornire manuală după ce totul este online nu demonstrează nimic despre ordinea de pornire. Reporniți mașina cu tunelul configurat să pornească automat și urmăriți dacă ascultătorul apare fără intervenție.

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

Apoi coborâți și restabiliți tunelul, pentru că o reconectare poate schimba adresa și o legare codificată rigid nu o va urma. Păstrați o cale de recuperare în afara benzii în timpul testării, astfel încât o schimbare proastă de ordine să nu vă poată bloca în afara gazdei.

Criteriul de succes este un ascultător care apare sub dependența sa documentată, nu unul pe care cineva și-a amintit să îl repornească.