Bro SOCKS-klienter til en HTTP CONNECT-forælder med 3proxy

Forklarer en SOCKS-vendt gateway bakket op af en HTTP CONNECT-forælder og kravene til protokol og godkendelse ved hvert hop.

Programmet kræver SOCKS. Din godkendte opstrøms tjeneste accepterer HTTP CONNECT. At sætte HTTP-endepunktet i programmets SOCKS-felt oversætter ikke mellem protokollerne.

En gateway kan acceptere SOCKS fra programmet, læse den ønskede destination og bede HTTP-forælderen om en CONNECT-tunnel til den destination. Derefter videresender den programmets strøm gennem tunnelen.

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

Gør hver grænseflade eksplicit

For en gateway, der understøtter denne opsætning, betyder dens forældrtype noget. 3proxy-dokumentationen skelner mellem en connect-forælder og en forælder, der bruges som en almindelig HTTP-videresendelsesproxy.

Med en eksisterende 3proxy-bruger og godkendelsesopsætning kan et kun-lokalt routingfragment se sådan ud:

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

Dette fragment forudsætter, at kontoen allerede er defineret. Det tilføjer ikke de legitimationsoplysninger, som HTTP-forælderen selv kræver, og erstatter ikke den eksisterende adgangspolitik. For offentlige destinationer på en rute, der tillader en uautentificeret offentlig HTTP-forælder, tilbyder HTTP-proxylisten værts- og portkandidater. Hold forældrens legitimationsoplysninger væk for den gren og bekræft tilladelsen til det faktiske mål; gatewayens egen konto forbliver lokal. Reglen parent knyttes til den foregående allow-regel under 3proxys dokumenterede konfigurationsmodel.

Programmet bruger det lokale SOCKS-endepunkt. Gatewayen bruger HTTP CONNECT mod forælderen. Forælderen afgør stadig, om den ønskede destinationsvært og -port er tilladt.

Almindelig TCP-strømtunnelering er det nyttige omfang her. En SOCKS5 UDP-association bliver ikke understøttet, blot fordi den forreste lytter accepterer SOCKS5. En HTTP CONNECT-forælder leverer ikke automatisk den krævede UDP-relay.

HTTPS kan forblive ende-til-ende i denne vej; oversættelse mellem proxygrænseflader kræver ikke at efterligne destinationswebstedet. Godkendelse til gatewayen, godkendelse til forælderen og godkendelse på webstedet er fortsat forskellige legitimationsoplysninger og udvekslinger.

Relaterede artikler