Який трафік програм насправді несе перенаправлення 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 — правильна форма, коли багатьом програмам потрібен той самий мережевий шлях. Жодне з них не дає всього, що досяжне з його віддаленого кінця.

Схожі статті