З'єднання 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 може залишатися наскрізним на цьому шляху; перетворення між проксі-інтерфейсами не вимагає видавати себе за цільовий сайт. Автентифікація на шлюзі, на батьківському сервері й на сайті залишаються різними обліковими даними та обмінами.

Схожі статті