Обратный SSH-туннель доступен только на сервере: разбираем адрес привязки

Разработчик поднял обратный SSH-туннель с закрытого стенда на диагностический сервер. На самом сервере панель открывается, а с соседней машины — нет. Это может быть штатной границей: удалённый слушатель привязан к loopback. Перенаправление работает, просто его область доступности отличается от ожидания.

Разберите направление

ssh -N -o ExitOnForwardFailure=yes -R 127.0.0.1:19000:127.0.0.1:9000 operator@relay.example

Команда запускается на закрытом стенде. На relay появляется слушатель 127.0.0.1:19000. Входящий в него трафик передаётся по SSH обратно на машину клиента, а уже она соединяется с собственным 127.0.0.1:9000. Последний loopback относится к стенду, не к relay.

Проверять приложение следует сначала на relay через локальный порт. Если это работает, туннель выполнил свою задачу. Недоступность 19000 с соседней машины не доказывает сетевую поломку: для loopback-слушателя она ожидаема.

Узнайте фактическую привязку

ss -ltn 'sport = :19000'

Выполните команду на relay в рамках разрешённого доступа. В локальном адресе будет видно, слушает ли порт на 127.0.0.1, конкретном интерфейсе или всех адресах. Не делайте вывод только по успешно завершившемуся SSH: серверная политика может ограничивать адрес привязки перенаправлений.

За возможность внешней привязки отвечает, среди прочего, GatewayPorts на SSH-сервере. Значение clientspecified позволяет клиенту запрашивать конкретный bind-адрес; другие значения задают иное поведение. Изменять эту политику должен владелец relay с пониманием, какие обратные туннели разрешены. Запрос 0.0.0.0 в клиентской команде сам по себе не отменяет серверные ограничения.

Выберите нужную аудиторию порта

Для личной диагностики оставьте loopback. Другой инженер может зайти на relay штатным SSH или построить свой локальный туннель к этому порту. Так обратное перенаправление не становится неожиданной внешней публикацией стенда.

Если панель должна обслуживать несколько клиентов напрямую, заранее определите интерфейс, разрешённые источники, авторизацию приложения и срок существования доступа. После согласованной настройки проверьте слушатель и запрос с разрешённой машины. Отдельно проверьте источник, которому доступ не полагается. Это подтверждает границу, а не только работоспособность панели.

ExitOnForwardFailure сообщает о неудаче установки перенаправления, но не проверяет будущий сервис на 9000. Если приложение на стенде остановлено, слушатель на relay может существовать, а каждый запрос будет завершаться ошибкой открытия канала. В таком случае исправляйте конечное приложение, не расширяйте адрес привязки.

По завершении эксперимента остановите клиентский SSH-сеанс и убедитесь, что слушатель исчез. В записи диагностики сохраните, на какой машине запускалась каждая команда: обратные туннели особенно легко перепутать по одному номеру порта.

Научитесь объяснять путь до внутреннего сервиса. Откройте программу Linux и Bash для DevOps-инженеров. Работа с доступами, сетью и портами на учебном сервере поможет проверять такую схему по шагам и управлять её областью доступности.

Ещё по теме

• Внутренняя панель через SSH-туннель: где открывается порт и кто идёт к сервису
• После переустановки сервера изменился SSH host key: как обновить доверие