Redsocks escoita no loopback, pero o tráfico VPN nunca chega

Levántase un túnel, o cliente pode facer ping á pasarela e cada solicitude web pola ruta do proxy morre. O proceso redsocks execútase e o seu porto escoita, así que o servizo parece san desde a propia pasarela. O que falla é o paso de entrega: un paquete redirixido desde o túnel non aterra no socket que iniciaches. O enderezo de vinculación e o destino da redirección deben coincidir, e normalmente só se comproba un dos dous.

Onde aterra realmente un paquete redirixido

O proxy transparente nunha pasarela usa REDIRECT na táboa nat en PREROUTING para reescribir o destino dunha conexión entrante cara a un porto local. O destino reescrito é un enderezo local tal como o ve a interface pola que chegou o paquete, non o enderezo de loopback dun proceso iniciado noutro lugar. Un oínte vinculado só a 127.0.0.1 acepta conexións que xa eran locais no host, e ese é xusto o caso que segue funcionando mentres o tráfico do túnel falla. O loopback propio do cliente é un terceiro enderezo e nunca é o destino da regra da pasarela.

Así que antes de tocar as credenciais do tramo superior, estabelece dous feitos: a que enderezo local reescribe a regra e a que enderezo está vinculado o socket do proxy.

Le o oínte e a regra de redirección xuntos

Imprime a táboa de sockets e as regras nat nunha soa pasada, porque unha regra que apunta a un porto que ninguén posúe parece idéntica a unha regra que apunta ao enderezo equivocado. sudo ss -ltnp | grep redsocks mostra o enderezo de vinculación e o proceso propietario. sudo iptables -t nat -S PREROUTING mostra o destino REDIRECT, e sudo iptables -t nat -L PREROUTING -v -n mostra se algo coincidiu con el.

Un salto a unha cadea de usuario chamada REDSOCKS non acada nada a menos que esa cadea exista e leve as exclusións previstas e a acción REDIRECT. Le a cadea á que salta con sudo iptables -t nat -S REDSOCKS en lugar de supor que o nome fai o traballo.

Despois compara os dous valores. Se a regra redirixe a un enderezo de pasarela no porto 12345 e o oínte informa de 127.0.0.1:12345, a discrepancia explica o fallo sen ningún diagnóstico adicional.

Vincula estreitamente e despois limita que pode alcanzalo

A configuración de exemplo do tramo superior pon o oínte no loopback por unha boa razón: un proxy transparente acepta conexións en nome de calquera que poida alcanzalo. Cambiar a vinculación a 0.0.0.0 corrixe a entrega e ao mesmo tempo abre o porto en todas as interfaces, o que é un cambio de seguridade, non unha reparación neutra. Prefire vincular ao enderezo local concreto que a redirección ten como obxectivo, e mantén o porto pechado nas interfaces non fiables. Se unha vinculación máis ampla é inevitable, engade unha regra de devasas do host que permita só o rango de orixe do túnel e o tráfico local propio da pasarela.

Abrir o porto na interface pública nunca é necesario para o tráfico VPN redirixido, porque a conexión remata localmente despois da reescritura. Non expoñas o proxy a internet para facer funcionar unha redirección local.

Demostrao cunha conexión nova desde un cliente

Proba desde un cliente VPN real cunha conexión TCP nova, non desde un shell na pasarela. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com no cliente exercita a ruta redirixida de extremo a extremo.

Despois confirma que unha conexión directa ao oínte desde unha rede non fiable segue rexeitándose, e que a conexión ascendente do propio proxy non volve ser capturada pola mesma regra. A captura recursiva maniféstase como un proxy que se conecta a si mesmo e nunca completa unha solicitude. Engade o destino do proxy ao conxunto de exclusións, ou marca os seus paquetes saíntes para que a cadea os omita.

Por último, lembra o que non cobre esta ruta. A redirección TCP normal de redsocks non converte UDP, QUIC nin DNS en tráfico SOCKS, e os destinos privados adoitan necesitar exclusións explícitas. Unha proba local exitosa só demostra a ruta de loopback que nunca foi o problema.