Сопряжение клиентов SOCKS с родителем HTTP CONNECT через 3proxy

Описывает шлюз со стороны SOCKS на основе родителя HTTP CONNECT и требования к протоколу и аутентификации на каждом участке.

Приложению нужен SOCKS. Ваш утверждённый вышестоящий сервис принимает HTTP CONNECT. Запись HTTP-эндпоинта в поле SOCKS приложения не транслирует между протоколами.

Шлюз может принимать SOCKS от приложения, читать запрошенный пункт назначения и запрашивать у родителя HTTP туннель CONNECT к этому пункту. Затем он передаёт поток приложения через туннель.

SOCKS application → SOCKS-facing gateway → HTTP CONNECT parent → destination

Сделайте каждый интерфейс явным

Для шлюза с такой схемой важен тип родителя. Документация 3proxy различает родителя connect и родителя, используемого как обычный HTTP-прокси пересылки.

При существующих пользователе 3proxy и аутентификации фрагмент локальной маршрутизации может выглядеть так:

auth strong
allow alex
parent 1000 connect parent.example.net 8080
socks -i127.0.0.1 -p1080

Этот фрагмент предполагает, что учётная запись уже определена. Он не добавляет учётные данные, которые требует сам родитель HTTP, и не заменяет существующую политику доступа. Для публичных назначений на маршруте, разрешающем неаутентифицированного публичного родителя HTTP, список HTTP-прокси предлагает кандидатов хоста и порта. Для этой ветви оставьте учётные данные родителя отсутствующими и подтвердите разрешение для фактической цели; учётная запись самого шлюза остаётся локальной. Правило parent связывается с предыдущим правилом allow согласно документированной модели конфигурации 3proxy.

Приложение использует локальный эндпоинт SOCKS. Шлюз использует HTTP CONNECT в сторону родителя. Именно родитель по-прежнему решает, разрешены ли запрошенные хост и порт назначения.

Полезный охват здесь — туннелирование обычного TCP-потока. UDP-ассоциация SOCKS5 не становится поддерживаемой только потому, что фронтальный слушатель принимает SOCKS5. Родитель HTTP CONNECT не предоставляет необходимый UDP-ретранслятор автоматически.

HTTPS может оставаться сквозным на этом пути; трансляция между прокси-интерфейсами не требует выдавать себя за целевой сайт. Аутентификация на шлюзе, на родителе и на сайте остаются разными учётными данными и обменами.

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