systemd-socket-proxyd kan overleve sin SSH SOCKS-tunnel

Tilpas livscyklussen for en socket-videresendelseshjælper til dens SSH-afhængighed, så en død tunnel ikke efterlader en front, der ser sund ud.

Hvis frontporten stadig accepterer forbindelser, efter at SSH er afsluttet, så undersøg alle tre units. Aktiveringssocketen, hjælperen systemd-socket-proxyd og den SOCKS-lytter, SSH opretter, har forskellige levetider:

SocketHjælperSSHFortolkning
LytterInaktivInaktivVenter muligvis normalt på efterspørgsel
LytterAktivAktivProcesser findes; sundheden for destinationen længere fremme er ikke bevist
LytterAktivInaktivFronten kan tage imod arbejde uden sin backend

At starte hjælperen og SSH sammen fastlægger ikke den senere stopovergang. For en hjælper, der ikke må forblive aktiv uden sin tunnel, dokumenterer systemd det stærkere forhold:

[Unit]
BindsTo=ssh-socks.service
After=ssh-socks.service

Anvend det på den relevante unit i det faktiske design. Requires= og rækkefølgen dækker kun en del af forholdet. En allerede aktiv front vil ellers måske aldrig udløse aktivering igen, efter at dens backend forsvinder. Kontroller også tilstanden for fejlede units og startrate-grænser; afhængigheder tilsidesætter ikke disse grænser.

Etabler derefter startparathed. After= ordner job, ikke paratheden af en SSH-lytter af typen Type=simple. En fast ventetid kan fejle under langsom godkendelse. Brug en startkontrakt, der etablerer den krævede lytter; ExitOnForwardFailure=yes fanger fejl i opsætningen af videresendelsen, ikke den senere tilgængelighed af destinationen.

Til sidst skal du definere tomgangsafslutning og genaktivering. Videresendelsesdaemonens tomgangsvalg handler om ingen aktive forbindelser, ikke om mangel på bytes på en åben forbindelse. En stille session kan holde den aktiv. Den næste efterspørgsel bør aktivere de krævede tjenester, og genstartsloops bør forblive begrænsede og synlige. At genskabe lytteren tillader nye forbindelser; det gendanner ikke gamle proxyede TCP-sessioner.

Relaterede artikler