Git trava em WSL2 com VPN: MTU da interface ou do caminho?

O clone autentica, a contagem de objetos aparece e então nada se move por minutos. O Windows informa que a VPN está conectada, o nome do host é resolvido e um navegador na mesma máquina obtém a mesma página do repositório sem dificuldade. Essa combinação aponta para o tamanho do pacote e não para as credenciais, e a questão do tamanho precisa ser feita em dois lugares porque o WSL2 tem a própria interface Linux com o próprio MTU. Um número pertence ao lado Windows do caminho, o outro à distribuição, e ler só o adaptador VPN deixa metade do caminho sem exame.

Três sinais separam um problema de tamanho de outro

O primeiro sinal é a forma: o estabelecimento da conexão e uma pequena troca funcionam, e depois a transferência em massa para de avançar. O segundo é a simetria: o mesmo repositório e o mesmo transporte falham enquanto outro host no mesmo caminho funciona, ou a falha muda com o tamanho da carga útil e não com a hora do dia. O terceiro é o silêncio: nenhum erro de autenticação, nenhuma recusa do proxy, nenhuma falha de resolução de nomes, apenas uma transferência que nunca termina.

Esses três juntos justificam uma hipótese de tamanho de pacote. Uma falha de DNS, um token expirado, uma chave SSH recusada e um proxy que recusa CONNECT produzem cada um o seu próprio erro, e nenhum deles parece um travamento após sucesso. Manter o mesmo repositório, transporte e janela de tempo durante o teste é o que torna a comparação honesta.

Compare as duas interfaces antes de decidir

Reúna a visão do Windows e a visão do Linux na mesma sessão, e mantenha o endereço do repositório em vez de adivinhar qual interface o carrega. O comando abaixo resolve primeiro o destino para que a consulta de rota descreva o servidor real que o clone contata, que pode diferir do nome mostrado por um navegador. Execute as duas metades próximas uma da outra, porque a VPN pode mudar as métricas da interface entre tentativas.

netsh interface ipv4 show subinterfaces
wsl -d Ubuntu -- bash -lc 'dest=$(getent ahostsv4 github.com | awk \'NR==1{print $1}\'); ip -br link show; ip route get "$dest"'

Execute a metade Linux dentro da distribuição em vez de colar a saída num shell do Windows, já que os nomes de interface e a seleção de rota só fazem sentido lá. Uma colagem de um shell do Windows informa os números errados com grande confiança. Anote o dispositivo, a rota selecionada e o MTU de cada lado antes de mudar qualquer coisa.

Decida se o número deve ser menor

Um MTU de interface maior do que o caminho consegue transportar não é automaticamente um defeito, porque a descoberta do MTU do caminho existe exatamente para isso. O modo de falha aparece quando a descoberta é suprimida: as mensagens ICMP são filtradas em algum ponto do caminho, o emissor nunca aprende o limite e os pacotes grandes desaparecem enquanto os pequenos passam. Isso é uma propriedade do caminho, não uma propriedade do Git. É também a razão pela qual um arquivo pequeno pode ter sucesso numa conexão em que um grande nunca termina.

Se as evidências apoiarem, uma mudança temporária na interface Linux é o teste mais barato. Escolha um valor abaixo do tamanho útil do caminho, anote o anterior e mantenha todo o resto constante para que a comparação signifique algo. Se a transferência terminar com o valor menor, você tem um diagnóstico e não uma coincidência.

ip -br link show dev eth0
sudo ip link set dev eth0 mtu 1380
ip -br link show dev eth0

Decida onde o ajuste deve viver

Três opções decorrem do teste, e normalmente apenas uma é adequada. Se o valor menor corrigir a transferência e o valor for realmente necessário para esta rede, o ajuste precisa de um proprietário do ciclo de vida: um gancho de inicialização na distribuição, uma configuração de rede gerida pela plataforma ou um procedimento documentado. Se o valor não corrigir nada, reverta-o e volte às questões de transporte, proxy e autenticação.

A existência de um gancho de inicialização depende das versões de Windows e WSL em uso e do modo de rede configurado. Espelhar a rede do Windows pode mudar a forma como uma VPN interage com a distribuição, de maneiras que importam mais do que um ajuste de MTU, por isso identifique o modo antes de desenhar uma solução alternativa para ele. Um valor que serve para um operador ou um perfil de VPN não é um padrão para o seguinte.

O que deve ser evitado é a colocação tentadora: um comando de rede privilegiado no arquivo de inicialização de cada shell interativo, ou sudo sem palavra-passe para todo o binário ip para que um script possa executar uma linha. Ambos transformam um diagnóstico em exposição permanente e tornam o problema original mais difícil de ver depois.

Verifique após um início limpo e depois reverta

Uma mudança que só sobrevive até a distribuição reiniciar não é uma correção. Reinicie a distribuição, reconecte a VPN e repita a operação Git original em vez de um substituto como ping ou um pequeno pedido HTTP. Depois confirme que a interface carrega o valor pretendido na nova sessão.

ip -br link show dev eth0
ip route get "$(getent ahostsv4 github.com | awk 'NR==1{print $1}')"

Mantenha o valor original anotado junto da mudança para que a experiência possa ser desfeita de forma limpa, e anote que família de endereços foi testada, já que um resultado IPv4 não diz nada sobre uma conexão IPv6 no mesmo host. A documentação de rede do WSL descreve os modos que determinam como uma correção deve parecer; o próprio número de MTU é uma medição local, não uma recomendação.