systemd-socket-proxyd kan överleva sin SSH SOCKS-tunnel
Anpassa livscykeln för socket-vidarebefordran till SSH-beroendet så att en död tunnel inte lämnar en front som ser frisk ut.
Om frontporten accepterar anslutningar efter att SSH avslutats, undersök alla tre enheterna. Aktiveringssocketen, systemd-socket-proxyd-hjälparen och SOCKS-lyssnaren som SSH skapade har olika livslängder:
| Socket | Hjälpare | SSH | Tolkning |
|---|---|---|---|
| Lyssnar | Inaktiv | Inaktiv | Kan vänta normalt på efterfrågan |
| Lyssnar | Aktiv | Aktiv | Processer finns; hälsan hos nästa destination är fortfarande obevisad |
| Lyssnar | Aktiv | Inaktiv | Fronten kan ta emot arbete utan sin backend |
Att starta hjälparen och SSH tillsammans definierar inte övergången vid senare stopp. För en hjälpare som inte får förbli aktiv utan sin tunnel dokumenterar systemd en starkare relation:
[Unit]
BindsTo=ssh-socks.service
After=ssh-socks.serviceTillämpa det på rätt enhet i den faktiska designen. Requires= och ordning löser bara en del av relationen. En redan aktiv front kan annars aldrig utlösa aktivering igen efter att dess backend försvinner. Kontrollera även tillståndet för misslyckade enheter och startfrekvensgränser; beroenden åsidosätter inte dessa gränser.
Ställ sedan in startberedskap. After= ordnar jobb, inte beredskapen hos en Type=simple SSH-lyssnare. En fast paus kan misslyckas vid långsam autentisering. Använd ett startkontrakt som etablerar den nödvändiga lyssnaren; ExitOnForwardFailure=yes fångar fel i vidarebefordringsinställningen, inte senare nåbarhet till destinationen.
Definiera slutligen tomgångsavslut och återaktivering. Vidarebefordringsdaemonens tomgångsalternativ gäller inga aktiva anslutningar, inte brist på byte i en öppen anslutning. En tyst session kan hålla den aktiv. Nästa efterfrågan bör aktivera de nödvändiga tjänsterna, och omstartsloopar bör förbli begränsade och synliga. Att återskapa lyssnaren släpper in nya anslutningar; det återställer inte gamla proxyade TCP-sessioner.