systemd-socket-proxyd は SSH SOCKS トンネルより長く生き残ることがある
ソケット転送ヘルパーのライフサイクルを SSH 依存関係に合わせ、死んだトンネルが健全に見えるフロントエンドを残さないようにします。
SSH の終了後もフロントポートが接続を受け付けるなら、3 つのユニットすべてを調べてください。有効化ソケット、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 セッションは復元されません。