Что вы подразумеваете под «обратным» туннелем?
Параметр -R относится к дистанционно инициируемому туннелю, а не параметр -L, который относится к локально инициируемому туннелю.
Таким образом, с точки зрения клиента SSH, параметр -R будет прослушивать трафик на удаленном конце (что означает сервер SSH). Когда компьютер, на котором работает сервер SSH, получает трафик через указанный порт (1122), этот компьютер отправит эту информацию через программное обеспечение SSH. В частности, он отправит эту информацию через туннель SSH. Когда информация отправляется через туннель SSH, она шифруется, как и весь трафик SSH. Кроме того, к этой информации добавлено небольшое примечание, которое (перефразировано здесь, чтобы сказать) «отправляет трафик на локальный порт 5000».
Когда трафик на другом конце туннеля SSH (в этом примере мы сейчас говорим о компьютере, на котором работает клиент SSH) получает трафик, он видит примечание о том, куда будет идти трафик. Итак, этот компьютер достигает порта локального хоста 5000. Это момент времени, когда имя хоста «localhost» разрешается. Итак, в этом примере «localhost» будет ссылаться на клиента SSH. (Напротив, если вы используете вместо этого -L, использование «localhost», как этот, все равно будет интерпретироваться конечным получателем трафика через туннель, поэтому SSH-сервер будет интерпретировать фразу «localhost».)
Теперь лучше всего понять, почему туннель рушится. Я обычно использовал -L (локальные) туннели, но я просто игнорировал их в течение многих дней, прежде чем (иногда) решил использовать один, и он прекрасно работает. Я предположил бы, что туннель может быть разрушен любым концом. Проверьте обе стороны для регистрации. Вы можете проверить документацию OpenSSH, чтобы узнать, есть ли какое-то время ожидания, с которым вы имеете дело.
Если вы хотите пойти по неприемлемому пути обхода проблемы (вместо ее устранения), убив sshd и перезапустив его, вы можете сделать это. Как уже отмечалось, вы не хотите использовать, killall sshdпотому что может быть другое соединение sshd. Вы можете попытаться pkillисключить любую программу, подключающуюся к 203.0.113.10 (или это 10.34.23.12?) Или к номеру порта (1122), но, опять же, это может привести к ложным срабатываниям. У вас есть более безопасный способ обойти проблему; это даже включает ваш предложенный подход перезапуска сервера.
Вы можете использовать sshd с помощью пользовательского файла конфигурации ( -f configuration file) или указать информацию о конфигурации в командной строке (используя -o). например:
sshd -o PidFile /var/run/sshd-remPC-tunnel.pid
(Кроме того, вы должны включить другие необходимые параметры в этой командной строке.)
Это помещает идентификационный номер процесса в этот файл при запуске sshd. Тогда ты можешь:
kill $( cat /var/run/sshd-remPC-tunnel.pid )
(Примечание: вам, возможно, придется испортить права доступа. Я намеренно не забочусь об этом, чтобы сделать мой ответ простым. Убедитесь, что sshdможете создать файл, и вы можете успешно catего использовать, когда захотите kill. Запустите тесты и внесите все необходимые изменения.)
Примечание. Возможно, вы НЕ хотите просто автоматически перезапускать туннель каждые 5 минут (для автоматизации решения проблемы). Потому что, если у вас есть успешное соединение, это нарушит успешное соединение. Так что я думаю, что это будет сделано вручную.