mitmproxy, DevTools, Gradle: tres capas detrás da VPN
O loopback nunca entra no túnel. Clasifique o síntoma como oínte, almacén de confianza ou filtro de paquetes, e repare a capa que realmente fallou.
A VPN conéctase, e tres ferramentas sen relación fallan de tres maneiras distintas esa mesma tarde. mitmproxy deixa de ver peticións, Chrome rexeita o depurador e Gradle lanza BindException mentres enlaza un socket local. A sospeita compartida é que o túnel bloquea localhost. Non pode: 127.0.0.1 xestiónase dentro do kernel e nunca chega a un adaptador, e moito menos a unha pasarela.
Tres capas, tres avarías distintas
O que cambiou co cliente non é a ruta cara a loopback. Son un proxy local, un almacén de confianza da máquina e un filtro de paquetes, e cada un rompe unha parte distinta do fluxo de traballo dun desenvolvedor. Clasificar o síntoma na fila correcta é a maior parte do diagnóstico:
| Symptom | Layer | First check |
|---|---|---|
| Proxy sees no traffic | Local proxy or listener | ss -lntp, or netstat -ano on Windows |
| TLS error in one tool only | Trust store | Which CA bundle does that runtime read? |
| Local bind or connect refused | Packet filter or port owner | Who holds the port, and what rule drops it? |
Case todos os informes deste tipo comezan pola última fila e soben, o cal é ao revés. O túnel é a única capa que demostrablemente non pode ver tráfico de loopback, así que merece a menor sospeita. Comece polo que enlazou o proceso, logo pregunte en que certificados confía, e só despois mire a política da máquina.
Comece polo oínte, non polo túnel
Cando un proxy en 127.0.0.1:8080 deixa de recibir tráfico, ocorreu unha de tres cousas: nunca arrincou, enlazou outro porto ou o filtro descartou a conexión de loopback. Listar os sockets que escoitan respóndeo cun só comando, e tamén mostra que proceso posúe o porto cando dúas ferramentas non coinciden sobre quen chegou primeiro.
Un enderezo local nunha consulta de ruta confirma o mesmo desde a outra dirección. ip route get cara a un destino de loopback informa do dispositivo de loopback, nunca do túnel, que é unha frase útil de ter preparada cando alguén propón un cambio de encamiñamento como solución.
A capa de proxy: a contorna non é configuración
Moitos clientes corporativos executan un proxy HTTP e esperan que as aplicacións o usen. Establecer HTTPS_PROXY nun shell arranxa as ferramentas de liña de ordes que o respectan, e non fai nada por unha ferramenta que le o seu propio ficheiro de configuración. Gradle, Selenium e gRPC consultan cada un a súa propia configuración, e un proxy exportado nunha terminal é invisible para un demo iniciado polo IDE.
As ferramentas de contedores son o lugar habitual onde isto se fai visible. O loopback dun contedor é propio, así que 127.0.0.1 dentro do contedor nunca significa o proxy do anfitrión; fai falta o enderezo do anfitrión ou un axuste de rede do anfitrión. Unha solución que funciona no shell e falla na compilación adoita ser esta fila, non o túnel.
A capa de confianza: a ferramenta le outro almacén
A interceptación é o segundo cambio, e produce os erros máis enganosos. O cliente presenta o seu propio certificado para as conexións inspeccionadas, así que un navegador que confía na raíz corporativa ten éxito mentres unha ferramenta cun almacén de CA incluído falla. As peticións de Python a través de certifi son o caso clásico: o almacén do sistema operativo pode ser correcto e a petición aínda falla, porque esa contorna de execución nunca o le. O texto do erro raramente menciona a interceptación, e por iso esta fila diagnostícase mal como un punto final roto.
Compare o que o punto final presenta realmente co que a ferramenta validou. openssl s_client mostra a cadea que enviou o servidor; a saída de validación propia da ferramenta mostra que decidiu. Cando non coinciden, REQUESTS_CA_BUNDLE ou SSL_CERT_FILE é a panca para esa contorna de execución, e a raíz corporativa pertence ao almacén que esa contorna le, non a unha localización global que só algunhas ferramentas respectan.
Un cambio de versión que arranxa un erro SSL é evidencia sobre a política de confianza e de cifrado, non sobre a VPN. Unha baixada de versión de Python que fai funcionar un cliente SOAP cambiou o almacén de CA incluído e a configuración TLS predeterminada; a ruta de rede non se moveu.
A capa de filtro: tamén pode descartar loopback
O terceiro cambio é un filtro de paquetes, e algúns produtos instalan regras que descartan o tráfico que non entra no túnel. Os oíntes locais poden estar incluídos. Iso converte un socket que funcionaba nunha conexión rexeitada ou esgotada, e o erro resultante parece un fallo da aplicación máis que unha política da máquina.
A propiedade do porto é a outra metade desta capa. BindException significa que o socket non se puido abrir, o cal é un fallo distinto dunha conexión rexeitada. Comprobe se outro proceso xa ten o porto antes de culpar o filtro, logo busque unha regra que descarte o tráfico local e engada o permiso máis estreito que admita o produto. Dúas ferramentas que compiten polo mesmo porto de depuración producen exactamente a mesma mensaxe que un bloqueo de política, e só unha delas se corrixe cun cambio de devasas.
O porto de depuración de Chrome falla na mesma familia. O navegador arrinca, o controlador non chega ao punto final de DevTools e a mensaxe nomea DevTools en lugar da rede. Indicadores de lanzamento adicionais e un xestor de controladores redundante cambian que proceso posúe o porto, e por iso quitalos ás veces parece arranxar a VPN.
Repare a capa que fallou
Repare a capa que fallou, non o túnel. Un oínte de loopback inalcanzable necesita que se corrixan o seu oínte ou o seu porto. Un certificado non fiable necesita a raíz corporativa instalada onde mira esa contorna de execución concreta, coa excepción ben estreita. Un filtro que descarta o tráfico local necesita unha regra de permiso específica en lugar dun filtro desactivado, porque desactivalo tamén reabre todo o demais que protexía.
Reconectar a VPN non proba ningunha destas capas. Só volve executar o cambio que as rompeu, e por iso os mesmos tres fallos volven tras cada reconexión e desaparecen tras cada reinicio que deixa o cliente inactivo.