mitmproxy, DevTools, Gradle: tres capas detrás de la VPN

La VPN se conecta, y tres herramientas sin relación fallan de tres maneras distintas esa misma tarde. mitmproxy deja de ver peticiones, Chrome rechaza al depurador y Gradle lanza BindException mientras enlaza un socket local. La sospecha compartida es que el túnel bloquea localhost. No puede: 127.0.0.1 se gestiona dentro del kernel y nunca llega a un adaptador, y mucho menos a una puerta de enlace.

Tres capas, tres averías distintas

Lo que cambió con el cliente no es la ruta hacia loopback. Son un proxy local, un almacén de confianza de la máquina y un filtro de paquetes, y cada uno rompe una parte distinta del flujo de trabajo de un desarrollador. Clasificar el síntoma en la fila correcta es la mayor parte del diagnóstico:

Casi todos los informes de este tipo empiezan por la última fila y suben, lo cual es al revés. El túnel es la única capa que demostrablemente no puede ver tráfico de loopback, así que merece la menor sospecha. Empiece por lo que enlazó el proceso, luego pregunte en qué certificados confía, y solo después mire la política de la máquina.

Empiece por el oyente, no por el túnel

Cuando un proxy en 127.0.0.1:8080 deja de recibir tráfico, ha ocurrido una de tres cosas: nunca arrancó, enlazó otro puerto o el filtro descartó la conexión de loopback. Listar los sockets que escuchan lo responde con un solo comando, y también muestra qué proceso posee el puerto cuando dos herramientas no coinciden sobre quién llegó primero.

Una dirección local en una consulta de ruta confirma lo mismo desde la otra dirección. ip route get hacia un destino de loopback informa del dispositivo de loopback, nunca del túnel, que es una frase útil de tener preparada cuando alguien propone un cambio de enrutamiento como solución.

La capa de proxy: el entorno no es configuración

Muchos clientes corporativos ejecutan un proxy HTTP y esperan que las aplicaciones lo usen. Establecer HTTPS_PROXY en un shell arregla las herramientas de línea de comandos que lo respetan, y no hace nada por una herramienta que lee su propio archivo de configuración. Gradle, Selenium y gRPC consultan cada uno su propia configuración, y un proxy exportado en una terminal es invisible para un demonio iniciado por el IDE.

Las herramientas de contenedores son el lugar habitual donde esto se hace visible. El loopback de un contenedor es propio, así que 127.0.0.1 dentro del contenedor nunca significa el proxy del anfitrión; hace falta la dirección del anfitrión o un ajuste de red del anfitrión. Una solución que funciona en el shell y falla en la compilación suele ser esta fila, no el túnel.

La capa de confianza: la herramienta lee otro almacén

La interceptación es el segundo cambio, y produce los errores más engañosos. El cliente presenta su propio certificado para las conexiones inspeccionadas, así que un navegador que confía en la raíz corporativa tiene éxito mientras una herramienta con un almacén de CA incluido falla. Las peticiones de Python a través de certifi son el caso clásico: el almacén del sistema operativo puede ser correcto y la petición aun así falla, porque ese entorno de ejecución nunca lo lee. El texto del error rara vez menciona la interceptación, y por eso esta fila se diagnostica mal como un punto final roto.

Compare lo que el punto final presenta realmente con lo que la herramienta validó. openssl s_client muestra la cadena que envió el servidor; la salida de validación propia de la herramienta muestra qué decidió. Cuando no coinciden, REQUESTS_CA_BUNDLE o SSL_CERT_FILE es la palanca para ese entorno de ejecución, y la raíz corporativa pertenece al almacén que ese entorno lee, no a una ubicación global que solo algunas herramientas respetan.

Un cambio de versión que arregla un error SSL es evidencia sobre la política de confianza y de cifrado, no sobre la VPN. Una bajada de versión de Python que hace funcionar a un cliente SOAP cambió el almacén de CA incluido y la configuración TLS predeterminada; la ruta de red no se movió.

La capa de filtro: también puede descartar loopback

El tercer cambio es un filtro de paquetes, y algunos productos instalan reglas que descartan el tráfico que no entra en el túnel. Los oyentes locales pueden estar incluidos. Eso convierte un socket que funcionaba en una conexión rechazada o agotada, y el error resultante parece un fallo de la aplicación más que una política de la máquina.

La propiedad del puerto es la otra mitad de esta capa. BindException significa que el socket no se pudo abrir, lo cual es un fallo distinto de una conexión rechazada. Compruebe si otro proceso ya tiene el puerto antes de culpar al filtro, luego busque una regla que descarte el tráfico local y añada el permiso más estrecho que admita el producto. Dos herramientas que compiten por el mismo puerto de depuración producen exactamente el mismo mensaje que un bloqueo de política, y solo una de ellas se corrige con un cambio de firewall.

El puerto de depuración de Chrome falla en la misma familia. El navegador arranca, el controlador no llega al punto final de DevTools y el mensaje nombra DevTools en lugar de la red. Indicadores de lanzamiento adicionales y un gestor de controladores redundante cambian qué proceso posee el puerto, y por eso quitarlos a veces parece arreglar la VPN.

Repare la capa que falló

Repare la capa que falló, no el túnel. Un oyente de loopback inalcanzable necesita que se corrijan su oyente o su puerto. Un certificado no confiable necesita la raíz corporativa instalada donde mira ese entorno de ejecución concreto, con la excepción bien estrecha. Un filtro que descarta el tráfico local necesita una regla de permiso específica en lugar de un filtro desactivado, porque desactivarlo también reabre todo lo demás que protegía.

Reconectar la VPN no prueba ninguna de estas capas. Solo vuelve a ejecutar el cambio que las rompió, y por eso los mismos tres fallos vuelven tras cada reconexión y desaparecen tras cada reinicio que deja inactivo al cliente.