Als de frontpoort verbindingen accepteert nadat SSH is gestopt, inspecteer dan alle drie de units. De activeringssocket, de systemd-socket-proxyd-helper en de door SSH gemaakte SOCKS-listener hebben verschillende levensduren:

SocketHelperSSHInterpretatie
LuistertInactiefInactiefWacht mogelijk normaal op vraag
LuistertActiefActiefProcessen bestaan; de gezondheid van de volgende bestemming is nog niet bewezen
LuistertActiefInactiefDe frontend kan werk aannemen zonder zijn backend

De helper en SSH samen starten definieert de latere stopovergang niet. Voor een helper die niet actief mag blijven zonder zijn tunnel, documenteert systemd een sterkere relatie:

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

Pas het toe op de juiste unit in het werkelijke ontwerp. Requires= en ordening dekken slechts een deel van de relatie. Een al actieve frontend kan anders nooit opnieuw activering uitlokken nadat zijn backend verdwijnt. Controleer ook de status van mislukte units en de startfrequentielimieten; afhankelijkheden overschrijven die limieten niet.

Stel vervolgens de startgereedheid vast. After= ordent taken, niet de gereedheid van een Type=simple SSH-listener. Een vaste slaap kan mislukken bij langzame authenticatie. Gebruik een startcontract dat de vereiste listener vaststelt; ExitOnForwardFailure=yes vangt fouten bij het opzetten van de forward, niet de latere bereikbaarheid van de bestemming.

Definieer ten slotte het idle-afsluiten en heraktivering. De idle-exitoptie van de forwarding-daemon gaat over geen actieve verbindingen, niet over een gebrek aan bytes op een open verbinding. Een stille sessie kan hem actief houden. De volgende vraag moet de vereiste diensten activeren, en herstartlussen moeten begrensd en zichtbaar blijven. De listener opnieuw aanmaken laat nieuwe verbindingen toe; het herstelt geen oude geproxiede TCP-sessies.

Gerelateerde artikelen