Bro SOCKS-klienter til en HTTP CONNECT-forelder med 3proxy

Forklarer en SOCKS-vendt gateway med en HTTP CONNECT-forelder, og kravene til protokoll og autentisering ved hvert hopp.

Applikasjonen krever SOCKS. Den godkjente oppstrømstjenesten din godtar HTTP CONNECT. Å sette HTTP-endepunktet i applikasjonens SOCKS-felt oversetter ikke mellom protokollene.

En gateway kan godta SOCKS fra applikasjonen, lese den forespurte destinasjonen og be HTTP-forelderen om en CONNECT-tunnel til den destinasjonen. Deretter videresender den applikasjonens strøm gjennom tunnelen.

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

Gjør hvert grensesnitt eksplisitt

For en gateway som støtter denne ordningen, er foreldretypen viktig. 3proxy-dokumentasjonen skiller en connect-forelder fra en forelder som brukes som en vanlig HTTP-videresendingsproxy.

Med en eksisterende 3proxy-bruker og autentisering kan et kun lokalt rutingfragment se slik ut:

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

Dette fragmentet forutsetter at kontoen allerede er definert. Det legger ikke til legitimasjon som HTTP-forelderen selv krever, og det erstatter ikke den eksisterende tilgangspolicyen. For offentlige destinasjoner på en rute som tillater en uautentisert offentlig HTTP-forelder, tilbyr HTTP-proxylisten verts- og portkandidater. Hold forelderens legitimasjon borte for den grenen og bekreft tillatelsen for det faktiske målet; gatewayens egen konto forblir lokal. Regelen parent knyttes til den foregående allow-regelen under 3proxys dokumenterte konfigurasjonsmodell.

Applikasjonen bruker det lokale SOCKS-endepunktet. Gatewayen bruker HTTP CONNECT mot forelderen. Forelderen avgjør fortsatt om den forespurte destinasjonsverten og -porten er tillatt.

Vanlig TCP-strømtunnelering er det nyttige omfanget her. En SOCKS5 UDP-tilknytning blir ikke støttet bare fordi den fremre lytteren godtar SOCKS5. En HTTP CONNECT-forelder leverer ikke automatisk den nødvendige UDP-videresendingen.

HTTPS kan forbli ende-til-ende i denne veien; oversettelse mellom proxygrensesnitt krever ikke å etterligne destinasjonsnettstedet. Autentisering mot gatewayen, mot forelderen og på nettstedet er fortsatt forskjellige legitimasjoner og utvekslinger.

Relaterte artikler