O WSL2 não herda a VPN corporativa, e é exatamente esse o bug

O wiki interno carrega no Edge, enquanto o git clone dentro da distribuição expira. Essa única observação costuma ser lida como «a VPN está bloqueando o WSL2», e a hora seguinte vai para editar o /etc/resolv.conf. A leitura mais útil é que o WSL2 nunca teve o caminho de rede do host: ele roda numa VM auxiliar com o próprio adaptador, as próprias rotas e um arquivo de resolver que o Windows gera para ele. Tudo o que vem depois depende de qual desses três você realmente não tem.

A VM tem a própria pilha, métrica e resolver

No modo NAT padrão, a distribuição fica atrás de um switch virtual e alcança a internet pelo host, mas não vê os adaptadores do host. ip addr mostra uma interface com endereço privado, ip route mostra uma rota padrão por esse switch, e /etc/resolv.conf é um arquivo gerado que aponta para um stub resolver escolhido pelo Windows. Nada disso muda porque um cliente VPN subiu do lado do Windows.

Por isso «o navegador funciona» prova tão pouco. O navegador usa a pilha do host, o túnel e a política de resolver do host. O seu shell usa outra pilha que por acaso compartilha uma placa de rede física. Elas concordam no caso feliz e divergem exatamente quando a VPN instala um filtro, reescreve a lista de DNS ou adiciona uma rota para a sub-rede do switch virtual.

Dois testes decidem em que mundo você está, e eles precisam rodar dentro da distribuição:

getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.conf

Nomes falharem enquanto um endereço literal responde é um problema de resolver. Nomes e endereços falharem juntos é um problema de caminho, e nenhuma edição de resolver vai tocar nisso. As evidências do lado do Windows vêm em seguida: Get-NetAdapter | Get-DnsClientServerAddress e route print -4 mostram se o túnel tomou a sub-rede onde sua VM vive.

Mito um: os servidores DNS corporativos resolvem

Editar o arquivo de resolver é o conselho clássico, e ele acerta mais ou menos metade das vezes. Quando acerta, é por um motivo específico: o arquivo gerado aponta para um resolver que só conhece nomes públicos, então uma consulta para intranet.example.internal volta como inexistente mesmo que o caminho esteja bom.

Fixar os servidores da VPN significa impedir o Windows de regenerar o arquivo, porque qualquer arquivo escrito à mão é substituído na próxima inicialização:

[network]
generateResolvConf = false

Salve isso como /etc/wsl.conf, execute wsl --shutdown a partir do Windows, depois inicie a distribuição e escreva /etc/resolv.conf com os servidores do túnel primeiro e um resolver público só como reserva. É uma mudança duradoura com custo de manutenção: o arquivo não segue mais o host, então quando os endereços DNS corporativos mudam a distribuição continua perguntando pelos antigos. Alguém precisa ser dono desse arquivo.

Também não faz nada quando a falha é mais ampla. Se curl para 1.1.1.1 expira, o cliente do túnel está filtrando o switch virtual ou encaminhando a sub-rede da VM para dentro do túnel, e um resolver correto só entrega nomes que ainda não podem ser alcançados.

Mito dois: a mudança de métrica se mantém

Quando os nomes resolvem mas o tráfego sai pelo adaptador físico, a alavanca são as métricas de interface. Dê custo alto ao adaptador da VPN e baixo ao switch WSL:

Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1

Depois lembre que em muitas compilações do cliente o adaptador do túnel é recriado a cada conexão e a métrica volta ao padrão. Um comando único é uma correção que expira em silêncio, geralmente durante um fim de semana, e o chamado volta com «na semana passada funcionava». Uma tarefa agendada disparada pelo evento da VPN, ou um script que o usuário executa após conectar, é a versão honesta dessa correção.

A mesma expiração vale para rotas de host adicionadas para um prefixo teimoso. Elas valem como diagnóstico, porque dizem se o problema é um destino ou o caminho inteiro, mas não são arquitetura.

Mito três: uma correção cobre toda compilação do Windows

wsl-vpnkit é o padrão sidecar: uma distribuição pequena é dona do caminho do lado do host e encaminha para outras distribuições por um soquete virtual, então o tráfego das aplicações deixa de depender do switch filtrado. Ele exige que o caminho padrão funcione, o que significa remover as sobreposições networkingMode e dnsTunneling do %UserProfile%\.wslconfig, restaurar generateResolvConf = true em cada distribuição que funcione e iniciar o serviço no login.

O modo espelhado é a alternativa embutida no Windows 11 22H2 e posteriores, e é uma configuração mais um desligamento:

[wsl2]
networkingMode=mirrored

Dentro da distribuição o ip addr então lista os adaptadores do host, o túnel pode aparecer entre eles, e o tunelamento de DNS encaminha consultas pelo resolver do Windows mesmo quando o cliente reescreve a lista de DNS. Não é universal: alguns drivers de filtro ainda descartam o caminho espelhado, e as regras de firewall do Hyper-V podem precisar de uma permissão explícita. O guia de redes do WSL da Microsoft é a página que você deve comparar com a sua compilação antes de aplicar uma receita escrita para uma mais nova.

Teste três coisas após cada mudança

Escolha um mecanismo por máquina e anote, porque os dois se combinam mal. Um sidecar sobre o modo espelhado dobra o encaminhamento, e um host espelhado com uma entrada de sidecar desatualizada no .wslconfig tende a falhar depois de uma atualização, não antes.

Escolha o que escolher, o teste de aceitação são as mesmas três requisições dentro da distribuição: um nome interno, um nome público e um endereço bruto. Depois repita-as após desconectar e reconectar o túnel, e após wsl --shutdown. Só o nome interno falhar significa política de resolver; nomes interno e público falharem juntos com um endereço funcionando ainda significa política de resolver; tudo falhar significa o caminho.

Se um host interno falha enquanto o resto funciona, pare de olhar o resolver e procure uma rota ausente para esse prefixo. Se tudo funciona até a próxima reconexão, você encontrou uma correção que depende do estado em tempo de execução, e ela precisa ser reaplicada automaticamente ou substituída por um dos dois mecanismos acima.