Git bloquéase en WSL2 cunha VPN: MTU da interface ou da ruta?

O clon autentícase, aparece a conta de obxectos e entón nada se move durante minutos. Windows informa de que a VPN está conectada, o nome de host resólvese e un navegador na mesma máquina obtén a mesma páxina do repositorio sen dificultade. Esa combinación apunta ao tamaño do paquete e non ás credenciais, e a cuestión do tamaño debe exporse en dous lugares porque WSL2 ten a súa propia interface Linux co seu propio MTU. Un número pertence ao lado Windows da ruta, o outro á distribución, e ler só o adaptador VPN deixa medio camiño sen examinar.

Tres sinais separan un problema de tamaño doutro

O primeiro sinal é a forma: o establecemento da conexión e un intercambio pequeno teñen éxito, e despois a transferencia masiva deixa de avanzar. O segundo é a simetría: o mesmo repositorio e o mesmo transporte fallan mentres outro host na mesma ruta funciona, ou o fallo cambia co tamaño da carga útil e non coa hora do día. O terceiro é o silencio: ningún erro de autenticación, ningún rexeitamento do proxy, ningún fallo de resolución de nomes, só unha transferencia que nunca remata.

Esas tres xuntas xustifican unha hipótese de tamaño de paquete. Un fallo de DNS, un token caducado, unha chave SSH rexeitada e un proxy que rexeita CONNECT producen cada un o seu propio erro, e ningún se parece a un bloqueo despois do éxito. Manter o mesmo repositorio, transporte e xanela temporal durante a proba é o que fai honesta a comparación.

Compare ambas as interfaces antes de decidir

Reúna a vista de Windows e a vista de Linux na mesma sesión, e conserve o enderezo do repositorio en lugar de adiviñar que interface o transporta. O comando seguinte resolve primeiro o destino para que a consulta de ruta describa o servidor real co que contacta o clon, que pode diferir do nome que mostrou un navegador. Execute ambas as metades moi seguidas, porque a VPN pode cambiar as métricas da interface entre intentos.

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 de Linux dentro da distribución en lugar de pegar a saída nun shell de Windows, xa que os nomes de interface e a selección de ruta só teñen sentido alí. Unha pega desde un shell de Windows informa de números equivocados con grande confianza. Anote o dispositivo, a ruta seleccionada e o MTU de cada lado antes de cambiar nada.

Decida se o número debería ser menor

Un MTU de interface maior do que a ruta pode transportar non é automaticamente un defecto, porque o descubrimento do MTU de ruta existe precisamente para iso. O modo de fallo aparece cando se suprime o descubrimento: as mensaxes ICMP fíltranse nalgún punto do camiño, o emisor nunca aprende o límite e os paquetes grandes desaparecen mentres os pequenos pasan. Iso é unha propiedade da ruta, non unha propiedade de Git. Tamén é a razón pola que un ficheiro pequeno pode ter éxito nunha conexión onde un grande nunca remata.

Se as probas o apoian, un cambio temporal na interface Linux é a proba máis barata. Escolla un valor por baixo do tamaño útil da ruta, anote o anterior e manteña todo o demais constante para que a comparación signifique algo. Se a transferencia remata co valor menor, ten un diagnóstico e non unha coincidencia.

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

Decida onde debe vivir o axuste

Da proba derivan tres opcións, e normalmente só unha é axeitada. Se o valor menor corrixe a transferencia e o valor é realmente necesario para esta rede, o axuste necesita un propietario do ciclo de vida: un gancho de inicio na distribución, unha configuración de rede xestionada pola plataforma ou un procedemento documentado. Se o valor non corrixe nada, reverta e volva ás cuestións de transporte, proxy e autenticación.

Que exista un gancho de inicio depende das versións de Windows e WSL en uso e do modo de rede configurado. Reflectir a rede de Windows pode cambiar como interactúa unha VPN coa distribución de maneiras que importan máis que un axuste de MTU, así que identifique o modo antes de deseñar unha solución alternativa para el. Un valor que serve para un operador ou un perfil de VPN non é un valor predeterminado para o seguinte.

O que hai que evitar é a ubicación tentadora: un comando de rede privilexiado no ficheiro de inicio de cada shell interactivo, ou sudo sen contrasinal para todo o binario ip para que un script poida executar unha liña. Ambas as cousas converten un diagnóstico nunha exposición permanente e fan que o problema orixinal sexa máis difícil de ver despois.

Verifique tras un inicio limpo e logo reverta

Un cambio que só sobrevive ata que se reinicia a distribución non é unha solución. Reinicie a distribución, volva conectar a VPN e repita a operación de Git orixinal en lugar dun substituto como ping ou unha petición HTTP pequena. Despois confirme que a interface leva o valor previsto na sesión nova.

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

Manteña o valor orixinal anotado xunto ao cambio para que o experimento poida desfacerse limpamente, e anote que familia de enderezos se probou, xa que un resultado IPv4 non di nada sobre unha conexión IPv6 no mesmo host. A documentación de redes de WSL describe os modos que determinan como debe ser unha solución; o número de MTU é unha medida local, non unha recomendación.