mitmproxy, DevTools, Gradle: tres capes darrere la VPN

La VPN es connecta, i tres eines sense relació fallen de tres maneres diferents el mateix migdia. mitmproxy deixa de veure peticions, Chrome refusa el depurador i Gradle llança BindException mentre enllaça un sòcol local. La sospita compartida és que el túnel bloqueja localhost. No pot: 127.0.0.1 es gestiona dins del nucli i no arriba mai a un adaptador, i encara menys a una passarel·la.

Tres capes, tres avaries diferents

El que ha canviat amb el client no és la ruta cap al loopback. Són un proxy local, un magatzem de confiança de la màquina i un filtre de paquets, i cadascun trenca una part diferent del flux de treball d’un desenvolupador. Col·locar el símptoma a la fila correcta és la major part del diagnòstic:

Gairebé tots els informes d’aquest tipus comencen per l’última fila i pugen, cosa que és al revés. El túnel és l’única capa que demostradament no pot veure el trànsit de loopback, així que mereix la menys sospita. Comenceu pel que ha enllaçat el procés, després pregunteu quins certificats confia, i només llavors mireu la política a la màquina.

Comenceu per l’oient, no pel túnel

Quan un proxy a 127.0.0.1:8080 deixa de rebre trànsit, ha passat una de tres coses: no s’ha iniciat mai, ha enllaçat un altre port o el filtre ha descartat la connexió de loopback. Llistar els sòcols que escolten ho respon amb una sola ordre, i també mostra quin procés té el port quan dues eines no es posen d’acord sobre qui va ser primer.

Una adreça local en una consulta de ruta confirma el mateix des de l’altra direcció. ip route get cap a una destinació de loopback informa del dispositiu de loopback, mai del túnel, que és una frase útil de tenir a punt quan algú proposa un canvi d’encaminament com a solució.

La capa de proxy: l’entorn no és configuració

Molts clients corporatius executen un proxy HTTP i esperen que les aplicacions l’utilitzin. Establir HTTPS_PROXY en un shell arregla les eines de línia d’ordres que l’honoren, i no fa res per a una eina que llegeix el seu propi fitxer de configuració. Gradle, Selenium i gRPC consulten cadascun la seva pròpia configuració, i un proxy exportat en un terminal és invisible per a un dimoni iniciat per l’IDE.

Les eines de contenidors són el lloc habitual on això es fa visible. El loopback d’un contenidor és seu, així que 127.0.0.1 dins del contenidor no significa mai el proxy de l’amfitrió; cal l’adreça de l’amfitrió o una configuració de xarxa de l’amfitrió. Una solució que funciona al shell i falla a la compilació sol ser aquesta fila, no el túnel.

La capa de confiança: l’eina llegeix un altre magatzem

La intercepció és el segon canvi, i produeix els errors més enganyosos. El client presenta el seu propi certificat per a les connexions inspeccionades, així que un navegador que confia en l’arrel corporativa té èxit mentre una eina amb un magatzem de CA inclòs falla. Les peticions de Python a través de certifi són el cas clàssic: el magatzem del sistema operatiu pot ser correcte i la petició encara falla, perquè aquest entorn d’execució no el llegeix mai. El text de l’error poques vegades esmenta la intercepció, i per això aquesta fila es diagnostica malament com un punt final trencat.

Compareu què presenta realment el punt final amb què ha validat l’eina. openssl s_client mostra la cadena que ha enviat el servidor; la sortida de validació pròpia de l’eina mostra què ha decidit. Quan no coincideixen, REQUESTS_CA_BUNDLE o SSL_CERT_FILE és la palanca per a aquell entorn d’execució, i l’arrel corporativa pertany al magatzem que llegeix aquell entorn, no a una ubicació global que només algunes eines honoren.

Un canvi de versió que arregla un error SSL és evidència sobre la política de confiança i de xifratge, no sobre la VPN. Una baixada de versió de Python que fa funcionar un client SOAP va canviar el magatzem de CA inclòs i la configuració TLS per defecte; el camí de xarxa no es va moure.

La capa de filtre: també pot descartar loopback

El tercer canvi és un filtre de paquets, i alguns productes instal·len regles que descarten el trànsit que no entra al túnel. Els oients locals hi poden estar inclosos. Això converteix un sòcol que funcionava en una connexió rebutjada o esgotada, i l’error resultant sembla un defecte de l’aplicació més que una política de la màquina.

La propietat del port és l’altra meitat d’aquesta capa. BindException significa que el sòcol no s’ha pogut obrir, cosa que és una fallada diferent d’una connexió rebutjada. Comproveu si un altre procés ja té el port abans de culpar el filtre, després busqueu una regla que descarti el trànsit local i afegiu el permís més estret que admeti el producte. Dues eines que competeixen pel mateix port de depuració produeixen exactament el mateix missatge que un bloc de política, i només una d’elles es corregeix amb un canvi de tallafocs.

El port de depuració de Chrome falla en la mateixa família. El navegador arrenca, el controlador no pot arribar al punt final de DevTools, i el missatge anomena DevTools en lloc de la xarxa. Els indicadors de llançament addicionals i un gestor de controladors redundant canvien quin procés té el port, i per això eliminar-los de vegades sembla que arregli la VPN.

Repareu la capa que ha fallat

Repareu la capa que ha fallat, no el túnel. Un oient de loopback inabastable necessita que es corregeixin el seu oient o el seu port. Un certificat no fiable necessita l’arrel corporativa instal·lada allà on mira aquest entorn d’execució concret, amb l’excepció ben estreta. Un filtre que descarta el trànsit local necessita una regla de permís específica en lloc d’un filtre desactivat, perquè desactivar-lo també reobre tota la resta que protegia.

Reconnectar la VPN no prova cap d’aquestes capes. Només torna a executar el canvi que les va trencar, i per això les mateixes tres fallades tornen després de cada reconnexió i desapareixen després de cada reinici que deixa el client inactiu.