Enrutamiento por políticas frente a SOCKS: qué capa hace realmente de proxy

Añadió una ruta por políticas que envía el tráfico de un cliente VPN a un host que ejecuta un proceso de escucha SOCKS en el puerto 1080. Los paquetes llegan, el proceso de escucha no registra nada y la conexión se cuelga. La ruta no tiene nada de malo: el siguiente salto elige adónde va un paquete, y SOCKS es una conversación que el cliente debe iniciar. Compare las tres arquitecturas que la gente suele querer decir cuando envía tráfico a través de un proxy y quedará claro qué pieza falta en su configuración.

El enrutamiento, DNAT y SOCKS cambian cosas distintas

Una ruta por políticas reescribe una decisión de capa 3. Dos líneas bastan para enviar el tráfico de un cliente a un siguiente salto elegido:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

Después, el núcleo entrega el paquete a 10.50.0.2 con el destino original todavía en la cabecera IP. Si 10.50.0.2 es un enrutador, reenvía el paquete. Si es un host con un demonio SOCKS en el 1080, el paquete no está dirigido a nada que pueda aceptarlo, y el DNAT al puerto 1080 tampoco ayuda, porque un paquete traducido sigue llevando la carga útil original de la aplicación en lugar de un saludo SOCKS.

SOCKS5 comienza con un byte de versión, una lista de métodos, un intercambio de autenticación y una petición que nombra el destino. Eso son datos de aplicación. Ni una entrada de enrutamiento ni un objetivo de netfilter los generan, y esa es la comparación en una línea: el enrutamiento elige una ruta, SOCKS pide a un servidor que haga una segunda conexión.

Caso uno: la aplicación puede hablar SOCKS por sí misma

Cuando el programa tiene un ajuste de proxy, este es el camino más corto y no necesita ningún cambio en el núcleo. Apúntelo al proceso de escucha, proporcione credenciales si el servidor las pide y decida si los nombres se resuelven localmente o se pasan al proxy. Con curl son indicadores distintos, y la diferencia importa cuando el destino solo se resuelve desde el lado del proxy:

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

Las aplicaciones que ignoran las variables de entorno de proxy, o que abren sockets sin procesar, no pueden recibir ayuda así. Los navegadores y la mayoría de las herramientas HTTP están bien; un cliente de juegos, un demonio de correo o un binario arbitrario de un proveedor normalmente no. El límite es por aplicación y por protocolo, por eso esta opción es excelente para probar y débil como respuesta para todo el VPN.

Caso dos: un adaptador que convierte flujos IP en sesiones de proxy

Para los programas que no pueden hablar SOCKS, la conversión tiene que ocurrir en algo que termine el tráfico IP y abra sesiones de proxy en su nombre. Ese componente posee una interfaz de túnel, acepta los flujos que seleccionó el enrutamiento por políticas, realiza el apretón de manos SOCKS para cada uno y reconstruye las respuestas. La ruta dirige el tráfico hacia él; el adaptador es lo que crea la sesión.

Lea su documentación antes de confiarle una subred entera. Muchos adaptadores transportan bien TCP y solo manejan UDP mediante una asociación UDP de SOCKS5, y ninguno convierte ICMP en tráfico de proxy, así que un ping correcto no dice nada sobre la ruta del proxy. El DNS es la otra trampa: si el adaptador resuelve nombres localmente, los registros solo internos se resuelven a una respuesta equivocada, o a nada en absoluto.

La prevención de bucles es el detalle operativo que muerde. Las conexiones propias del adaptador al servidor SOCKS no deben enrutarse de vuelta al adaptador, así que su tráfico necesita una excepción en la regla o una dirección de origen dedicada. Si se hace mal, la sesión de proxy intentará hacer de proxy de sí misma.

Caso tres: el host es en realidad una puerta de enlace enrutada

A veces la configuración que funciona no contiene ningún SOCKS. El host remoto reenvía los paquetes o les aplica NAT, y la regla basada en el origen simplemente lo elige como salida. Ese diseño es legítimo, y explica por qué una configuración copiada funciona en una red y falla en otra: la regla es idéntica, la pieza que falta es un servicio de reenvío al otro lado.

Los tres casos se separan rápido. Compruebe qué está escuchando realmente y luego mire los primeros bytes que llegan al host:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

El primer byte de carga útil de un cliente SOCKS real es 0x05, la versión del saludo. Si la captura muestra en su lugar datos originales de la aplicación, ningún demonio SOCKS responderá, porque la negociación nunca comenzó. Si nada escucha en el 1080, el host es una puerta de enlace y la pregunta pasa a ser si reenvía y si existe un camino de vuelta.

Elija la capa con cuatro preguntas

¿El programa tiene un ajuste de proxy? Úselo y deténgase ahí. ¿El tráfico incluye UDP o ICMP que deben sobrevivir? Solo una puerta de enlace enrutada o con NAT transporta ICMP, y UDP necesita una asociación SOCKS5 que ambos extremos admitan. ¿Debe cubrirse cada proceso de la máquina, incluidos los que no puede configurar? Entonces necesita un adaptador que posea la interfaz y termine flujos. ¿Puede asumir también su enrutamiento, DNS y excepciones de prevención de bucles? Si no, la puerta de enlace simple costará menos de operar.

Una distinción merece mantenerse clara. La propia opción socks-proxy de un cliente VPN describe cómo la conexión del túnel exterior llega a su servidor, y no dice nada sobre convertir los flujos internos del cliente. Las dos se confunden constantemente en el mismo ticket. Decida qué relación necesita antes de tocar una ruta.