Какой трафик приложений на самом деле несёт перенаправление SSH?

Оболочка, локальное перенаправление, SOCKS и режим туннельного устройства предоставляют разные интерфейсы. Назовите тот, который может использовать ваше приложение, прежде чем сравнивать его с маршрутизируемым VPN.

Терминал подключается, появляется приглашение, и все согласны, что доступ по SSH работает. Затем клиент базы данных на ноутбуке всё ещё не может достучаться до частного хоста, и виноватой оказывается сессия. Построена была оболочка, а это один из четырёх совершенно разных интерфейсов, которые может предложить SSH. Сначала назовите интерфейс, затем проверьте, что приложение действительно его использует. Порядок важен, потому что каждый интерфейс отказывает по-своему.

Назовите интерфейс, прежде чем что-либо сравнивать

руководство клиента OpenSSH различает четыре механизма, которые легко перепутать. Оболочка или удалённая команда выполняется на узле SSH. Локальное перенаправление открывает слушающий сокет на клиенте и устанавливает дальнейшее соединение с удалённой стороны. Удалённое перенаправление делает наоборот, слушая на стороне сервера. Динамическое перенаправление предоставляет конечную точку SOCKS программам, которые умеют ею пользоваться.

  • Оболочка: программа работает на удалённой машине, локально ничего не слушает.
  • Локальное перенаправление: на вашем ноутбуке есть порт, удалённый узел устанавливает исходящее соединение.
  • Удалённое перенаправление: на удалённой стороне есть порт, трафик возвращается к вам.
  • Динамическое: прокси SOCKS на клиенте, используется только приложениями, понимающими прокси.

Ни одно из них не устанавливает маршрут. Программа, которая игнорирует настройки прокси, или говорит по UDP, или сама разрешает имена, не затрагивается активной сессией SSH. Это не дефект SSH; это охват выбранного вами интерфейса.

Локальное, удалённое и динамическое перенаправления различаются тем, кто слушает

Различие, определяющее большинство случаев, — кто владеет слушающим сокетом. При локальном перенаправлении слушает клиент, а дальний конец набирает адресата, поэтому адрес назначения разрешается с точки зрения сервера. При удалённом перенаправлении слушает сервер, а соединение переносится обратно на вашу сторону, и так вы открываете локальную службу, не публикуя её напрямую.

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

Первая команда привязывает порт 5432 на ноутбуке и перенаправляет его к базе данных так, как она видна с бастиона. Вторая создаёт прокси SOCKS на порту 1080. Третья команда подтверждает, какие процессы действительно слушают, и это единственное доказательство того, что перенаправление существует, а не тихо отказало из-за конфликта портов.

Динамическое перенаправление заслуживает отдельного предупреждения: оно охватывает только приложения, соблюдающие SOCKS. Браузер можно на него направить, инструменту командной строки можно сказать использовать его, но драйвер базы данных с собственным стеком соединений обычно этого не может. Предположение, что теперь каждая программа на машине использует туннель, — самая частая ошибка во всей этой области.

Режим туннельного устройства — единственное настоящее сетевое исключение

OpenSSH также поддерживает перенаправление туннельного устройства -w, которое передаёт интерфейс «точка-точка» вместо прослушивателя TCP. Это настоящий сетевой туннель, и он настраивается намеренно, а не как побочный эффект открытия оболочки.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

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

Даже тогда туннель заканчивается на удалённом узле. Любая защита, которую обеспечил транспорт SSH, заканчивается там, а дальнейшее соединение — отдельный переход. У шлюза VPN такая же форма границы, поэтому сравнение должно быть об охвате и завершении, а не о том, какой инструмент сильнее. Громкое называние этой границы также закрывает спор о том, «шифрует ли туннель всё», потому что явно не шифрует.

Проверьте, что ваше приложение использует построенный вами интерфейс

Проверка выполняется для каждого приложения, а не для сессии. Работающее перенаправление доказывает, что порт привязан и дальняя сторона может набирать; оно не доказывает, что нужная вам программа подключилась через него.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

Первая команда отправляет запрос через конечную точку SOCKS с разрешением имени узла удалённо, а вторая проверяет перенаправленный порт базы данных при всё ещё обязательном TLS. Запустите те же тесты с остановленным перенаправлением, чтобы убедиться, что они не проходят, потому что тест, проходящий обоими способами, никогда не использовал туннель.

Затем сравните с маршрутизируемым VPN только по тем измерениям, которые важны: какие адресаты охвачены, какие протоколы работают, где заканчивается защита и кто должен одобрить доступ. Перенаправление одной службы может быть более узким и лучшим ответом, тогда как VPN — правильная форма, когда многим приложениям нужен один и тот же сетевой путь. Ни один из них не даёт всего, что достижимо с его дальнего конца.

Похожие статьи