mitmproxy, DevTools, Gradle: três camadas atrás da VPN

A VPN conecta-se, e três ferramentas sem relação falham de três maneiras diferentes na mesma tarde. o mitmproxy deixa de ver pedidos, o Chrome recusa o depurador e o Gradle lança BindException ao ligar um socket local. A suspeita partilhada é que o túnel bloqueia o localhost. Não pode: 127.0.0.1 é tratado dentro do kernel e nunca chega a um adaptador, muito menos a uma gateway.

Três camadas, três avarias diferentes

O que mudou com o cliente não é a rota para o loopback. São um proxy local, um armazenamento de confiança da máquina e um filtro de pacotes, e cada um quebra uma parte diferente do fluxo de trabalho de um programador. Colocar o sintoma na linha certa é a maior parte do diagnóstico:

Quase todos os relatórios deste tipo começam na última linha e sobem, o que está ao contrário. O túnel é a única camada que, comprovadamente, não consegue ver tráfego de loopback, por isso merece a menor suspeita. Comece pelo que o processo ligou, depois pergunte em que certificados confia, e só então olhe para a política na máquina.

Comece pelo ouvinte, não pelo túnel

Quando um proxy em 127.0.0.1:8080 deixa de receber tráfego, aconteceu uma de três coisas: nunca arrancou, ligou outra porta, ou o filtro descartou a ligação de loopback. Listar os sockets à escuta responde a isso com um único comando, e também mostra que processo detém a porta quando duas ferramentas discordam sobre quem chegou primeiro.

Um endereço local numa pesquisa de rota confirma o mesmo do outro lado. ip route get para um destino de loopback reporta o dispositivo de loopback, nunca o túnel, o que é uma frase útil de ter pronta quando alguém propõe uma alteração de encaminhamento como solução.

A camada de proxy: o ambiente não é configuração

Muitos clientes empresariais executam um proxy HTTP e esperam que as aplicações o usem. Definir HTTPS_PROXY num shell corrige as ferramentas de linha de comandos que o respeitam, e não faz nada por uma ferramenta que lê o seu próprio ficheiro de definições. O Gradle, o Selenium e o gRPC consultam cada um a sua própria configuração, e um proxy exportado num terminal é invisível para um daemon iniciado pelo IDE.

As ferramentas de contentores são o local habitual onde isto se torna visível. O loopback de um contentor é o seu próprio, por isso 127.0.0.1 dentro do contentor nunca significa o proxy do anfitrião; é necessário o endereço do anfitrião ou uma definição de rede do anfitrião. Uma correção que funciona no shell e falha na compilação é normalmente esta linha, não o túnel.

A camada de confiança: a ferramenta lê outro armazenamento

A interceção é a segunda mudança, e produz os erros mais enganadores. O cliente apresenta o seu próprio certificado para as ligações inspecionadas, por isso um navegador que confia na raiz empresarial tem sucesso enquanto uma ferramenta com um armazenamento de CA incluído falha. Os requests de Python através do certifi são o caso clássico: o armazenamento do sistema operativo pode estar correto e o pedido falhar mesmo assim, porque esse ambiente de execução nunca o lê. O texto do erro raramente menciona a interceção, e é por isso que esta linha é mal diagnosticada como um endpoint quebrado.

Compare o que o endpoint apresenta realmente com o que a ferramenta validou. openssl s_client mostra a cadeia enviada pelo servidor; a saída de validação da própria ferramenta mostra o que decidiu. Quando não coincidem, REQUESTS_CA_BUNDLE ou SSL_CERT_FILE é a alavanca para esse ambiente de execução, e a raiz empresarial pertence ao armazenamento que esse ambiente lê, não a um local global que só algumas ferramentas respeitam.

Uma mudança de versão que corrige um erro SSL é evidência sobre a política de confiança e de cifra, não sobre a VPN. Uma descida de versão do Python que faz funcionar um cliente SOAP alterou o armazenamento de CA incluído e as definições TLS predefinidas; o caminho de rede não se moveu.

A camada de filtro: também pode descartar loopback

A terceira mudança é um filtro de pacotes, e alguns produtos instalam regras que descartam o tráfego que não entra no túnel. Os ouvintes locais podem estar incluídos. Isso transforma um socket que funcionava numa ligação recusada ou expirada, e o erro resultante parece um defeito da aplicação em vez de uma política da máquina.

A propriedade da porta é a outra metade desta camada. BindException significa que o socket não pôde ser aberto, o que é uma falha diferente de uma ligação recusada. Verifique se outro processo já detém a porta antes de culpar o filtro, depois procure uma regra que descarte o tráfego local e acrescente a permissão mais estreita que o produto suporta. Duas ferramentas a competir pela mesma porta de depuração produzem exatamente a mesma mensagem que um bloqueio de política, e só uma delas se corrige com uma alteração de firewall.

A porta de depuração do Chrome falha na mesma família. O navegador arranca, o controlador não alcança o endpoint do DevTools, e a mensagem nomeia o DevTools em vez da rede. Indicadores de arranque adicionais e um gestor de controladores redundante alteram qual processo detém a porta, e é por isso que removê-los às vezes parece corrigir a VPN.

Repare a camada que falhou

Repare a camada que falhou, não o túnel. Um ouvinte de loopback inalcançável precisa que o seu ouvinte ou a sua porta sejam corrigidos. Um certificado não fidedigno precisa da raiz empresarial instalada onde esse ambiente de execução específico olha, com a exceção mantida estreita. Um filtro que descarta o tráfego local precisa de uma regra de permissão concreta em vez de um filtro desativado, porque desativar também reabre tudo o resto que ele protegia.

Reconectar a VPN não testa nenhuma destas camadas. Limita-se a executar de novo a mudança que as quebrou, e é por isso que as mesmas três falhas voltam após cada reconexão e desaparecem após cada reinício que deixa o cliente inativo.