SSH lyssnar inte efter omstart: VPN-adressen kommer för sent

Du binder SSH till tunneladressen under installationen, det fungerar, och efter nästa omstart kan ingen logga in förrän någon startar om tjänsten manuellt. Inloggningsuppgifterna är inte problemet. Daemonen bad kärnan om en adress som ännu inte fanns, bindningen misslyckades och meddelandet rullade förbi i startloggen. Det som ser ut som ett autentiseringsproblem är ett problem med startordningen.

Vad bindningsfelet faktiskt säger

En lyssnande socket måste skapas på en adress som finns i det ögonblicket. När VPN-gränssnittet dyker upp senare har en daemon som är konfigurerad att bara binda till tunneladressen inget att fästa vid. Konfigurationen förblir syntaktiskt giltig; miljön var helt enkelt inte redo. En tjänst som har kört sedan en manuell start går aldrig igenom startvägen, och därför visar sig felet först vid nästa omstart. Jämför tidsstämpeln för den misslyckade bindningen med tidsstämpeln för adresstilldelningen, och ordningen blir uppenbar.

Konfigurationsgiltighet och driftsberedskap är separata egenskaper. Testa båda, eftersom en av dem misslyckas utan att säga något.

Vilken process äger porten

Daemonen är inte alltid den komponent som skapar lyssnaren. Socketaktivering flyttar det ansvaret till en unit, och då ändrar en omstart av daemonen ingenting.

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

Socketlistan visar vilken process som håller porten och på vilken adress, medan unit-dumpen visar om det överhuvudtaget finns en socket-unit. När aktivering är inblandad hör adressen hemma i socket-uniten och daemonfilen är inte auktoritativ. Läs startloggen för det egentliga bindningsfelet i stället för att sluta dig till det från symptomet. En saknad socket-unit betyder helt enkelt den klassiska ordningen, där daemonen binder direkt.

Gör beredskapen explicit, inte en sömn

En fast fördröjning är en gissning som behandlar snabb hårdvara och långsamma nätverk likadant. Uttryck i stället beroendet: vänta på adressen och starta sedan.

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

Lägg till ett ExecStartPre-kommando som upprepas tills adressen dyker upp, eller ordna uniten efter det specifika nätmål som äger gränssnittet. Båda metoderna registrerar beroendet någonstans där nästa administratör kan läsa det. Loopen behöver en timeout, annars lämnar en misslyckad VPN en unit som hänger sig i stället för att rapportera ett fel. Bekräfta sedan att daemonen binder tunneladressen medan det vanliga gränssnittet fortsatt styrs av dina filterregler.

Testa en ren start och en återanslutning

En manuell omstart efter att allt är online bevisar ingenting om startordningen. Starta om maskinen med tunneln konfigurerad att komma upp automatiskt och se om lyssnaren dyker upp utan ingripande.

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

Släpp sedan tunneln och återupprätta den, eftersom en återanslutning kan ändra adressen och en hårdkodad bindning följer inte med. Behåll en återställningsväg utanför bandet under testningen, så att en dålig ordningsändring inte kan låsa dig ute från värden.

Framgångskriteriet är en lyssnare som dyker upp under sitt dokumenterade beroende, inte en som någon kom ihåg att starta om.