Povezovanje odjemalcev SOCKS z nadrejenim strežnikom HTTP CONNECT s 3proxy

Pojasnjuje prehod na strani SOCKS, ki ga podpira nadrejeni strežnik HTTP CONNECT, ter zahteve protokola in preverjanja pristnosti na vsakem koraku.

Aplikacija potrebuje SOCKS. Vaša odobrena nadrejena storitev sprejema HTTP CONNECT. Vnos končne točke HTTP v polje SOCKS aplikacije ne prevaja med protokoloma.

Prehod lahko sprejme SOCKS od aplikacije, prebere zahtevani cilj in nadrejenemu strežniku HTTP pošlje zahtevo za tunel CONNECT do tega cilja. Nato pretaka tok aplikacije skozi tunel.

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

Naredite vsak vmesnik ekspliciten

Za prehod, ki podpira to ureditev, je pomembna vrsta nadrejenega strežnika. Dokumentacija 3proxy razlikuje nadrejeni connect od nadrejenega strežnika, ki se uporablja kot običajni posrednik za posredovanje HTTP.

Ob obstoječem uporabniku 3proxy in preverjanju pristnosti je lahko lokalni fragment usmerjanja videti takole:

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

Ta fragment predpostavlja, da je račun že določen. Ne doda poverilnic, ki jih zahteva nadrejeni strežnik HTTP sam, in ne nadomesti obstoječe politike dostopa. Za javne cilje na poti, ki dovoljuje neoverjenega javnega nadrejenega strežnika HTTP, seznam posrednikov HTTP ponuja kandidate za gostitelja in vrata. Za to vejo pustite poverilnice nadrejenega strežnika odsotne in potrdite dovoljenje za dejanski cilj; račun samega prehoda ostane lokalen. Pravilo parent je skladno z dokumentiranim konfiguracijskim modelom 3proxy povezano s prejšnjim pravilom allow.

Aplikacija uporablja lokalno končno točko SOCKS. Prehod uporablja HTTP CONNECT proti nadrejenemu strežniku. Nadrejeni strežnik še vedno odloča, ali sta zahtevani gostitelj in vrata cilja dovoljena.

Koristen obseg je tu tuneliranje običajnega toka TCP. Pridružitev UDP pri SOCKS5 ni podprta samo zato, ker sprednji poslušalec sprejema SOCKS5. Nadrejeni strežnik HTTP CONNECT ne zagotovi potrebnega posrednika UDP samodejno.

HTTPS lahko na tej poti ostane od konca do konca; prevajanje med vmesniki posrednika ne zahteva, da bi se izdajali za ciljno spletno mesto. Preverjanje pristnosti pri prehodu, pri nadrejenem strežniku in na spletnem mestu ostajajo različne poverilnice in izmenjave.

Sorodni članki