Redsocks escucha en loopback, pero el tráfico VPN nunca llega

Se levanta un túnel, el cliente puede hacer ping a la puerta de enlace y cada solicitud web por la ruta del proxy muere. El proceso redsocks se ejecuta y su puerto escucha, así que el servicio parece sano desde la propia puerta de enlace. Lo que falla es el paso de entrega: un paquete redirigido desde el túnel no aterriza en el socket que iniciaste. La dirección de vinculación y el destino de la redirección deben coincidir, y normalmente solo se comprueba uno de los dos.

Dónde aterriza realmente un paquete redirigido

El proxy transparente en una puerta de enlace usa REDIRECT en la tabla nat en PREROUTING para reescribir el destino de una conexión entrante hacia un puerto local. El destino reescrito es una dirección local tal como la ve la interfaz por la que llegó el paquete, no la dirección de loopback de un proceso iniciado en otro lugar. Un oyente vinculado solo a 127.0.0.1 acepta conexiones que ya eran locales en el host, y ese es justo el caso que sigue funcionando mientras el tráfico del túnel falla. El loopback propio del cliente es una tercera dirección y nunca es el destino de la regla de la puerta de enlace.

Así que antes de tocar las credenciales del tramo superior, establece dos hechos: a qué dirección local reescribe la regla y a qué dirección está vinculado el socket del proxy.

Lee el oyente y la regla de redirección juntos

Imprime la tabla de sockets y las reglas nat en una sola pasada, porque una regla que apunta a un puerto que nadie posee se ve idéntica a una regla que apunta a la dirección equivocada. sudo ss -ltnp | grep redsocks muestra la dirección de vinculación y el proceso propietario. sudo iptables -t nat -S PREROUTING muestra el destino REDIRECT, y sudo iptables -t nat -L PREROUTING -v -n muestra si algo coincidió con él.

Un salto a una cadena de usuario llamada REDSOCKS no logra nada a menos que esa cadena exista y lleve las exclusiones previstas y la acción REDIRECT. Lee la cadena a la que salta con sudo iptables -t nat -S REDSOCKS en lugar de suponer que el nombre hace el trabajo.

Luego compara los dos valores. Si la regla redirige a una dirección de puerta de enlace en el puerto 12345 y el oyente informa de 127.0.0.1:12345, la discrepancia explica el fallo sin ningún diagnóstico adicional.

Vincula de forma estrecha y luego limita qué puede alcanzarlo

La configuración de ejemplo del tramo superior pone el oyente en loopback por una buena razón: un proxy transparente acepta conexiones en nombre de cualquiera que pueda alcanzarlo. Cambiar la vinculación a 0.0.0.0 corrige la entrega y al mismo tiempo abre el puerto en todas las interfaces, lo que es un cambio de seguridad, no una reparación neutra. Prefiere vincular a la dirección local concreta que la redirección tiene como objetivo y mantén el puerto cerrado en las interfaces no confiables. Si una vinculación más amplia es inevitable, añade una regla de cortafuegos del host que permita solo el rango de origen del túnel y el tráfico local propio de la puerta de enlace.

Abrir el puerto en la interfaz pública nunca es necesario para el tráfico VPN redirigido, porque la conexión termina localmente después de la reescritura. No expongas el proxy a internet para hacer funcionar una redirección local.

Demuéstralo con una conexión nueva desde un cliente

Prueba desde un cliente VPN real con una conexión TCP nueva, no desde un shell en la puerta de enlace. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com en el cliente ejercita la ruta redirigida de extremo a extremo.

Luego confirma que una conexión directa al oyente desde una red no confiable sigue rechazándose, y que la propia conexión ascendente del proxy no vuelve a ser capturada por la misma regla. La captura recursiva se manifiesta como un proxy que se conecta a sí mismo y nunca completa una solicitud. Añade el destino del proxy al conjunto de exclusiones, o marca sus paquetes salientes para que la cadena los omita.

Por último, recuerda qué no cubre esta ruta. La redirección TCP normal de redsocks no convierte UDP, QUIC ni DNS en tráfico SOCKS, y los destinos privados suelen necesitar exclusiones explícitas. Una prueba local exitosa solo demuestra la ruta de loopback que nunca fue el problema.