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

Падобныя артыкулы