Дайте віддаленому Pi SOCKS-проксі через ваш SSH-клієнт

Віддалене динамічне перенаправлення розміщує SOCKS-слухач на Pi і виконує наступне з'єднання з затвердженого VPN-шляху вашого ноутбука. Без другого SSH-сервера.

Ви виходите з того, що SOCKS-проксі має працювати там, де мережевий доступ уже є. OpenSSH уміє розмістити слухач зовсім в іншому місці. Віддалене динамічне перенаправлення відкриває порт SOCKS на віддаленому хості й починає кожне з'єднання з вашого локального SSH-клієнта, який несе затверджений VPN-шлях ноутбука. Pi отримує обмежений проксі; він не успадковує ваш тунель чи ваші привілеї.

Слухач і сторона, з якої виникає з'єднання, можуть відрізнятися

Звичайний ssh -D 1080 запускає слухач на вашій власній машині й надсилає з'єднання звідти. Віддалене динамічне перенаправлення перевертає це: слухач з'являється на віддаленому хості, і кожне прийняте ним з'єднання відкривається з локального боку. посібник клієнта OpenSSH описує -R без фіксованого призначення саме як таку схему SOCKS4/5.

Підтримувана команда з ноутбука виглядає так, причому обліковий запис, хости й порт вважаються заповнювачами:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

Три деталі роблять там корисну роботу. -S none утримує сеанс осторонь від спільного контрольного майстра, ExitOnForwardFailure швидко завершується помилкою замість того, щоб залишити вас із напіввідкритим сеансом, а PermitRemoteOpen обмежує, куди може дістатися віддалений слухач. Використовуйте авторизований обліковий запис Pi і перевірте ключ хоста, перш ніж будь-що з цього додавати.

Що насправді розкриває віддалений слухач

Перевірте політику перенаправлення сервера, перш ніж покладатися на слухач. З GatewayPorts no віддалене перенаправлення лишається прив'язаним до loopback, і це саме той вплив, який вам потрібен. Сервер, налаштований примусово застосовувати узагальнене перенаправлення, публікує той самий порт на кожному інтерфейсі, що перетворює особистий проксі на щось доступне локальній мережі.

Loopback також не є межею між користувачами. Інший процес на Pi може підключитися до 127.0.0.1:1080, якщо знає порт, тож локальні облікові записи Pi і все, що на ньому працює, є частиною вашої схеми доступу. Це причина тримати список призначень вузьким, а не причина пропускати перевірку політики.

Тримайте дозволене призначення конкретним для застосунку, до якого ви прагнете. Заміна його необмеженим перенаправленням, щоб запрацювала стороння програма, розширює шлях далеко за межі проблеми, з якої ви почали. Список призначень також фіксує, для чого був сеанс, і це допомагає тому, хто перевірятиме його пізніше. Запишіть його поруч з обліковим записом, який використовували.

Проведіть один застосунок через проксі

Клієнт на Pi, який розуміє проксі, тоді може надіслати запит. Префікс socks5h передає ім'я призначення проксі, тож пошук і з'єднання відбуваються обидва на боці ноутбука, і це збігається з названим призначенням у PermitRemoteOpen:

curl --proxy socks5h://127.0.0.1:1080 \
  --noproxy '' https://app.corp.example/

Збережіть звичайну перевірку сертифіката й власну автентифікацію застосунку. Проксі змінює те, де встановлюється TCP-з'єднання; він не робить неавтентифікований сервіс безпечним і не перетворює самопідписаний кінцевий пункт на довірений.

Ноутбуку все ще потрібні власний маршрут і доступ до резолвера як до SSH-сервера, так і до застосунку. Трафік його SSH-клієнта має обиратися затвердженою політикою VPN, а виняток split-tunnel може надіслати цей трафік іншим шляхом, ніж перевірений.

Доведіть шлях і закрийте його

Переконайтеся, що слухач існує там, де ви очікуєте, і що відповідає лише передбачене призначення:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

ExitOnForwardFailure може довести, що перенаправлення встановлено, і все одно не може засвідчити, що вхід у застосунок нижче за потоком успішний. Перевіряйте застосунок, а не лише порт. Слухач, який приймає, а потім провалює кожен запит, зазвичай означає, що ім'я призначення або маршрут ноутбука неправильні, а не що тунель не вдався.

Ця схема несе лише TCP. UDP, ICMP і програми, що ігнорують налаштування проксі, лишаються поза нею, а перенаправлення закінчується тієї миті, коли закінчується сеанс SSH. Зупиніть цей сеанс, коли завершите, і вилучіть налаштування проксі, яке додали до застосунку.

Для постійного доступу використовуйте натомість підтримувану реєстрацію власника мережі або керований шлюз. Зворотний проксі — невідповідний інструмент для обходу обмежень VPN щодо пристроїв чи ресурсів; застосований усередині них, він просто один дозволений шлях застосунку з явними межами.

Схожі статті