systemd-socket-proxyd kan overleve SSH SOCKS-tunnelen sin
Tilpass livssyklusen til socket-videresendingshjelperen til SSH-avhengigheten, slik at en død tunnel ikke etterlater en front som ser sunn ut.
Hvis frontporten godtar tilkoblinger etter at SSH avsluttes, undersøk alle tre enhetene. Aktiveringssokkelen, systemd-socket-proxyd-hjelperen og SOCKS-lytteren som SSH opprettet, har ulike levetider:
| Sokkel | Hjelper | SSH | Tolkning |
|---|---|---|---|
| Lytter | Inaktiv | Inaktiv | Kan vente normalt på etterspørsel |
| Lytter | Aktiv | Aktiv | Prosesser finnes; helsetilstanden til neste destinasjon er fortsatt ubestemt |
| Lytter | Aktiv | Inaktiv | Frontenden kan ta imot arbeid uten backend |
Å starte hjelperen og SSH sammen definerer ikke overgangen ved senere stopp. For en hjelper som ikke må forbli aktiv uten tunnelen, dokumenterer systemd et sterkere forhold:
[Unit]
BindsTo=ssh-socks.service
After=ssh-socks.serviceBruk det på riktig enhet i den faktiske utformingen. Requires= og rekkefølge dekker bare en del av forholdet. En allerede aktiv frontend kan ellers aldri utløse aktivering igjen etter at backend forsvinner. Kontroller også tilstanden til mislykkede enheter og startfrekvensgrenser; avhengigheter overstyrer ikke disse grensene.
Deretter etablerer du startberedskap. After= ordner jobber, ikke beredskapen til en Type=simple SSH-lytter. En fast pause kan mislykkes under langsom autentisering. Bruk en startkontrakt som etablerer den nødvendige lytteren; ExitOnForwardFailure=yes fanger svikt i videresendingsoppsettet, ikke senere nåbarhet til destinasjonen.
Til slutt definerer du tomgangsavslutning og reaktivering. Videresendingsdaemonens tomgangsvalg gjelder ingen aktive tilkoblinger, ikke mangel på bytes på en åpen tilkobling. En stille økt kan holde den aktiv. Neste etterspørsel bør aktivere de nødvendige tjenestene, og omstartsløyfer bør forbli avgrensede og synlige. Å gjenopprette lytteren slipper inn nye tilkoblinger; det gjenoppretter ikke gamle proxyede TCP-økter.