Se o porto frontal aínda acepta conexións despois de que SSH saia, revise as tres unidades. O socket de activación, o axudante systemd-socket-proxyd e o oínte SOCKS creado por SSH teñen vidas distintas:

SocketAxudanteSSHInterpretación
EscoitaInactivoInactivoPode estar agardando demanda con normalidade
EscoitaActivoActivoHai procesos; a saúde do destino final segue sen probar
EscoitaActivoInactivoA interface pode aceptar traballo sen o seu backend

Arrancar o axudante e SSH xuntos non define a transición posterior de parada. Para un axudante que non debe permanecer activo sen o seu túnel, systemd documenta a relación máis forte:

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

Aplíquea á unidade axeitada no deseño real. Requires= e a orde só cobren parte da relación. Unha interface xa activa podería non volver disparar a activación tras desaparecer o seu backend. Revise tamén o estado das unidades fallidas e os límites de frecuencia de arranque; as dependencias non anulan eses límites.

Despois estableza a preparación de arranque. After= ordena tarefas, non a preparación dun oínte SSH Type=simple. Unha espera fixa pode fallar durante unha autenticación lenta. Use un contrato de arranque que estableza o oínte necesario; ExitOnForwardFailure=yes detecta o fallo da configuración do reenvío, non a accesibilidade posterior do destino.

Por último, defina a saída por inactividade e a reactivación. A opción de saída por inactividade do daemon de reenvío refírese á ausencia de conexións activas, non á falta de bytes nunha conexión aberta. Unha sesión silenciosa pode mantelo activo. A seguinte demanda debería activar os servizos necesarios, e os bucles de reinicio deberían seguir limitados e visibles. Recrear o oínte admite conexións novas; non restaura as sesións TCP antigas que pasaban polo proxy.

Artigos relacionados