Un proxy directo privado no necesita situarse físicamente entre el portátil y el router. Puede ser otra máquina de la misma LAN, con una sola interfaz de red.

El portátil se conecta a la dirección del proxy y a su puerto de escucha. El proceso del proxy abre una conexión aparte hacia el sitio web o hacia su padre. La misma interfaz puede transportar ambas conversaciones, mientras la tabla de rutas del host elige el siguiente salto.

client → proxy listener
proxy → existing router → destination

Eso basta para una aplicación que ha elegido el proxy de forma explícita. En Linux, esta disposición habitual no exige habilitar el reenvío IP solo para retransmitir las peticiones de la aplicación.

La puerta de enlace predeterminada responde a otra pregunta

La puerta de enlace predeterminada de un cliente gestiona los paquetes que este envía hacia otras redes. Cambiar ese ajuste no hace que el navegador emita peticiones de proxy HTTP ni negociaciones SOCKS. Del mismo modo, introducir un proxy en el navegador no encamina todas las demás aplicaciones por esa máquina.

Un host puede desempeñar ambas tareas, pero entonces tiene dos configuraciones que administrar: el servicio de proxy y la función de enrutamiento o cortafuegos. Más interfaces pueden facilitar la separación de redes. Son una elección de topología, no un requisito previo impuesto por el proxy HTTP explícito.

Esta distinción también explica un experimento fallido habitual: editar las reglas de reenvío de un servidor proxy no afecta a una conexión directa de cliente que atraviesa otro router. Los paquetes nunca cruzaron ese servidor.

Si el requisito es el uso obligatorio, determine dónde puede controlarse el tráfico saliente alternativo. Un proxy explícito de una interfaz puede ser un servicio válido mientras una puerta de enlace separada aplica la política de red. Coloque la aplicación donde los paquetes pasan de verdad.

Artículos relacionados