Proxy SOCKS5 para OpenVPN: ¿túnel TCP o hacer proxy de las aplicaciones?

Las redes que solo permiten salir a través de un proxy son donde un perfil que funcionaba muere de repente. La dirección del proxy es la variable menos interesante de ese fallo. Todo lo decide la forma del tráfico que el proxy retransmitirá, porque estos proxies envían un flujo de bytes y un túnel UDP no lo es. Eso deja dos arquitecturas, y se rompen en lugares distintos.

Una restricción decide el diseño

SOCKS5 sí especifica un modo de asociación UDP. La compatibilidad con proxy del cliente OpenVPN está, sin embargo, construida en torno a flujos: socks-proxy está documentado para perfiles TCP, y un proxy HTTP CONNECT no tiene ninguna ruta para datagramas. Una línea de documentación resuelve la arquitectura antes de que toque un archivo de configuración.

La pregunta, por tanto, no es qué proxy elegir. Es si el túnel se convierte en un flujo o sigue siendo un datagrama y deja que otra cosa absorba el proxying.

Opción A: convertir el túnel en un flujo

Esto requiere un servidor con un oyente TCP y un perfil de cliente que nombre el proxy. Ambas piezas son necesarias, y el lado del servidor es el que la gente olvida:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

Sustituya la última línea por http-proxy proxy.internal 8080 cuando el proxy habla HTTP, y añada un archivo de credenciales si lo exige. El proxy debe aceptar hacer CONNECT a su puerto VPN, y el servidor debe responder en TCP; un oyente solo UDP ignora el intento. Elegir 443 es una decisión práctica, porque muchas redes restrictivas lo permiten y poco más.

El coste es TCP sobre TCP. Un segmento exterior perdido bloquea todos los flujos interiores que comparten esa conexión, así que una recuperación que normalmente sería independiente pasa a ser compartida. La configuración también tarda más, y una ruta exterior inestable se convierte en un túnel inestable en lugar de uno lento.

Opción B: dejar el túnel en paz

Cuando el túnel debe quedarse en UDP, el túnel no es donde se configura nada. En su lugar, el TCP saliente de las aplicaciones se redirige a un oyente SOCKS local, y las aplicaciones nunca saben que existe un proxy. En Linux eso suele ser redsocks más una regla NAT REDIRECT en la tabla nat.

Solo TCP, otra vez. Un proxy solo HTTP como privoxy no puede retransmitir protocolos arbitrarios, y este diseño tampoco añade compatibilidad con datagramas para las aplicaciones.

Decirle a cada aplicación lo del proxy directamente suele ser mejor cuando el software lo admite. Es más fácil de auditar, y falla en un sitio que realmente puede ver.

Dónde falla cada opción

La opción A falla cuando al servidor le falta un oyente TCP, cuando el proxy rechaza el objetivo CONNECT o cuando el flujo exterior se limita por debajo de lo que el túnel necesita. Las dos primeras dejan una entrada en el registro del proxy; la tercera deja una conexión que se establece y luego se siente mal. Lea ese registro antes de editar el perfil, porque separa un problema de permisos de uno de capacidad. Un CONNECT completado traslada la investigación al interior del túnel.

La opción B falla para todo lo que necesite datagramas, para los protocolos que el proxy no entiende, y en silencio en hosts donde la regla de redirección existe pero el enrutamiento envía el tráfico por otro lado.

Ninguna opción cambia el requisito del dispositivo. Los paquetes siguen necesitando un nodo TUN o TAP antes de que el núcleo los enrute, así que el proceso sigue necesitando permiso en /dev/net/tun. Un envoltorio cambia lo que ocurre después de que ese nodo esté abierto, no si lo necesita.

Demostrar qué camino construyó

Mire los sockets en lugar del icono de la bandeja. El proceso VPN debería mantener una conexión establecida con la dirección del proxy, y el proxy debería haber registrado el destino al que se le pidió llegar:

ss -tnp | grep openvpn

Luego busque un destino que solo el túnel pueda servir, y un nombre que solo el resolutor del túnel pueda responder. Una conexión de proxy completada con un túnel muerto suele significar que el extremo remoto nunca ofreció el transporte indicado en su perfil.

Anote el transporte y el proxy que acepta en un lugar duradero. Cuando el mismo perfil falle en otra red, esa nota descarta o confirma el proxy en segundos.