Bru SOCKS-klientar til ein HTTP CONNECT-forelder med 3proxy

Forklarer ein SOCKS-vend gateway med ein HTTP CONNECT-forelder, og krava til protokoll og autentisering ved kvar hopp.

Applikasjonen krev SOCKS. Den godkjende oppstraumstenesta di godtek HTTP CONNECT. Å setje HTTP-endepunktet i SOCKS-feltet til applikasjonen omset ikkje mellom protokollane.

Ein gateway kan godta SOCKS frå applikasjonen, lese den førespurde destinasjonen og be HTTP-forelderen om ein CONNECT-tunnel til den destinasjonen. Deretter videresender han straumen frå applikasjonen gjennom tunnelen.

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

Gjer kvart grensesnitt eksplisitt

For ein gateway som støttar denne ordninga, er foreldertypen viktig. 3proxy-dokumentasjonen skil ein connect-forelder frå ein forelder som vert brukt som ein vanleg HTTP-vidareformidlingsproxy.

Med ein eksisterande 3proxy-brukar og autentisering kan eit berre lokalt rutefragment sjå slik ut:

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

Dette fragmentet føreset at kontoen allereie er definert. Det legg ikkje til legitimasjon som HTTP-forelderen sjølv krev, og det erstattar ikkje den eksisterande tilgangspolitikken. For offentlege destinasjonar på ei rute som tillèt ein uautentisert offentleg HTTP-forelder, tilbyr HTTP-proxylista verts- og portkandidatar. Hald foreldrelegitimasjonen borte for den greina og stadfest løyvet for det faktiske målet; den eigne kontoen til gatewayen blir verande lokal. Regelen parent er knytt til den førre allow-regelen under den dokumenterte konfigurasjonsmodellen til 3proxy.

Applikasjonen brukar det lokale SOCKS-endepunktet. Gatewayen brukar HTTP CONNECT mot forelderen. Forelderen avgjer framleis om den førespurde destinasjonsverten og -porten er tillaten.

Vanleg TCP-straummuntling er det nyttige omfanget her. Ein SOCKS5 UDP-tilknyting blir ikkje støtta berre fordi den fremre lyttaren godtek SOCKS5. Ein HTTP CONNECT-forelder leverer ikkje automatisk den naudsynte UDP-vidareformidlinga.

HTTPS kan halde fram som ende-til-ende i denne vegen; omsetjing mellom proxygrensesnitt krev ikkje å etterlikne destinasjonsnettstaden. Autentisering mot gatewayen, mot forelderen og på nettstaden er framleis ulike legitimasjonar og utvekslingar.

Relaterte artiklar