Создание локального SOCKS-прокси через SSH

При разрешённом SSH-доступе к серверу OpenSSH может создать SOCKS-узел на вашем компьютере. 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 при каждом последующем отказе соединения с целью, поэтому отдельно проверяйте сеанс, локальный порт и запрос к цели.