Дайте удалённому 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 по устройствам или ресурсам; применённый внутри них, он просто один разрешённый путь приложения с явными границами.

Похожие статьи