Redsocks ascolta su loopback ma il traffico VPN non arriva mai

Un tunnel viene su, il client riesce a fare ping del gateway, e ogni richiesta web lungo il percorso del proxy muore. Il processo redsocks è in esecuzione e la sua porta è in ascolto, quindi il servizio sembra sano dal gateway stesso. Ciò che fallisce è il passo di consegna: un pacchetto reindirizzato dal tunnel non atterra sul socket che hai avviato. L'indirizzo di binding e la destinazione della redirezione devono concordare, e di solito se ne controlla solo uno.

Dove atterra davvero un pacchetto reindirizzato

Il proxy trasparente su un gateway usa REDIRECT nella tabella nat in PREROUTING per riscrivere la destinazione di una connessione in ingresso su una porta locale. La destinazione riscritta è un indirizzo locale visto dall'interfaccia su cui è arrivato il pacchetto, non l'indirizzo di loopback di un processo avviato altrove. Un listener legato solo a 127.0.0.1 accetta connessioni che erano già locali sull'host, ed è esattamente il caso che continua a funzionare mentre il traffico del tunnel fallisce. Il loopback del client stesso è un terzo indirizzo e non è mai la destinazione della regola del gateway.

Quindi, prima di toccare le credenziali di monte, stabilisci due fatti: su quale indirizzo locale la regola riscrive e a quale indirizzo è legato il socket del proxy.

Leggi il listener e la regola di redirezione insieme

Stampa la tabella dei socket e le regole nat nello stesso passaggio, perché una regola che punta a una porta che nessuno possiede sembra identica a una regola che punta all'indirizzo sbagliato. sudo ss -ltnp | grep redsocks mostra l'indirizzo di binding e il processo proprietario. sudo iptables -t nat -S PREROUTING mostra la destinazione REDIRECT, e sudo iptables -t nat -L PREROUTING -v -n mostra se qualcosa vi ha corrisposto.

Un salto a una catena utente chiamata REDSOCKS non ottiene nulla se quella catena non esiste e non porta le esclusioni previste e l'azione REDIRECT. Leggi la catena verso cui salta con sudo iptables -t nat -S REDSOCKS invece di supporre che il nome faccia il lavoro.

Poi confronta i due valori. Se la regola reindirizza a un indirizzo del gateway sulla porta 12345 e il listener riporta 127.0.0.1:12345, la discrepanza spiega il guasto senza alcuna ulteriore diagnosi.

Lega in modo stretto, poi limita cosa può raggiungerlo

La configurazione di esempio di monte mette il listener su loopback per una buona ragione: un proxy trasparente accetta connessioni a nome di chiunque possa raggiungerlo. Cambiare il binding a 0.0.0.0 corregge la consegna e allo stesso tempo apre la porta su ogni interfaccia, il che è un cambiamento di sicurezza, non una riparazione neutra. Preferisci legare all'indirizzo locale specifico che la redirezione prende di mira, e tieni la porta chiusa sulle interfacce non fidate. Se un binding più ampio è inevitabile, aggiungi una regola del firewall dell'host che consenta solo l'intervallo di origine del tunnel e il traffico locale del gateway stesso.

Aprire la porta sull'interfaccia pubblica non è mai necessario per il traffico VPN reindirizzato, perché la connessione termina localmente dopo la riscrittura. Non esporre il proxy a internet per far funzionare una redirezione locale.

Provalo con una nuova connessione da un client

Testa da un client VPN reale con una connessione TCP nuova, non da una shell sul gateway. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com sul client esercita il percorso reindirizzato da un capo all'altro.

Poi conferma che una connessione diretta al listener da una rete non fidata è ancora rifiutata, e che la connessione a monte del proxy non viene catturata di nuovo dalla stessa regola. La cattura ricorsiva si manifesta come un proxy che si connette a se stesso e non completa mai una richiesta. Aggiungi la destinazione del proxy all'insieme delle esclusioni, o contrassegna i suoi pacchetti in uscita perché la catena li salti.

Infine, ricorda cosa questo percorso non copre. La normale redirezione TCP di redsocks non trasforma UDP, QUIC o DNS in traffico SOCKS, e le destinazioni private di solito richiedono esclusioni esplicite. Un test locale riuscito dimostra solo il percorso di loopback che non è mai stato il problema.