Git si blocca in WSL2 dietro una VPN: MTU dell’interfaccia o del percorso?

Il clone si autentica, compare il conteggio degli oggetti e poi nulla si muove per minuti. Windows segnala la VPN come connessa, il nome host si risolve e un browser sulla stessa macchina recupera la stessa pagina del repository senza difficoltà. Questa combinazione punta alla dimensione dei pacchetti più che alle credenziali, e la questione della dimensione va posta in due punti perché WSL2 ha la propria interfaccia Linux con il proprio MTU. Un numero appartiene al lato Windows del percorso, l’altro alla distribuzione, e leggere solo l’adattatore VPN lascia metà del percorso non esaminata.

Tre segnali separano un problema di dimensione da altro

Il primo segnale è la forma: l’instaurazione della connessione e un piccolo scambio riescono, poi il trasferimento massivo smette di progredire. Il secondo è la simmetria: lo stesso repository e lo stesso trasporto falliscono mentre un altro host sullo stesso percorso funziona, oppure il guasto cambia con la dimensione del carico utile e non con l’ora del giorno. Il terzo è il silenzio: nessun errore di autenticazione, nessun rifiuto del proxy, nessun fallimento di risoluzione dei nomi, solo un trasferimento che non si completa mai.

Questi tre insieme giustificano un’ipotesi di dimensione del pacchetto. Un guasto DNS, un token scaduto, una chiave SSH rifiutata e un proxy che rifiuta CONNECT producono ciascuno il proprio errore, e nessuno sembra uno stallo dopo un successo. Mantenere lo stesso repository, lo stesso trasporto e la stessa finestra temporale durante il test è ciò che rende onesto il confronto.

Confrontate entrambe le interfacce prima di decidere

Raccogliete la vista di Windows e la vista di Linux nella stessa sessione, e tenete l’indirizzo del repository invece di indovinare quale interfaccia lo trasporta. Il comando seguente risolve prima la destinazione, così la ricerca del percorso descrive il server reale che il clone contatta, che può differire dal nome mostrato da un browser. Eseguite le due metà a breve distanza, perché la VPN può cambiare le metriche dell’interfaccia tra un tentativo e l’altro.

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"'

Eseguite la metà Linux all’interno della distribuzione invece di incollare l’output in una shell di Windows, dato che i nomi delle interfacce e la scelta del percorso hanno senso solo lì. Un incolla da una shell di Windows riporta i numeri sbagliati con grande sicurezza. Annotate il dispositivo, il percorso selezionato e l’MTU di ciascun lato prima di cambiare qualsiasi cosa.

Decidete se il numero debba essere più piccolo

Un MTU dell’interfaccia maggiore di quanto il percorso possa trasportare non è automaticamente un difetto, perché la scoperta dell’MTU del percorso esiste proprio per questo. La modalità di guasto compare quando la scoperta viene soppressa: i messaggi ICMP vengono filtrati da qualche parte lungo il percorso, il mittente non apprende mai il limite e i pacchetti grandi svaniscono mentre i piccoli passano. È una proprietà del percorso, non una proprietà di Git. È anche il motivo per cui un file piccolo può riuscire su una connessione dove uno grande non termina mai.

Se le prove lo sostengono, una modifica temporanea sull’interfaccia Linux è il test più economico. Scegliete un valore inferiore alla dimensione utile del percorso, annotate il precedente e tenete tutto il resto costante perché il confronto significhi qualcosa. Se il trasferimento si completa con il valore più piccolo, avete una diagnosi e non una coincidenza.

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

Decidete dove deve vivere l’impostazione

Dal test derivano tre opzioni, e di solito solo una è appropriata. Se il valore più piccolo corregge il trasferimento e il valore è davvero necessario per questa rete, l’impostazione ha bisogno di un proprietario del ciclo di vita: un gancio di avvio nella distribuzione, una configurazione di rete gestita dalla piattaforma o una procedura documentata. Se il valore non corregge nulla, ripristinatelo e tornate alle questioni di trasporto, proxy e autenticazione.

L’esistenza di un gancio di avvio dipende dalle versioni di Windows e WSL in uso e dalla modalità di rete configurata. Rispecchiare la rete di Windows può cambiare il modo in cui una VPN interagisce con la distribuzione, in modi che contano più di un aggiustamento dell’MTU, quindi identificate la modalità prima di progettare una soluzione alternativa per essa. Un valore adatto a un operatore o a un profilo VPN non è un valore predefinito per il successivo.

Ciò che va evitato è la collocazione tentante: un comando di rete privilegiato nel file di avvio di ogni shell interattiva, o sudo senza password per l’intero binario ip affinché uno script possa eseguire una riga. Entrambi trasformano una diagnosi in esposizione permanente e rendono più difficile vedere in seguito il problema originale.

Verificate dopo un avvio pulito, poi annullate

Una modifica che sopravvive solo fino al riavvio della distribuzione non è una correzione. Riavviate la distribuzione, riconnettete la VPN e ripetete l’operazione Git originale invece di un sostituto come ping o una piccola richiesta HTTP. Poi confermate che l’interfaccia porti il valore previsto nella nuova sessione.

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

Tenete il valore originale annotato accanto alla modifica perché l’esperimento possa essere annullato in modo pulito, e annotate quale famiglia di indirizzi è stata testata, dato che un risultato IPv4 non dice nulla su una connessione IPv6 sullo stesso host. La documentazione di rete di WSL descrive le modalità che determinano che aspetto deve avere una correzione; il numero di MTU è di per sé una misura locale, non una raccomandazione.