WSL2 não alcança a sub-rede VPN: leia a rota do host

De dentro da distribuição, um ping para um servidor interno expira enquanto o mesmo endereço responde do Windows. A VPN está conectada e a rota do Windows está correta, então a lacuna é a fronteira do WSL. Percorra o caminho do comando que falha até a interface do host. A correção não é um CIDR fixo num arquivo de configuração; é ler o endereço atual e adicioná-lo onde a distribuição possa usá-lo.

Confirme onde o caminho para

Execute o mesmo teste dos dois lados: resolva e conecte-se a um host interno pelo Windows e repita na distribuição. Um sucesso no Windows mais um tempo limite na distribuição localizam a falha entre os dois, não no cliente VPN nem no servidor interno. Faça isso antes de mudar qualquer rota, para que os dois resultados descrevam o mesmo destino.

Dentro da distribuição, ip -4 addr mostra um adaptador virtual com um endereço da faixa NAT do WSL, e ip route mostra uma rota padrão para o gateway do WSL. Não há rota para o prefixo corporativo, porque o adaptador de túnel do host não tem equivalente dentro da distribuição. O gateway padrão leva ao NAT do WSL, não à rede corporativa.

Adicionar a rota corporativa sem antes adicionar um endereço local num enlace alcançável produz um tempo limite ou um erro de rede inalcançável. O endereço é a parte que torna a rota utilizável, então leia-o primeiro e trate a rota como o segundo passo.

Escolha rede espelhada ou uma rota com script

A rede espelhada entrega à distribuição as interfaces do próprio host, então o túnel e suas rotas aparecem sem copiar. O recurso depende de uma compilação recente do Windows e de networkingMode=mirrored em .wslconfig, e ativá-lo muda comportamentos não relacionados, como o encaminhamento de localhost. Trate isso como uma mudança de plataforma, não como um ajuste de rota. Se a compilação oferece suporte e os efeitos colaterais são aceitáveis, é o caminho mais curto.

A abordagem mais estreita mantém o NAT padrão e copia o endereço e a rota do túnel para a distribuição sempre que o túnel sobe. Funciona em mais compilações, não muda o comportamento de localhost e falha de forma visível quando a VPN está desligada. O custo é um script pequeno que precisa rodar a cada conexão.

Escolha um e escreva-o. Misturar uma configuração espelhada com rotas manuais produz uma distribuição com dois caminhos para o mesmo prefixo e sem dono claro para nenhum deles. Um método documentado é mais fácil de depurar do que dois meio configurados.

Obtenha os detalhes atuais do túnel do host

Combine o adaptador pelo endereço MAC e não pelo nome, porque os nomes mudam com o cliente VPN e a ordem de conexão. Liste os adaptadores uma vez, anote o MAC do adaptador de túnel e consulte o endereço e o prefixo. O MAC permanece com o adaptador virtual entre reconexões, enquanto o nome e o índice da interface não:

powershell.exe 'Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" } | Get-NetIPAddress -AddressFamily IPv4 | Select-Object IPAddress, PrefixLength'

O gateway vem da configuração da interface. Obtenha primeiro o índice da interface e depois leia o próximo salto. O índice pode mudar após um reinício ou um reset do adaptador, por isso o script deve lê-lo em vez de armazená-lo:

powershell.exe '(Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" }).InterfaceIndex'
powershell.exe '(Get-NetIPConfiguration -InterfaceIndex 27).IPv4DefaultGateway.NextHop'

Passe a saída por tr -d '\r' antes de atribuí-la a uma variável. O PowerShell termina as linhas com um retorno de carro, e sem a remoção o último campo carrega um caractere oculto que faz um comando de rota falhar com um erro de análise confuso.

Aplique o endereço e a rota dentro da distribuição

Instale o endereço do túnel como endereço com prefixo na interface da distribuição e depois encaminhe o bloco corporativo pelo gateway do host:

sudo ip addr add 172.20.14.37/22 dev vpn
sudo ip route add 172.20.0.0/16 via 172.20.12.1 dev vpn

O NetworkManager descarta um endereço configurado manualmente quando a conexão reinicia, e nenhum cliente DHCP pede um substituto. Defina o método como automático para que cada reconexão atualize o endereço e depois suba a conexão novamente. O método manual parece estável até a primeira reconexão:

nmcli con show vpn
sudo nmcli con mod vpn ipv4.method auto
sudo nmcli con up vpn

Execute os dois passos a partir do hook que inicia a VPN, não de um shell interativo. Um script que lê o endereço, adiciona-o, adiciona a rota e registra os valores transforma um reparo manual recorrente em repetível, e o log é a primeira coisa a ler quando o prefixo muda.

Fixe o nome e prove o caminho

O kernel pode renomear a interface da distribuição entre eth1 e eth2 após uma troca de rede, e um script escrito para um nome edita então o dispositivo errado. Uma regra udev vinculada ao MAC dá à interface um rótulo estável:

SUBSYSTEM=="net", ACTION=="add", ATTRS{address}=="3c:52:82:0a:1b:7c", NAME="vpn"

Depois verifique com o endereço, a rota e uma conexão TCP real: ip -4 addr show dev vpn, ip route get 172.20.4.10 e uma conexão a uma porta interna conhecida. A consulta de rota deve nomear o dispositivo vpn e o endereço de origem que você adicionou.

Se as três provas passarem dentro da distribuição e a conexão ainda falhar, o pacote está saindo do WSL e sendo descartado no lado do Windows. Verifique o firewall do host e a filtragem do próprio cliente VPN antes de mudar o script, porque outra edição de rota não corrigirá um pacote que já chega ao host.