Si el port frontal encara accepta connexions després que SSH surti, reviseu les tres unitats. El socket d'activació, l'auxiliar systemd-socket-proxyd i l'oient SOCKS creat per SSH tenen durades diferents:

SocketAuxiliarSSHInterpretació
EscoltaInactiuInactiuPotser espera normalment la demanda
EscoltaActiuActiuHi ha processos; però la salut de la destinació final no està provada
EscoltaActiuInactiuLa interfície pot acceptar feina sense el seu rerefons

Engegar l'auxiliar i SSH alhora no defineix la transició posterior d'aturada. Per a un auxiliar que no ha de romandre actiu sense el túnel, systemd documenta la relació més forta:

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

Apliqueu-la a la unitat adequada en el disseny real. Requires= i l'ordenació només cobreixen part de la relació. Una interfície ja activa potser no tornarà a provocar mai l'activació després que desaparegui el seu rerefons. Reviseu també l'estat de les unitats fallides i els límits de freqüència d'inici; les dependències no anul·len aquests límits.

Després establiu la preparació d'inici. After= ordena tasques, no la preparació d'un oient SSH Type=simple. Una espera fixa pot fallar durant una autenticació lenta. Feu servir un contracte d'inici que estableixi l'oient necessari; ExitOnForwardFailure=yes detecta la fallada de la configuració del reenviament, no l'abast posterior de la destinació.

Finalment, definiu la sortida per inactivitat i la reactivació. L'opció de sortida per inactivitat del dimoni de reenviament fa referència a l'absència de connexions actives, no a la manca de bytes en una connexió oberta. Una sessió tranquil·la el pot mantenir actiu. La propera demanda hauria d'activar els serveis necessaris, i els bucles de reinici haurien de romandre limitats i visibles. Recrear l'oient admet connexions noves; no restaura les sessions TCP antigues que passaven pel proxy.

Articles relacionats