SSH luistert niet na herstart: het VPN-adres komt te laat

Je bindt SSH tijdens de installatie aan het tunneladres, het werkt, en na de volgende herstart kan niemand inloggen tot iemand de dienst handmatig herstart. De inloggegevens zijn niet het probleem. De daemon vroeg de kernel om een adres dat er nog niet was, de binding mislukte, en het bericht schoof voorbij in het opstartlogboek. Wat eruitziet als een authenticatieprobleem is een probleem met de opstartvolgorde.

Wat de bindfout werkelijk zegt

Een luisterende socket moet worden aangemaakt op een adres dat op dat moment bestaat. Wanneer de VPN-interface later verschijnt, heeft een daemon die alleen aan het tunneladres mag binden niets om zich aan vast te hechten. De configuratie blijft syntactisch geldig; de omgeving was simpelweg niet gereed. Een dienst die sinds een handmatige start draait, doorloopt nooit het opstartpad, waardoor de fout pas bij de volgende herstart optreedt. Vergelijk de tijdstempel van de mislukte binding met die van de adrestoewijzing, en de volgorde wordt duidelijk.

Configuratiegeldigheid en gereedheid tijdens runtime zijn aparte eigenschappen. Test beide, want een van de twee faalt zonder iets te zeggen.

Welk proces de poort bezit

De daemon is niet altijd het onderdeel dat de luisteraar aanmaakt. Socketactivering verplaatst die verantwoordelijkheid naar een unit, en dan verandert een herstart van de daemon niets.

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

De socketlijst toont welk proces de poort vasthoudt en op welk adres, terwijl de unit-dump toont of er überhaupt een socket-unit bestaat. Als activering in het spel is, hoort het adres in de socket-unit en is het daemonbestand niet gezaghebbend. Lees het opstartlogboek voor de echte bindfout in plaats van die uit het symptoom af te leiden. Een ontbrekende socket-unit betekent simpelweg de klassieke opstelling, waarbij de daemon rechtstreeks bindt.

Maak gereedheid expliciet, geen slaap

Een vaste vertraging is een gok die snelle hardware en trage netwerken gelijk behandelt. Druk in plaats daarvan de afhankelijkheid uit: wacht op het adres en start dan.

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

Voeg een ExecStartPre-opdracht toe die zich herhaalt tot het adres verschijnt, of orden de unit na het specifieke netwerkdoel dat de interface bezit. Beide benaderingen leggen de afhankelijkheid vast op een plek die de volgende beheerder kan lezen. De lus heeft een time-out nodig, anders laat een mislukte VPN een unit achter die blijft hangen in plaats van een fout te melden. Bevestig daarna dat de daemon het tunneladres bindt terwijl de gewone interface onder uw filterregels blijft.

Test een schone start en een herverbinding

Een handmatige herstart nadat alles online is bewijst niets over de opstartvolgorde. Herstart de machine met de tunnel geconfigureerd om automatisch op te komen en kijk of de luisteraar zonder ingrijpen verschijnt.

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

Laat de tunnel dan vallen en herstel hem, want een herverbinding kan het adres wijzigen en een hardgecodeerde binding volgt dat niet. Houd tijdens het testen een buitenbandse herstelroute aan, zodat een slechte volgordewijziging u niet buiten de host kan sluiten.

Het succescriterium is een luisteraar die onder zijn gedocumenteerde afhankelijkheid verschijnt, niet een die iemand nog herinnerde te herstarten.