Il proxy chainingconsiste nel far passare il traffico attraverso più proxy in sequenza: client → proxy A → proxy B → destinazione. Nelle spiegazioni più diffuse viene presentato come "più anonimato"; nella realtà nasce quasi sempre da un'esigenza operativa : uscire da dietro il proxy aziendale, mantenere le credenziali in locale o convertire il protocollo.
In questo articolo analizziamo gli scenari in cui il chaining serve davvero, il suo costo e i metodi di configurazione.
Anatomia della catena
La destinazione vede soltanto l'ultimo anello della catena. La lunghezza della catena non le viene nascosta, ma l'unico indirizzo che rivela la tua identità è l'uscita finale.
Quando serve davvero il chaining?
Uscire da dietro il proxy aziendale
Se la tua rete fa passare tutto il traffico dal proprio proxy, per raggiungere il tuo proxy devi prima passare da quello aziendale. È una catena obbligata.
Mantenere le credenziali in locale
Se il browser o l'applicazione non supporta proxy con autenticazione, puoi far girare sulla macchina un piccolo proxy locale che custodisce la password e collegarti a esso tramite 127.0.0.1 .
Convertire il protocollo
La tua applicazione supporta solo proxy HTTP ma tu hai un SOCKS5. Inserendo un convertitore in mezzo colleghi i due.
Suddividere il traffico in base a regole
Se vuoi che determinati domini escano da un'uscita e gli altri da un'altra, inserisci in mezzo un livello che decide.
"Più proxy, più anonimato" non è vero. La destinazione vede comunque solo l'ultima uscita. Aggiungere un anello alla catena non cambia ciò che la destinazione sa di te: aumenta soltanto la latenza e la probabilità di guasto.
Il costo: latenza e fragilità
Ogni anello aggiunge il proprio handshake TCP e, se presente, TLS. Una catena a tre anelli può produrre una latenza vicina al quintuplo di una connessione diretta.
Oltre alla latenza, si moltiplica anche la fragilità : ogni anello è un punto di guasto. In una catena a tre anelli, ipotizzando che ciascun anello funzioni al 99%, la probabilità complessiva di funzionamento della catena scende a circa il 97%.
Configurazione pratica: bridge locale
La catena più spesso necessaria è un bridge locale che custodisce le credenziali. In questo modo anche le applicazioni che non supportano le password possono usare il tuo proxy con autenticazione.
Con questa configurazione le tue applicazioni si connettono all'indirizzo 127.0.0.1:3128 senza password; la password resta soltanto nella configurazione del bridge e non si diffonde a livello di sistema.
Se hai accesso SSH, puoi ottenere lo stesso risultato anche senza installare software aggiuntivo:
Il tunnel SSH produce un unico indirizzo fisso che esce dall'IP del tuo server. Come comportamento dà un risultato vicino a ISP proxy, ma non offre pool né rotazione.
Catena di conversione di protocollo
Se hai un SOCKS5 ma l'applicazione richiede solo un proxy HTTP, inserisci in mezzo un livello che ascolta in HTTP e inoltra a SOCKS5. È possibile anche il contrario. Questi convertitori sono leggeri e non incidono in modo apprezzabile sulla latenza.
Il livello convertitore risolve l'incompatibilità di protocollo senza modificare l'applicazione. È un pattern diffuso negli ambienti aziendali.
I limiti del chaining
- L'UDP non viene trasportato: se anche un solo anello della catena supporta esclusivamente TCP, il traffico basato su UDP (giochi, alcune soluzioni VoIP) non passa.
- L'autenticazione si stratifica: ogni anello richiede le proprie credenziali; una password inserita nel livello sbagliato provoca errori silenziosi.
- Il debug diventa più difficile: per capire quale anello sta dando errore bisogna testare ogni livello separatamente.
- I timeout entrano in conflitto: se il timeout dell'anello inferiore è più breve di quello superiore si verificano disconnessioni inattese.
- Dove viene risolto il DNS? In una catena il rischio di DNS leak aumenta; verifica a ogni livello dove avviene la risoluzione dei nomi.
Testa la catena dalla fine verso l'inizio: prima collegati direttamente all'uscita finale e verifica che funzioni, poi aggiungi l'anello precedente. Così individui il livello problematico al primo tentativo.
La soluzione generalmente migliore rispetto alla catena
Se il tuo obiettivo è la diversità geografica o la rotazione degli IP, invece di costruire una catena è molto più efficiente un servizio che usa un' architettura gateway . Il gateway gestisce già centinaia di uscite sullo sfondo; tu ottieni lo stesso risultato con una sola connessione e una latenza inferiore.
La catena è lo strumento giusto solo in presenza di un vincolo strutturale (rete aziendale, gestione delle credenziali, conversione di protocollo).
Riepilogo
Una catena di proxy non aumenta l'anonimato; la destinazione vede comunque solo l'ultima uscita. Il suo valore reale è operativo: uscire dalla rete aziendale, tenere le credenziali in locale, convertire il protocollo o suddividere il traffico in base a regole. Ogni anello aggiunge latenza e rischio di guasto, quindi mantieni la catena più corta possibile e testala dalla fine verso l'inizio. Per verificare il comportamento della tua uscita test di anonimato e test di DNS leak i nostri strumenti.