Повезивање SOCKS клијената са HTTP CONNECT родитељем помоћу 3proxy

Апликацији је потребан 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 тока. SOCKS5 UDP асоцијација не постаје подржана само зато што предњи слушалац прихвата SOCKS5. HTTP CONNECT родитељ не обезбеђује аутоматски потребни UDP релеј.

HTTPS може остати од краја до краја унутар ове путање; превођење између прокси сучеља не захтева представљање као одредишно веб место. Аутентификација према пролазу, према родитељу и на веб месту остају различити акредитиви и размене.