SSH lauschtert net nom Neistart: d’VPN-Adress kënnt ze spéit
En Déngscht, deen un eng Tunnell-Adress gebonnen ass, brauch déi Adress bei der Bindung. Kontrolléiert den Eegentemer vum Lauschterer, d’Startreihenfolg an de Bindungsfehler, ier Dir Schlësselen ännert.
Dir bënnt SSH während der Installatioun un d’Tunnell-Adress, et funktionnéiert, an nom nächsten Neistart kann keen sech aloggen, bis een den Déngscht vun Hand nei start. D’Zougangsdaten sinn net de Problem. Den Daemon huet de Kernel no enger Adress gefrot, déi et nach net gouf, d’Bindung ass gescheitert, an d’Message ass am Startlog laanscht gerullt. Wat wéi en Authentifikatiounsproblem ausgesäit, ass e Problem vun der Startreihenfolg.
Wat de Bindungsfehler tatsächlech seet
En lauschterende Socket muss op enger Adress erstallt ginn, déi an deem Moment existéiert. Wann d’VPN-Interface méi spéit optrëtt, huet en Daemon, deen konfiguréiert ass just un d’Tunnell-Adress ze bannen, näischt fir sech unzehaangen. D’Konfiguratioun bleift syntaktesch valabel; d’Ëmwelt war einfach net prett. En Déngscht, dee säit engem manuelle Start leeft, duerchleeft ni de Startwee, dofir erschéngt de Feeler eréischt beim nächsten Neistart. Vergläicht den Zäitstempel vun der gescheiterter Bindung mat deem vun der Adresszouweisung, an d’Reihenfolg gëtt evident.
Konfiguratiounsvaliditéit a Runtime-Prett sinn getrennte Eegenschaften. Test béides, well eng dovun ouni eppes ze soen feelt.
Wee Prozess den Port besëtzt
Den Daemon ass net ëmmer de Komponent, deen de Lauschterer erstallt. Socket-Aktivatioun verréckelt déi Verantwortung op eng Eenheet, an duerno ännert en Neistart vum Daemon näischt.
ss -ltnp 'sport = :22'
systemctl cat ssh.socketD’Socket-Lëscht weist, wee Prozess den Port hält an op wien Adress, während den Eenheets-Dump weist, ob iwwerhaapt eng Socket-Eenheet existéiert. Wann Aktivatioun am Spill ass, gehéiert d’Adress an d’Socket-Eenheet an d’Daemon-Datei ass net autoritativ. Liest de Startlog fir de richtegen Bindungsfehler, amplaz en aus dem Symptom ofzeleeden. Eng feelend Socket-Eenheet bedeit einfach déi klassesch Arrangement, wou den Daemon direkt bënnt.
Maacht Prettheet explizit, net en Schlof
Eng fest Verzögerung ass eng Vermutung, déi séier Hardware a lues Netzwierker gläich behandelt. Dréckt amplaz d’Ofhängegkeet aus: waart op d’Adress, dann start.
ip -4 addr show dev tun0
systemctl edit ssh.serviceFüügt en ExecStartPre-Befehl derbäi, dee sech widderhëlt bis d’Adress erschéngt, oder ordnet d’Eenheet no deem spezifeschen Netzwierkzil, deem d’Interface gehéiert. Béid Approche notéieren d’Ofhängegkeet op enger Plaz, déi den nächsten Administrateur ka liesen. D’Schleif brauch en Timeout, soss hannerléisst en feelgeschloene VPN eng Eenheet, déi hängt, amplaz e Feeler ze mellen. Bestätegt duerno, datt den Daemon d’Tunnell-Adress bënnt, während d’gewéinlech Interface ënner Äre Filterregelen bleift.
Test en proppere Start an eng Reconnect
En manuellen Neistart, nodeems alles online ass, beweist näischt iwwer d’Startreihenfolg. Start d’Maschinn nei, mat dem Tunnell konfiguréiert fir automatesch eropzekommen, a beobacht, ob de Lauschterer ouni Agrëff erschéngt.
systemctl status ssh.service
ss -ltnp 'sport = :22'Dann zitt den Tunnell of a riicht en erëm an, well eng Reconnect d’Adress ka änneren an eng haart kodéiert Bindung wäert et net verfollegen. Halt während dem Testen en Out-of-Band-Recovery-Wee, sou datt eng schlecht Reihenfolgenännerung Iech net vum Host ka aussperren.
D’Erfolgskriterium ass en Lauschterer, deen ënner senger dokumentéierter Ofhängegkeet erschéngt, net een, un deen een sech beim Neistart erënnert huet.