Proxy HTTP, túnel SSH o VPN: elige la capa correcta

Pregunte a tres ingenieros cómo llegar a un servicio interno y obtendrá tres diseños: un proxy web, un túnel SSH o una VPN completa. Los tres pueden poner un servicio remoto a su alcance, y los tres pueden hacer que el tráfico parezca venir de otro lugar. Las diferencias aparecen más tarde, cuando el protocolo en uso no es el que supone la herramienta elegida. Un diseño que supera una comprobación rápida en el navegador suele fallar en la aplicación que motivó la petición.

Decida a partir de dos hechos: qué protocolos deben cruzar y quién puede resolver los nombres implicados. Todo lo demás es preferencia.

Un proxy solo mueve lo que entiende

Un proxy web analiza el protocolo para el que fue construido. El cliente le entrega una petición y él la entrega más adelante, así que una aplicación sin configuración de proxy no participa en absoluto. Para HTTPS el cliente necesita un canal opaco, que el proxy proporciona mediante CONNECT en lugar de leer la petición.

Un reenvío dinámico SSH abre un puerto local que habla SOCKS, y ese puerto retransmite un flujo TCP a cualquier destino que el cliente nombre. Los protocolos construidos sobre TCP suelen funcionar a través de él. UDP no, salvo que una herramienta añada soporte de forma explícita. Un reenvío local es aún más estrecho: un puerto local asignado a un host y un puerto fijos, que atiende un único servicio conocido y nada más.

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

Una VPN mueve paquetes. Todo lo que el cliente encamina hacia el túnel lo atraviesa, UDP e ICMP incluidos, por eso encaja con un requisito de red y no con una conexión única.

Alguien tiene que resolver el nombre

Cuando el nombre de destino solo existe en el DNS de la red remota, la máquina que hace la consulta debe poder ver esa zona. Un proxy web hace la consulta él mismo, así que un nombre interno funciona a través de él incluso cuando el portátil no puede resolver el nombre en absoluto. SOCKS puede comportarse igual, pero solo si el cliente reenvía el nombre en lugar de conectarse a una dirección que ya ha resuelto. Esa elección está en el cliente, no en el servidor.

curl muestra la división con claridad: una opción pasa el nombre de host al proxy, otra lo resuelve primero en local. Con resolución local, un nombre solo interno falla antes de tocar cualquier túnel, y el error culpa al proxy de lo que en realidad fue una decisión de DNS.

Una VPN toma la tercera vía instalando el resolutor privado y el dominio de búsqueda junto a las rutas. Eso es cómodo, y fabrica una ilusión familiar: una ruta que existe con un resolutor que no responde parece exactamente un túnel muerto, aunque los paquetes llegan al otro lado.

Cuando la red permite una sola salida

Muchas redes corporativas permiten conexiones salientes solo a través de un proxy web autenticado. OpenVPN y SSH pueden hacerse funcionar allí, el primero tunelizando su propio transporte a través del proxy y el segundo mediante una orden de proxy que ejecuta un pequeño auxiliar CONNECT.

Los túneles construidos sobre TCP sobreviven a esa restricción, y una VPN basada en UDP no, lo que explica muchísimas configuraciones que funcionan en casa y fallan en una oficina. Un segundo coste es fácil de pasar por alto: un túnel TCP llevado dentro de una conexión TCP con proxy tiene ahora dos capas que retransmiten, y bajo pérdidas esa pareja se atasca de una forma que ninguna capa produce sola.

Encadenar intermediarios es una cuestión distinta de elegir una capa. Añadir un segundo proxy o Tor cambia quién observa qué, y la posición en la cadena decide qué salto ve el texto cifrado.

El orden importa más que el número de saltos. Un salto externo observa un flujo cifrado mientras uno interno ve el texto plano que transporta, así que una cadena es tan privada como su eslabón menos cuidadoso. Mezclar protocolos entre saltos no lo mejora automáticamente. Sobre todo hace que los modos de fallo sean más difíciles de razonar.

Una dirección falsificada no es una de las opciones

Crear paquetes con la dirección de origen de otra persona no logra nada útil: las respuestas viajan al propietario real, y la mayoría de las redes descartan el tráfico sin más. Se necesita un intermediario precisamente porque el origen no puede inventarse, y esa es la justificación honesta de los tres diseños.

También limita lo que cualquiera de ellos puede afirmar. Parecer originarse en una dirección concreta es una cuestión sobre dónde se asigna legítimamente esa dirección y quién puede encaminarla, no sobre qué herramienta puede falsificar una cabecera. Si un diseño supone lo contrario, el supuesto falla en el primer proveedor que lo filtra. Escriba el supuesto para que el fallo sea reconocible cuando llegue.

Decida por protocolos y nombres

Recurra a un proxy cuando un solo cliente web necesita un solo servicio web y tiene configuración de proxy. Recurra a un túnel SSH cuando basta un puñado de servicios TCP conocidos y el acceso SSH ya existe. Recurra a una VPN cuando varias aplicaciones, tráfico no TCP, DNS privado o una ruta reutilizable forman parte del requisito.

Luego verifique con el cliente real y el nombre real. Cargar una página a través de un proxy no le enseña nada sobre UDP, y hacer funcionar una herramienta sobre SOCKS no le enseña nada sobre el resolutor del sistema. Lea qué dirección local vinculó el proceso y qué resolutor respondió. Esa es la diferencia entre una ruta que funciona y una que funcionó por casualidad una vez.