Dacă portul frontal acceptă conexiuni după ce SSH se închide, inspectați toate cele trei unități. Socketul de activare, ajutorul systemd-socket-proxyd și ascultătorul SOCKS creat de SSH au durate de viață diferite:

SocketAjutorSSHInterpretare
AscultăInactivInactivPoate aștepta normal cererea
AscultăActivActivProcesele există; sănătatea destinației următoare rămâne nedemonstrată
AscultăActivInactivFrontul poate accepta lucru fără backendul său

Pornirea împreună a ajutorului și a SSH nu definește tranziția ulterioară de oprire. Pentru un ajutor care nu trebuie să rămână activ fără tunelul său, systemd documentează o relație mai puternică:

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

Aplicați-o unității potrivite din proiectul real. Requires= și ordonarea rezolvă doar o parte a relației. Un front deja activ poate altfel să nu mai declanșeze niciodată activarea după ce backendul dispare. Verificați și starea unităților eșuate și limitele ratei de pornire; dependențele nu anulează acele limite.

Apoi stabiliți pregătirea la pornire. After= ordonează lucrări, nu pregătirea unui ascultător SSH Type=simple. O pauză fixă poate eșua în timpul autentificării lente. Folosiți un contract de pornire care stabilește ascultătorul necesar; ExitOnForwardFailure=yes prinde eșecul configurării redirecționării, nu accesibilitatea ulterioară a destinației.

În final, definiți ieșirea în repaus și reactivarea. Opțiunea de ieșire în repaus a daemonului de redirecționare privește absența conexiunilor active, nu lipsa octeților pe o conexiune deschisă. O sesiune liniștită îl poate menține activ. Următoarea cerere ar trebui să activeze serviciile necesare, iar buclele de repornire ar trebui să rămână limitate și vizibile. Recrearea ascultătorului admite conexiuni noi; nu restaurează sesiunile TCP vechi proxy-ate.

Articole similare