ProxyChains-NG non crea un tunnel. Precarica una libreria che sostituisce le chiamate libc legate alla rete all'interno dell'unico programma che avvia, quindi il confine è una chiamata in un processo, non una rotta per tutto il dispositivo. Questa distinzione decide che cosa dimostra davvero un test riuscito. Un curl funzionante attraverso la catena conferma una sola chiamata agganciata, non che la risoluzione dei nomi, UDP o ogni processo figlio abbiano seguito lo stesso percorso. La guida qui sotto verifica la copertura in tre passaggi, poi elenca ciò che l'aggancio non può raggiungere.

Come il precaricamento raggiunge una connessione

All'avvio il lanciatore mette libproxychains in LD_PRELOAD e poi esegue il programma di destinazione. La libreria risolve i veri simboli libc e li sostituisce con le proprie versioni di funzioni come connect e getaddrinfo. Le chiamate che passano per quei simboli vengono riscritte verso il proxy SOCKS o HTTP del file di configurazione. Le chiamate che prendono un'altra strada non incontrano mai l'aggancio, ed è per questo che la garanzia vale per chiamata e non per macchina.

Partecipano solo i programmi collegati dinamicamente, e i binari setuid sotto esecuzione sicura ignorano del tutto il precaricamento. I figli ereditano l'ambiente, ma solo finché il lanciatore lo tiene al suo posto.

Confermate che la libreria è caricata in quel processo

Avviate la richiesta e ispezionate il processo vivo invece della shell che l'ha lanciato. Il file maps mostra ogni oggetto condiviso attualmente mappato nel processo.

proxychains4 -q curl -sS --max-time 8 https://example.com/ -o /dev/null &
pgrep -a curl
grep libproxychains /proc/$(pgrep -n curl)/maps

Una corrispondenza conferma che la libreria agganciata è presente, cosa necessaria ma non sufficiente. Un risultato vuoto di solito significa che avete ispezionato un altro processo, per esempio un browser che ha passato l'URL a un'istanza avviata prima del lanciatore. Verificate con ldd che il binario sia collegato dinamicamente prima di inseguire qualsiasi altra cosa, perché una build statica non può caricare affatto il precaricamento. Poi leggete la lista dei proxy nella configurazione che il lanciatore ha davvero usato, perché un percorso obsoleto o una porta chiusa producono un aggancio che funziona senza una catena che funziona.

Tracciate le connessioni che escono dal processo

La presenza della libreria non dimostra che ogni chiamata sia stata riscritta, quindi seguite le chiamate di sistema. Eseguite una richiesta sotto il tracciatore e leggete dove sono andati davvero i socket.

strace -f -e trace=connect -o /tmp/pc.trace proxychains4 -q curl -sS https://example.com/ -o /dev/null
grep -o "sin_port=htons([0-9]*)" /tmp/pc.trace | sort -u

La traccia dovrebbe mostrare solo connessioni verso il vostro endpoint proxy, con la porta che corrisponde alla voce nel file di configurazione. Se gli indirizzi di destinazione del sito di destinazione compaiono direttamente nella traccia, quella chiamata ha aggirato l'aggancio, ed è proprio il riscontro che stavate cercando. Confrontate i numeri di porta con la lista dei proxy invece di fidarvi del nome del file, perché una configurazione rimasta da un altro progetto è una fonte comune di accesso diretto silenzioso. Conservate la traccia per il verbale di collaudo; richiede secondi e chiude le discussioni sulla copertura.

Decidete cosa l'aggancio non può coprire

Il progetto proxychains-ng limita il reindirizzamento a TCP e avverte che script, processi in background e moduli caricati possono comportarsi diversamente dal programma principale. UDP e ICMP restano fuori dal meccanismo, quindi tutto ciò che vi si affida ha bisogno di un proprio percorso supportato. DNS segue l'impostazione proxy_dns e il comportamento del resolver dell'applicazione, il che significa che una richiesta HTTPS riuscita non vi dice nulla sulla risoluzione dei nomi. Mantenete anche la validazione dei certificati dove deve stare: raggiungere un server tramite un proxy non è una ragione per disattivare i controlli di identità.

Se il fallback diretto deve essere impossibile, usate un confine di applicazione che controlli il traffico stesso, come un namespace di rete, regole del firewall o una VPN, e tenetelo separato dall'aggancio della libreria. L'aggancio è uno strumento di compatibilità per un programma specifico, non un kill switch. Registrate il programma, il comando esatto, la porta proxy vista nella traccia e se DNS è stato risolto da remoto; questi quattro fatti sono la differenza tra un perimetro verificato e un perimetro di speranza.

Articoli correlati