SSH ne sluša nakon ponovnog pokretanja: VPN adresa kasni

Vežete SSH na adresu tunela tijekom postavljanja, radi, a nakon sljedećeg ponovnog pokretanja nitko se ne može prijaviti dok netko ručno ne restartuje uslugu. Podaci za prijavu nisu problem. Daemon je od kernela tražio adresu koja još nije postojala, povezivanje nije uspjelo, a poruka se otkotrljala u zapisu podizanja. Ono što izgleda kao problem autentifikacije zapravo je problem redoslijeda pokretanja.

Što pogreška povezivanja zapravo govori

Slušajući socket mora se stvoriti na adresi koja postoji u tom trenutku. Kada se VPN sučelje kasnije pojavi, daemon konfiguriran da se veže samo na adresu tunela nema za što se prikvačiti. Konfiguracija ostaje sintaktički ispravna; okruženje jednostavno nije bilo spremno. Usluga koja radi od ručnog pokretanja nikad ne prolazi put podizanja, zbog čega se kvar pojavljuje tek pri sljedećem restartu. Usporedite vremensku oznaku neuspjelog povezivanja s vremenskom oznakom dodjele adrese i redoslijed postaje očigledan.

Ispravnost konfiguracije i spremnost u radu odvojena su svojstva. Testirajte oboje, jer jedno od njih pada bez riječi.

Koji proces posjeduje port

Daemon nije uvijek komponenta koja stvara slušatelja. Aktivacija socketa prenosi tu odgovornost na jedinicu, a tada restart daemona ništa ne mijenja.

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

Popis socketova pokazuje koji proces drži port i na kojoj adresi, dok ispis jedinice pokazuje postoji li socket jedinica uopće. Kada je aktivacija u igri, adresa pripada socket jedinici i datoteka daemona nije mjerodavna. Čitajte zapis podizanja za stvarnu pogrešku povezivanja umjesto da je izvodite iz simptoma. Nedostatak socket jedinice jednostavno znači klasičan raspored, u kojem se daemon veže izravno.

Učinite spremnost eksplicitnom, ne spavanjem

Fiksno kašnjenje je pretpostavka koja brz hardver i spore mreže tretira isto. Umjesto toga izrazite ovisnost: pričekajte adresu, pa pokrenite.

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

Dodajte ExecStartPre naredbu koja se ponavlja dok se adresa ne pojavi, ili poredajte jedinicu nakon određenog mrežnog cilja kojem pripada sučelje. Oba pristupa bilježe ovisnost negdje gdje sljedeći administrator može to pročitati. Petlji treba tajmaut, inače neuspjeli VPN ostavlja jedinicu koja visi umjesto da prijavi kvar. Zatim potvrdite da daemon veže adresu tunela dok obično sučelje ostaje pod upravom vaših pravila filtriranja.

Testirajte čisto podizanje i ponovno povezivanje

Ručni restart nakon što je sve na mreži ne dokazuje ništa o redoslijedu podizanja. Ponovno pokrenite stroj s tunelom konfiguriranim da se podigne automatski i gledajte pojavljuje li se slušatelj bez intervencije.

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

Zatim oborite i ponovno uspostavite tunel, jer ponovno povezivanje može promijeniti adresu i tvrdo kodirano povezivanje neće je slijediti. Držite izvanpojasni put oporavka tijekom testiranja, da vas loša promjena redoslijeda ne zaključa izvan hosta.

Kriterij uspjeha je slušatelj koji se pojavljuje pod svojom dokumentiranom ovisnošću, a ne onaj koji se netko sjetio restartati.