Створення локального SOCKS-проксі через SSH

Маючи дозволений SSH-доступ до сервера, можна створити SOCKS-слухач на своєму комп’ютері за допомогою OpenSSH. SSH-з’єднання переносить перенаправлений трафік, а віддалений сервер з’єднується з ціллю.

Прослуховування лише loopback

ssh -N -T -o ControlPath=none -o ForkAfterAuthentication=no -o ExitOnForwardFailure=yes -D 127.0.0.1:1080 [email protected]

Замініть обліковий запис та ім’я хоста. Сервер SSH має дозволяти перенаправлення; адміністратор може обмежити його й цілі незалежно від входу в обліковий запис.

-D створює динамічне перенаправлення, а явна loopback-адреса обмежує слухач цим комп’ютером. -N не виконує віддаленої команди, -T не виділяє псевдотермінала. ControlPath=none уникає наявного спільного master-процесу, а ForkAfterAuthentication=no залишає цей запуск на передньому плані.

Тримайте процес запущеним, поки користуєтеся проксі. Якщо порт 1080 зайнятий, оберіть інший вільний високий порт і змініть клієнт. ExitOnForwardFailure=yes завершує SSH, якщо слухач не вдалося створити.

Використання кінцевої точки SOCKS

curl --proxy socks5h://127.0.0.1:1080 --noproxy '' --connect-timeout 5 --max-time 15 https://example.com/

Цей запит делегує обробку імені цілі через SOCKS5. Іншим застосункам потрібні власні налаштування SOCKS; поле HTTP-проксі не може говорити SOCKS із цим слухачем.

Перевірка власника порту:

ss -ltnp 'sport = :1080'

Потрібний SSH-процес має володіти loopback-слухачем. Запит через нього перевіряє, чи віддалений сервер теж досягає цілі. Використовуйте контрольовану ціль, коли треба перевірити спостережений вихід.

Час життя сеансу

Ctrl-C закриває процес SSH, слухач і перенаправлені з’єднання. Розрив SSH-з’єднання також робить проксі недоступним.

ExitOnForwardFailure перевіряє встановлення. Він не завершує SSH при кожному подальшому збої цільового з’єднання, тому окремо перевіряйте сеанс, локальний порт і запит до цілі.