Я настроил обратный туннель так:
function startconn () {
ssh -N -b ${SRCIP} -X -R ${REMOTEIP}:${REMOTEPORT}:${LOCALIP}:${LOCALPORT} root@${REMOTEIP} &
SSHPID=$!
echo "$SSHPID" > $PIDFILE
echo "Forwarding port ${REMOTEPORT} at ${REMOTEIP} to ${LOCALIP}:${LOCALPORT}"
}
Это пересылает REMOTEPORT @ REMOTEIP по резервной ссылке, доступной через сеть SRCIP (у меня есть вспомогательный сетевой адаптер с SRCIP == 192.168.5.2, который подключается к шлюзу резервной линии на 192.168.5.1).
Это работает хорошо, но есть проблема: если соединение ssh разрывается, например, при перезапуске шлюза и т.д., В общем, все, что нарушает соединение TCP/IP в сеансе ssh обратного туннеля, процесс sshd в REMOTEIP зависает, предотвращая повторное установление обратного туннель к этому порту (ниже 30200 - REMOTEPORT):
netstat -anp | grep 30200
tcp 0 0 0.0.0.0:30200 0.0.0.0:* LISTEN 8772/sshd: root
Единственное жизнеспособное решение, которое я вижу на данный момент, - это запись сценария переподключения на потерянное соединение с REMOTEIP и уничтожение процесса sshd "вручную" перед попыткой восстановить обратный туннель.
Есть ли какой-нибудь умный / менее громоздкий способ предотвратить удаленный процесс sshd, блокирующий порт REMOTEIP?