Локальная переадресация SSH к существующему HTTP-прокси: два адреса loopback

Ваш одобренный прокси работает на промежуточном хосте, где слушает только loopback, поэтому ничто за пределами этой машины не может до него добраться. Вам не нужны VPN или новый прокси; вам нужен один порт этой машины, перенесённый на один ваш порт. Локальная переадресация делает именно это, и для неё нужны одна команда и одна настройка приложения. Путаница обычно возникает из-за смешения того, какой адрес loopback относится к какой машине.

Решите, существует ли уже фиксированный прокси

Эта техника переадресует службу, которая уже работает. Если на удалённом хосте есть только демон SSH и нет прокси, никакое количество переадресации его не создаст, и соединение будет отклонено с удалённой стороны. Убедитесь, что прокси привязан, какой у него порт и слушает ли он на 127.0.0.1 или на конкретном адресе интерфейса, потому что именно на этот адрес должна целиться переадресация.

Если проверить это заранее, вы избавите себя от отладки туннеля, который никогда ни к чему не был подключён.

Постройте переадресацию и прочитайте команду

Нужная форма привязывает порт loopback на вашем ноутбуке и соединяет его со стороны сервера с адресом прокси так, как сервер его видит.

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N подавляет удалённую команду, а -T подавляет выделение termios, потому что вам нужен туннель, а не оболочка. Первый адрес loopback — это место, где слушает ноутбук; второй разрешается сервером SSH, поэтому 127.0.0.1 там означает прокси на той машине. ExitOnForwardFailure заставляет команду громко завершиться ошибкой, если локальный порт уже занят, вместо запуска сеанса, который ничего не переадресует. Записывайте целевой адрес так, как его разрешает сервер, потому что имя, которое может разрешить только ваш ноутбук, не сработает на другой стороне.

Собственная политика сервера действует до того, как что-либо из этого заработает. AllowTcpForwarding должен это разрешать, а PermitOpen может ограничивать, к каким назначениям и портам может попасть сеанс, поэтому переадресацию, которую клиент принимает, сервер всё равно может отклонить. Отказ проявляется как ошибка переадресации или канала на клиенте, и прочитать это сообщение быстрее, чем править команду.

Направьте одно приложение на переадресацию

Настройте приложение на использование HTTP-прокси по http://127.0.0.1:13128, с учётными данными, если удалённый прокси их требует. Сохраните собственную проверку сертификатов приложения для назначений HTTPS, поскольку туннель прокси её не заменяет. Это фиксированная переадресация одной службы, поэтому приложению нужно сообщить о прокси, а не оставлять его искать прокси самостоятельно.

Быстрая проверка перед любой постоянной настройкой: curl -x http://127.0.0.1:13128 -I https://example.com, что проверяет метод HTTP CONNECT, который прокси должен поддерживать.

Оставьте полномочия там, где они были

Удалённый прокси по-прежнему решает, какие назначения и методы он разрешает, и вход по SSH не должен молча выдавать каждой учётной записи общий веб-ретранслятор. Привязка к 127.0.0.1 на ноутбуке избегает публикации порта в вашей локальной сети и не делает порт закрытым от других процессов на той же машине. Замена этой привязки адресом wildcard ради совместного использования прокси — так и появляется неуправляемый открытый ретранслятор.

Транспорт SSH защищает переход до сервера. Дальше прокси открывает собственное соединение, поэтому обычный HTTP-запрос к назначению остаётся обычным и за сервером, хотя первый участок был зашифрован.

Проверьте оба конца, затем уберите за собой

Настройка локального туннеля и успех удалённой службы — разные результаты, и код завершения команды говорит вам только о первом. Проверьте наличие слушателя с помощью ss -ltn, затем выполните разрешённый запрос приложения и запрос, который прокси должен отклонить. Если оба ведут себя как ожидается, путь настоящий; если туннель работает, а каждый запрос завершается ошибкой, прокси отказывает или не может достичь назначения.

Когда закончите, остановите процесс SSH, которому он принадлежит, удалите настройку прокси из приложения и убедитесь, что локальный порт исчез, а не остался слушатель, переживший задачу.