Git se bloquea en WSL2 con una VPN: ¿MTU de la interfaz o de la ruta?

El clon se autentica, aparece el recuento de objetos y entonces nada se mueve durante minutos. Windows informa de que la VPN está conectada, el nombre de host se resuelve y un navegador en la misma máquina obtiene la misma página del repositorio sin dificultad. Esa combinación apunta al tamaño del paquete y no a las credenciales, y la cuestión del tamaño debe plantearse en dos lugares porque WSL2 tiene su propia interfaz Linux con su propio MTU. Un número pertenece al lado Windows de la ruta, el otro a la distribución, y leer solo el adaptador VPN deja medio camino sin examinar.

Tres señales separan un problema de tamaño de otro

La primera señal es la forma: el establecimiento de la conexión y un intercambio pequeño tienen éxito, y luego la transferencia masiva deja de avanzar. La segunda es la simetría: el mismo repositorio y el mismo transporte fallan mientras otro host en la misma ruta funciona, o el fallo cambia con el tamaño de la carga útil y no con la hora del día. La tercera es el silencio: ningún error de autenticación, ningún rechazo del proxy, ningún fallo de resolución de nombres, solo una transferencia que nunca termina.

Esas tres juntas justifican una hipótesis de tamaño de paquete. Un fallo de DNS, un token caducado, una clave SSH rechazada y un proxy que rechaza CONNECT producen cada uno su propio error, y ninguno se parece a un bloqueo después del éxito. Mantener el mismo repositorio, transporte y ventana temporal durante la prueba es lo que hace honesta la comparación.

Compare ambas interfaces antes de decidir

Reúna la vista de Windows y la vista de Linux en la misma sesión, y conserve la dirección del repositorio en lugar de adivinar qué interfaz la transporta. El comando siguiente resuelve primero el destino para que la consulta de ruta describa el servidor real con el que contacta el clon, que puede diferir del nombre que mostró un navegador. Ejecute ambas mitades muy seguidas, porque la VPN puede cambiar las métricas de la interfaz 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"'

Ejecute la mitad de Linux dentro de la distribución en lugar de pegar la salida en un shell de Windows, ya que los nombres de interfaz y la selección de ruta solo tienen sentido allí. Un pegado desde un shell de Windows informa de números equivocados con gran confianza. Anote el dispositivo, la ruta seleccionada y el MTU de cada lado antes de cambiar nada.

Decida si el número debería ser menor

Un MTU de interfaz mayor de lo que la ruta puede transportar no es automáticamente un defecto, porque el descubrimiento del MTU de ruta existe precisamente para eso. El modo de fallo aparece cuando se suprime el descubrimiento: los mensajes ICMP se filtran en algún punto del camino, el emisor nunca aprende el límite y los paquetes grandes desaparecen mientras los pequeños pasan. Eso es una propiedad de la ruta, no una propiedad de Git. También es la razón por la que un archivo pequeño puede tener éxito en una conexión donde uno grande nunca termina.

Si las pruebas lo respaldan, un cambio temporal en la interfaz Linux es la prueba más barata. Elija un valor por debajo del tamaño útil de la ruta, anote el anterior y mantenga todo lo demás constante para que la comparación signifique algo. Si la transferencia termina con el valor menor, tiene un diagnóstico y no una coincidencia.

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

Decida dónde debe vivir el ajuste

De la prueba se derivan tres opciones, y normalmente solo una es adecuada. Si el valor menor corrige la transferencia y el valor es realmente necesario para esta red, el ajuste necesita un propietario del ciclo de vida: un gancho de inicio en la distribución, una configuración de red gestionada por la plataforma o un procedimiento documentado. Si el valor no corrige nada, reviértalo y vuelva a las cuestiones de transporte, proxy y autenticación.

Que exista un gancho de inicio depende de las versiones de Windows y WSL en uso y del modo de red configurado. Reflejar la red de Windows puede cambiar cómo interactúa una VPN con la distribución de maneras que importan más que un ajuste de MTU, así que identifique el modo antes de diseñar una solución alternativa para él. Un valor que sirve para un operador o un perfil de VPN no es un valor predeterminado para el siguiente.

Lo que hay que evitar es la ubicación tentadora: un comando de red privilegiado en el archivo de inicio de cada shell interactivo, o sudo sin contraseña para todo el binario ip para que un script pueda ejecutar una línea. Ambas cosas convierten un diagnóstico en una exposición permanente y hacen que el problema original sea más difícil de ver después.

Verifique tras un inicio limpio y luego revierta

Un cambio que solo sobrevive hasta que se reinicia la distribución no es una solución. Reinicie la distribución, vuelva a conectar la VPN y repita la operación de Git original en lugar de un sustituto como ping o una petición HTTP pequeña. Después confirme que la interfaz lleva el valor previsto en la sesión nueva.

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

Mantenga el valor original anotado junto al cambio para que el experimento pueda deshacerse limpiamente, y anote qué familia de direcciones se probó, ya que un resultado IPv4 no dice nada sobre una conexión IPv6 en el mismo host. La documentación de redes de WSL describe los modos que determinan cómo debe ser una solución; el número de MTU es una medición local, no una recomendación.