Доступ к существующему HTTP- или SOCKS-прокси через SSH
Получите доступ к удалённому loopback HTTP- или SOCKS-прокси через SSH, не выставляя его слушатель публично.
Если relay.example.net уже запускает SOCKS на своём 127.0.0.1:1080, пересылайте доступ, а не выставляйте этот слушатель публично:
ssh -N -L 127.0.0.1:1081:127.0.0.1:1080 [email protected]| Конечная точка | Роль |
|---|---|
Ноутбук 127.0.0.1:1081 | Адрес SOCKS, который нужно настроить в приложении ноутбука. |
Ретранслятор 127.0.0.1:1080 | Существующий прокси, доступный со стороны сервера SSH. |
Синтаксис локальной переадресации назначает фиксированный пункт назначения стороне сервера. HTTP-прокси на удалённом loopback-порту 3128 или внутренняя конечная точка вроде proxy.internal.example:8080 работает по тому же принципу. Настройте клиент для этого существующего протокола HTTP и учётной записи; передача через SSH не создаёт SOCKS или HTTPS-слушатель с TLS.
Существующий сервис по-прежнему выбирает поддерживаемые версии протокола, аутентификацию, пункты назначения и окончательный выход. Если этот удалённый прокси создал другой процесс SSH, оба процесса должны оставаться живыми. Маршрут ноутбук→ретранслятор→шлюз оставляет сайту последнее исходящее соединение, а не идентичность, выделенную локальным портом 1081.
Держите привязку ноутбука явно локальной. Более широкое раскрытие меняет то, кто может добраться до сервиса, и вход по SSH не добавляет пароль SOCKS слушателю. При отказе проверяйте слушатель ноутбука, транспорт SSH и удалённый прокси как отдельные этапы.