systemd-socket-proxyd는 SSH SOCKS 터널보다 오래 살아남을 수 있다
소켓 전달 도우미의 수명 주기를 SSH 의존성과 맞추어 죽은 터널이 건강해 보이는 프런트 엔드를 남기지 않게 하세요.
SSH가 종료된 뒤에도 프런트 포트가 연결을 받아들인다면 세 유닛을 모두 확인하세요. 활성화 소켓, systemd-socket-proxyd 도우미, SSH가 만든 SOCKS 리스너는 수명이 서로 다릅니다.
| 소켓 | 도우미 | SSH | 해석 |
|---|---|---|---|
| 수신 중 | 비활성 | 비활성 | 정상적으로 수요를 기다리는 중일 수 있음 |
| 수신 중 | 활성 | 활성 | 프로세스는 있으나 최종 목적지의 건강은 아직 입증되지 않음 |
| 수신 중 | 활성 | 비활성 | 프런트 엔드가 백엔드 없이도 작업을 받을 수 있음 |
도우미와 SSH를 함께 시작한다고 이후의 정지 전이가 정의되지는 않습니다. 터널 없이 활성으로 남아서는 안 되는 도우미에 대해 systemd는 더 강한 관계를 문서화합니다.
[Unit]
BindsTo=ssh-socks.service
After=ssh-socks.service실제 설계에서는 적절한 유닛에 적용하세요. Requires= 와 순서는 관계의 일부만 다룹니다. 이미 활성인 프런트 엔드는 백엔드가 사라진 뒤 다시는 활성화를 일으키지 못할 수 있습니다. 실패한 유닛 상태와 시작 속도 제한도 확인하세요. 의존성은 그 제한을 무효화하지 않습니다.
다음으로 시작 준비 상태를 확립하세요. After= 는 작업 순서를 정할 뿐 Type=simple SSH 리스너의 준비 상태를 보장하지 않습니다. 고정 대기는 느린 인증 중에 실패할 수 있습니다. 필요한 리스너를 확립하는 시작 계약을 사용하세요. ExitOnForwardFailure=yes 는 전달 설정 실패를 잡아내며 이후 목적지 도달 가능성은 잡지 못합니다.
마지막으로 유휴 종료와 재활성화를 정의하세요. 전달 데몬의 유휴 종료 옵션은 활성 연결이 없음을 뜻하며 열린 연결에 바이트가 없음을 뜻하지 않습니다. 조용한 세션은 데몬을 활성으로 유지할 수 있습니다. 다음 수요는 필요한 서비스를 활성화해야 하고 재시작 루프는 제한적이고 가시적으로 유지되어야 합니다. 리스너를 다시 만들면 새 연결은 받지만 이전에 프록시된 TCP 세션은 복원되지 않습니다.