systemd-socket-proxyd kan overleve SSH SOCKS-tunnelen sin
Tilpass livssyklusen til hjelparen for socket-vidaresending til SSH-avhengnaden, slik at ein død tunnel ikkje lèt att ein front som ser frisk ut.
Viss frontporten tek imot tilkoplingar etter at SSH avsluttast, gransk alle tre einingane. Aktiveringssokkelen, systemd-socket-proxyd-hjelparen og SOCKS-lyttaren som SSH laga, har ulike levetider:
| Sokkel | Hjelpar | SSH | Tolking |
|---|---|---|---|
| Lyttar | Inaktiv | Inaktiv | Kan vente normalt på etterspurnad |
| Lyttar | Aktiv | Aktiv | Prosessar finst; helsa til neste destinasjon er framleis ikkje prova |
| Lyttar | Aktiv | Inaktiv | Fronten kan ta imot arbeid utan backend-en sin |
Å starte hjelparen og SSH saman definerer ikkje overgangen ved seinare stopp. For ein hjelpar som ikkje må vere aktiv utan tunnelen sin, dokumenterer systemd eit sterkare forhold:
[Unit]
BindsTo=ssh-socks.service
After=ssh-socks.serviceBruk det på rett eining i den faktiske utforminga. Requires= og rekkjefølgje dekkjer berre ein del av forholdet. Ein allereie aktiv front kan elles aldri utløyse aktivering igjen etter at backend-en forsvinn. Kontroller òg tilstanden til mislukka einingar og startfrekvensgrenser; avhengnader overstyrer ikkje desse grensene.
Deretter etablerer du startberedskap. After= ordnar jobbar, ikkje beredskapen til ein Type=simple SSH-lyttar. Ein fast pause kan mislukkast under langsam autentisering. Bruk ein startkontrakt som etablerer den nødvendige lyttaren; ExitOnForwardFailure=yes fangar svikt i vidaresendingsoppsettet, ikkje seinare nåbarheit til destinasjonen.
Til slutt definerer du tomgangsavslutning og reaktivering. Tomgangsvalet til vidaresendingsdaemonen gjeld ingen aktive tilkoplingar, ikkje mangel på bytes på ei open tilkopling. Ei stille økt kan halde han aktiv. Neste etterspurnad bør aktivere dei nødvendige tenestene, og omstartsløyfer bør halde seg avgrensa og synlege. Å gjenopprette lyttaren slepp inn nye tilkoplingar; det gjenopprettar ikkje gamle proxya TCP-økter.