Collegare client SOCKS a un parent HTTP CONNECT con 3proxy

Spiega un gateway lato SOCKS supportato da un parent HTTP CONNECT e i requisiti di protocollo e autenticazione a ogni salto.

L'applicazione richiede SOCKS. Il servizio upstream approvato accetta HTTP CONNECT. Mettere l'endpoint HTTP nel campo SOCKS dell'applicazione non traduce tra i protocolli.

Un gateway può accettare SOCKS dall'applicazione, leggere la destinazione richiesta e chiedere al parent HTTP un tunnel CONNECT verso quella destinazione. Poi inoltra il flusso dell'applicazione attraverso il tunnel.

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

Rendi esplicita ogni interfaccia

Per un gateway che supporta questa disposizione conta il tipo di parent. La documentazione di 3proxy distingue un parent connect da un parent usato come normale proxy di inoltro HTTP.

Con un utente 3proxy e un'autenticazione già esistenti, un frammento di routing solo locale può assumere questa forma:

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

Questo frammento presuppone che l'account sia già definito. Non aggiunge credenziali richieste dal parent HTTP stesso e non sostituisce la politica di accesso esistente. Per destinazioni pubbliche su una rotta che consente un parent HTTP pubblico non autenticato, l'elenco di proxy HTTP offre candidati host e porta. Lascia assenti le credenziali del parent per quel ramo e conferma il permesso per il target effettivo; l'account del gateway resta locale. La regola parent è associata alla regola allow precedente secondo il modello di configurazione documentato di 3proxy.

L'applicazione usa l'endpoint SOCKS locale. Il gateway usa HTTP CONNECT verso il parent. Il parent decide ancora se l'host e la porta di destinazione richiesti sono consentiti.

L'ambito utile qui è il tunneling di flussi TCP ordinari. Un'associazione UDP SOCKS5 non diventa supportata solo perché il listener frontale accetta SOCKS5. Un parent HTTP CONNECT non fornisce automaticamente il relay UDP richiesto.

HTTPS può restare end-to-end in questo percorso; la traduzione tra interfacce proxy non richiede di impersonare il sito di destinazione. L'autenticazione al gateway, al parent e al sito restano credenziali e scambi distinti.

Articoli correlati