El proxy de depuración se queda ciego cuando se conecta la VPN corporativa

La herramienta de captura funciona toda la mañana, el túnel se conecta y se queda en silencio. Desconectas y vuelve a arrancar. El instinto dice que la VPN rompió el proxy, pero en la configuración del proxy no cambió nada. Lo que cambió es qué configuración leen ahora las aplicaciones: una entrada de túnel puede llevar su propia configuración de proxy, un perfil gestionado puede reactivar la configuración automática y algunos entornos de ejecución solo leen una parte de lo que ofrece el sistema operativo. Lee el valor por conexión antes de tocar el global.

Windows guarda un proxy por conexión

En las opciones de Internet hay dos capas que en el diálogo parecen idénticas. La configuración de la red local se aplica a la conexión local normal, mientras que una entrada de marcación o de VPN guarda su propia copia en HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections, almacenada como valor binario. Escribir los conocidos valores globales del registro no actualiza esa copia.

Así es exactamente como una herramienta se comporta bien antes de conectar y mal después, sin ningún cambio visible en su configuración. El diálogo que mirabas era el panel de la red local. Era correcto y era irrelevante. La entrada que Windows usaba de verdad era la creada para el túnel.

La forma admitida de cambiar una entrada es la API de opciones de conexión de WinINET: rellena un INTERNET_PER_CONN_OPTION_LIST con el nombre de la conexión, los indicadores, el servidor proxy y una lista de exclusiones, aplícalo y luego actualiza. Para una comprobación rápida, abre el diálogo de configuración de la propia entrada del túnel y compara su panel de proxy con el de la red local; la diferencia suele ser obvia en cuanto sabes dónde mirar.

Un PAC gestionado puede volver a activarse

En macOS, el script de configuración automática del proxy y el descubrimiento automático de proxy son propiedades de un servicio de red, no de la máquina. Un perfil de configuración puede exigirlos, así que reaparecen después de desmarcarlos, y cada petición se envía entonces al proxy que elija el script.

Inspecciona y, si tienes autorización, desactiva esos dos interruptores para el servicio que lleva el tráfico:

networksetup -setautoproxystate "Wi-Fi" off
networksetup -setproxyautodiscovery "Wi-Fi" off
scutil --proxy

Usa el nombre real del servicio en lugar de una suposición. Un portátil con red inalámbrica y un adaptador Ethernet USB tiene dos, y solo uno lleva tu tráfico. scutil --proxy imprime los valores del servicio principal actual. Compara esa salida con lo que editaste antes de concluir que el perfil ha ganado.

Apunta la herramienta al origen real

Si el script contiene el proxy corporativo, léelo e introduce esa misma dirección como proxy externo dentro de la herramienta de captura. Entonces la herramienta reenvía al origen real, que es lo que espera el proxy corporativo, y se queda en la ruta de la petición en lugar de pelearse con la política.

Ese es el movimiento que te mantiene depurando en lugar de reconfigurando.

Mete el proxy dentro del túnel

Un cliente basado en OpenVPN puede aceptar opciones de proxy que se aplican cuando el túnel ya está levantado, lo que resulta cómodo cuando el cliente es dueño de las rutas:

dhcp-option HTTPPROXY 127.0.0.1:8888
dhcp-option HTTPSPROXY 127.0.0.1:8888

Solo los clientes que respetan la opción la usarán, y esta fija tu puerto de escucha dentro de un perfil. Trátalo como una comodidad de laboratorio y no como un estándar de despliegue, porque el siguiente envío de perfil la eliminará.

Algunos clientes nunca leen el proxy del sistema

Firefox guarda su propia configuración de proxy, por eso a veces sigue capturando cuando un navegador con proxy del sistema no lo hace. Un cliente .NET antiguo que no entiende la configuración automática se conecta directamente donde quiera que se ejecute, así que una página que se carga por la entrada del túnel puede fallar dentro de la aplicación.

Las herramientas de red también tienen sus propias causas. Una sesión FTP que se cuelga a través de un túnel o de un tethering de teléfono suele ser un problema de modo activo frente a pasivo que negocia el cliente, y ningún ajuste de proxy lo cambiará.

Lee la configuración, no el interruptor

Trabaja en este orden: el valor de proxy propio de la entrada del túnel, el estado de PAC y descubrimiento automático por servicio y después la gestión de proxy de la propia aplicación. Detente en el primero que difiera de lo que suponías.

Todos los casos de aquí son un problema de precedencia de configuración. Ninguno es el túnel rompiendo tu herramienta.