SSH luister nie ná herbegin nie: die VPN-adres is te laat

Jy bind SSH tydens die opstelling aan die tonneladres, dit werk, en ná die volgende herbegin kan niemand aanmeld totdat iemand die diens met die hand herbegin nie. Gelootsbriefies is nie die probleem nie. Die daemon het die kernel om ’n adres gevra wat nog nie bestaan het nie, die binding het misluk, en die boodskap het in die selflaailog verbygerol. Wat soos ’n verifikasieprobleem lyk, is ’n probleem met die selflaai-volgorde.

Wat die bind-fout eintlik sê

’n Luistersokkie moet op ’n adres geskep word wat op daardie oomblik bestaan. Wanneer die VPN-koppelvlak later opkom, het ’n daemon wat gekonfigureer is om net aan die tonneladres te bind, niks om aan te heg nie. Die konfigurasie bly sintakties geldig; die omgewing was bloot nie gereed nie. ’n Diens wat sedert ’n handmatige begin loop, oefen nooit die selflaaipad nie, en daarom verskyn die fout eers by die volgende herbegin. Vergelyk die tydstempel van die bind-mislukking met die tydstempel van die adrestoewysing, en die volgorde word duidelik.

Konfigurasiegeldigheid en gereedheid tydens looptyd is afsonderlike eienskappe. Toets albei, want een van hulle misluk sonder om iets te sê.

Watter proses besit die poort

Die daemon is nie altyd die komponent wat die luisteraar skep nie. Sokkelaktivering skuif daardie verantwoordelikheid na ’n eenheid, en die herbegin van die daemon verander dan niks.

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

Die sokkellys wys watter proses die poort hou en op watter adres, terwyl die eenheid-uitvoer wys of daar hoegenaamd ’n sokkeleeneheid bestaan. Wanneer aktivering in werking is, hoort die adres in die sokkeleeneheid, en die daemon-lêer is nie gesaghebbend nie. Lees die selflaailog vir die werklike bind-fout eerder as om dit uit die simptoom af te lei. ’n Ontbrekende sokkeleeneheid beteken bloot die klassieke reëling, waar die daemon direk bind.

Maak gereedheid eksplisiet, nie ’n wagtyd nie

’n Vaste vertraging is ’n raaiskoot wat vinnige hardeware en stadige netwerke dieselfde behandel. Druk eerder die afhanklikheid uit: wag vir die adres en begin dan.

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

Voeg ’n ExecStartPre-opdrag by wat herhaal totdat die adres verskyn, of orden die eenheid ná die spesifieke netwerkteiken wat die koppelvlak besit. Albei benaderings teken die afhanklikheid êrens aan waar die volgende administrateur dit kan lees. Die lus het ’n tydperk nodig, anders laat ’n mislukte VPN ’n eenheid wat hang in plaas daarvan om ’n fout te rapporteer. Bevestig dan dat die daemon aan die tonneladres bind terwyl die gewone koppelvlak deur jou filterreëls bestuur bly.

Toets ’n skoon selflaai en ’n herverbinding

’n Handmatige herbegin nadat alles aanlyn is, bewys niks oor die selflaai-volgorde nie. Herbegin die masjien met die tonnel wat gekonfigureer is om outomaties op te kom, en kyk of die luisteraar sonder ingryping verskyn.

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

Laat sak dan die tonnel en stel dit weer op, want ’n herverbinding kan die adres verander en ’n hardgekodeerde binding sal dit nie volg nie. Hou ’n buitebandse herstelpad tydens toetsing, sodat ’n slegte volgorde-verandering jou nie van die host kan uitsluit nie.

Die sukseskriterium is ’n luisteraar wat onder sy gedokumenteerde afhanklikheid verskyn, nie een wat iemand onthou het om te herbegin nie.