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

SSH vezujete na adresu tunela tokom postavljanja, radi, a nakon sljedećeg ponovnog pokretanja niko ne može da se prijavi dok neko ručno ne restartuje uslugu. Podaci za prijavu nisu problem. Daemon je od kernela tražio adresu koja još nije postojala, vezivanje nije uspjelo, a poruka se otkotrljala u zapisu podizanja. Ono što izgleda kao problem autentifikacije zapravo je problem redoslijeda pokretanja.

Šta greška vezivanja zaista govori

Slušajući socket mora se stvoriti na adresi koja postoji u tom trenutku. Kada se VPN interfejs kasnije pojavi, daemon konfigurisan da se veže samo na adresu tunela nema za šta da se prikači. Konfiguracija ostaje sintaksno 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. Uporedite vremensku oznaku neuspjelog vezivanja sa vremenskom oznakom dodjele adrese i redoslijed postaje očigledan.

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

Koji proces posjeduje port

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

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

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

Učinite spremnost eksplicitnom, ne spavanjem

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

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

Dodajte ExecStartPre komandu koja se ponavlja dok se adresa ne pojavi, ili poredajte jedinicu poslije određenog mrežnog cilja kojem pripada interfejs. Oba pristupa bilježe zavisnost negdje gdje sljedeći administrator može da je pročita. 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čni interfejs 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. Ponovo pokrenite mašinu s tunelom konfigurisanim da se podigne automatski i gledajte da li se slušalac pojavljuje bez intervencije.

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

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

Kriterij uspjeha je slušalac koji se pojavljuje pod svojom dokumentovanom zavisnošću, a ne onaj koji se neko sjetio restartovati.