VPN ativada e localhost deixa de funcionar: nome, proxy ou bind?

Seu servidor de desenvolvimento respondeu há um minuto, e agora que o túnel está ativo a requisição expira com um nome de host que você nunca digitou. Dois mecanismos explicam quase todos os casos, e de fora eles parecem idênticos. Um sufixo de busca transforma um nome curto em corporativo, enquanto um proxy envia o tráfego de loopback para um host que não consegue alcançá-lo. Separar os dois custa uma consulta e economiza a regra de firewall que você estava prestes a escrever.

Quando localhost resolve na zona corporativa

Verifique para o que o nome resolve enquanto o túnel está ativo, depois execute a mesma consulta com o túnel desligado e compare as duas respostas. A pista é um endereço na faixa corporativa onde você esperava 127.0.0.1. Um registro como localhost.mycompany.corp vence a entrada de loopback assim que o cliente adiciona esse sufixo à lista de busca, e a requisição viaja para um host privado onde nada escuta nessa porta. Leia a lista de busca em vez de adivinhá-la, porque um cliente pode adicionar mais de um domínio e a ordem decide qual candidato é testado primeiro:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Substitua o nome do host pelo endereço literal na aplicação, no cliente de banco de dados ou na URL do notebook, e repita a requisição. Se a falha desaparecer, você tinha um problema de nomes e o túnel era apenas o gatilho. Se persistir, o ouvinte ou a rota é o próximo suspeito e o nome era uma pista falsa.

Configurações de proxy que capturam loopback

Um proxy de sistema aplicado quando o túnel sobe aceitará uma requisição para 127.0.0.1 e a encaminhará a um proxy remoto que não faz ideia do que você queria dizer. Uma lista de exceções vazia transforma uma requisição local em remota, e a mensagem de erro raramente diz isso. Adicione os endereços de loopback à lista de exceções para toda a sessão e não para um único comando, e depois confirme que a ferramenta a respeita antes de concluir qualquer coisa sobre a rede.

Frameworks de aplicação leem suas próprias variáveis de ambiente e às vezes seu próprio arquivo de configuração, então uma exceção que funciona para uma ferramenta não prova nada para a seguinte. Navegadores acrescentam uma nuance: navegadores baseados em Chromium ignoram o proxy para loopback de forma implícita, e um token de exceção pode remover esse comportamento. Verifique a decisão efetiva do proxy em vez de supor que a configuração do sistema operacional é toda a história. Dois comandos resolvem isso para qualquer coisa iniciada a partir de um shell:

curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool

O endereço de bind decide quem pode conectar

Um servidor iniciado em 127.0.0.1 aceita conexões apenas daquela máquina, o que costuma ser o padrão correto para desenvolvimento. Um servidor em 0.0.0.0 responde em todas as interfaces, incluindo o adaptador VPN, o que é mais exposição do que a maioria das pessoas pretende. Quando o endereço literal de loopback falha, verifique o bind antes de qualquer outra coisa.

Olhe para o socket em escuta e anote o endereço ao qual ele está vinculado, não apenas a porta. Se outro dispositivo ou um contêiner precisar alcançar o serviço pelo túnel, vincule à interface específica que ele usará e permita essa porta deliberadamente. Se apenas sua própria máquina precisar, mantenha o bind estreito e corrija o cliente em vez de ampliar o servidor. Um redirecionamento de porta ou uma camada de túneis pode unir os dois, mas cada um adiciona um componente que depois precisará de sua própria depuração.

Onde uma ferramenta de depuração espera a LAN

Ferramentas de depuração carregam suposições que um túnel quebra em silêncio. Uma ponte de depuração de telefone perde o dispositivo quando a VPN captura a sub-rede do dispositivo, então reconectar pelo endereço LAN ou um cabo evita o conflito. Um hub de automação de navegador expira quando o hub só é acessível pelo proxy, ou quando um firewall local descarta sua porta de controle. Um depurador remoto pode exigir elevação e um endereço de loopback onde o cliente reescreveu a rota.

Identifique a porta de controle e a porta de dados separadamente, pois muitas vezes uma sobrevive enquanto a outra não. Depois decida se a correção pertence à configuração da ferramenta, a uma rota para essa sub-rede ou a uma regra de tunelamento dividido. Editar um arquivo hosts em cada máquina de desenvolvedor escala pior e é esquecido primeiro. Prefira a configuração que vive com o perfil e que pode ser revisada por quem possui o túnel.

Pare na primeira etapa que falha

Desça por três etapas: resolva o nome, abra um socket para o endereço literal e depois deixe a ferramenta fazer sua própria conexão. Cada etapa elimina uma camada, então a primeira falha nomeia a camada a corrigir e tudo depois dela fica sem teste. Anote o resultado antes de mudar qualquer coisa, porque uma correção aplicada antes da medição não se distingue da sorte. Se a primeira tentativa falhar e uma nova funcionar, o túnel provavelmente não estava pronto quando a ferramenta iniciou.

Substitua a espera fixa por uma verificação de prontidão limitada que espera a rota, e mantenha a etapa que falha no log para que a próxima pessoa veja onde parou. Uma ferramenta que se recupera sozinha não está consertada, ela tem sorte, e a sorte acaba na máquina de outra pessoa. Mude o túnel por último, e apenas para a etapa que realmente falhou. Essa ordem também é o caminho mais curto de volta a uma compilação funcional, porque impede você de reconstruir um componente que nunca esteve envolvido.