Aplicația are nevoie de SOCKS. Serviciul tău amonte aprobat acceptă HTTP CONNECT. Punerea punctului final HTTP în câmpul SOCKS al aplicației nu traduce între protocoale.

Un gateway poate accepta SOCKS de la aplicație, poate citi destinația cerută și poate cere părintelui HTTP un tunel CONNECT către acea destinație. Apoi retransmite fluxul aplicației prin tunel.

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

Fă explicită fiecare interfață

Pentru un gateway care sprijină această configurație, tipul părintelui contează. Documentația 3proxy distinge un părinte connect de un părinte folosit ca proxy obișnuit de redirecționare HTTP.

Cu un utilizator 3proxy și o autentificare deja existente, un fragment de rutare doar local poate arăta astfel:

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

Acest fragment presupune că contul este deja definit. Nu adaugă acreditările cerute de părintele HTTP însuși și nu înlocuiește politica de acces existentă. Pentru destinații publice pe o rută care permite un părinte HTTP public neautentificat, lista de proxy HTTP oferă candidați de gazdă și port. Lasă acreditările părintelui absente pentru acea ramură și confirmă permisiunea pentru ținta reală; contul gateway-ului rămâne local. Regula parent este asociată cu regula allow anterioară conform modelului de configurare documentat al 3proxy.

Aplicația folosește punctul final SOCKS local. Gateway-ul folosește HTTP CONNECT către părinte. Părintele decide în continuare dacă gazda și portul destinației cerute sunt permise.

Domeniul util aici este tunelarea fluxului TCP obișnuit. O asociere UDP SOCKS5 nu devine acceptată doar pentru că ascultătorul frontal acceptă SOCKS5. Un părinte HTTP CONNECT nu oferă automat releul UDP necesar.

HTTPS poate rămâne cap la cap în această cale; traducerea între interfețele de proxy nu cere să imiti site-ul destinație. Autentificarea la gateway, la părinte și la site rămân acreditări și schimburi diferite.

Articole similare