SSH ne aŭskultas post restartiĝo: la VPN-adreso malfruas

Vi ligas SSH al la tunela adreso dum la agordo, ĝi funkcias, kaj post la sekva restartiĝo neniu povas ensaluti ĝis iu permane restartas la servon. La akreditaĵoj ne estas la problemo. La demono petis de la kerno adreson, kiu ankoraŭ ne ekzistis, la ligo malsukcesis, kaj la mesaĝo ruliĝis preter en la starta protokolo. Tio, kio aspektas kiel aŭtentiga problemo, estas problemo de starta ordo.

Kion la liga eraro efektive diras

Aŭskultanta ingo devas esti kreita sur adreso, kiu ekzistas en tiu momento. Kiam la VPN-interfaco aperas poste, demono agordita ligi nur al la tunela adreso havas nenion al kio alkroĉiĝi. La agordo restas sintakse valida; la medio simple ne estis preta. Servo, kiu funkcias ekde permana starto, neniam trapasas la startan vojon, kaj tial la difekto aperas nur ĉe la sekva restartiĝo. Komparu la tempomarkon de la malsukcesa ligo kun la tempomarko de la adresa atribuo, kaj la ordo fariĝas evidenta.

Agorda valideco kaj rultempa preteco estas apartaj ecoj. Testu ambaŭ, ĉar unu el ili malsukcesas sen diri ion.

Kiu procezo posedas la pordon

La demono ne ĉiam estas la komponanto, kiu kreas la aŭskultanton. Inga aktivigo translokigas tiun respondecon al unuo, kaj restartigi la demonon tiam ŝanĝas nenion.

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

La inga listo montras, kiu procezo tenas la pordon kaj sur kiu adreso, dum la unua eligo montras, ĉu inga unuo entute ekzistas. Kiam aktivigo estas en ludo, la adreso apartenas al la inga unuo kaj la demona dosiero ne estas aŭtoritata. Legu la startan protokolon por la reala liga eraro anstataŭ deduki ĝin el la simptomo. Mankanta inga unuo simple signifas la klasikan aranĝon, kie la demono ligas rekte.

Faru pretecon eksplicita, ne dormo

Fiksa prokrasto estas konjekto, kiu traktas rapidan aparataron kaj malrapidajn retojn same. Esprimu la dependecon anstataŭe: atendu la adreson, tiam startu.

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

Aldonu ExecStartPre-komandon, kiu ripetiĝas ĝis la adreso aperas, aŭ ordigu la unuon post la specifa reta celo, kiu posedas la interfacon. Ambaŭ aliroj registras la dependecon ie, kie la sekva administranto povas legi ĝin. La buklo bezonas tempolimon, alie malsukcesa VPN lasas unuon, kiu pendas anstataŭ raporti difekton. Poste konfirmu, ke la demono ligas la tunelan adreson dum la ordinara interfaco restas regata de viaj filtraj reguloj.

Testu puran starton kaj rekonekton

Permana restarto post kiam ĉio estas enrete pruvas nenion pri la starta ordo. Restartu la maŝinon kun la tunelo agordita ekleviĝi aŭtomate kaj observu, ĉu la aŭskultanto aperas sen interveno.

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

Poste faligu kaj restarigu la tunelon, ĉar rekonekto povas ŝanĝi la adreson kaj malmola kodita ligo ne sekvos ĝin. Konservu eksterbendan reakira vojon dum testado, por ke malbona orda ŝanĝo ne povu ŝlosi vin ekster la gastiganto.

La sukceskriterio estas aŭskultanto, kiu aperas sub sia dokumentita dependeco, ne unu, kiun iu memoris restartigi.