Le pagine si caricano ma i caricamenti si bloccano su una VPN: quale causa vince
Un blocco che dipende dalla dimensione si adatta a un guasto MTU del percorso, ma anche a DNS, a un limite dell'applicazione o a un tunnel instabile. Quattro osservazioni decidono quale.
Le pagine si caricano, la VPN segnala la connessione e un caricamento di file si blocca sempre nello stesso punto. Quattro spiegazioni corrispondono a questa descrizione: un problema di dimensione del pacchetto, un problema di risoluzione dei nomi, un limite dell'applicazione e un tunnel che si reimposta di continuo. Ognuna può essere confermata o esclusa con un'osservazione diversa, quindi la decisione consiste nello scegliere il test giusto invece di indovinare la causa.
Quattro candidati e una forma
Inizia dalla forma del guasto, perché elimina la maggior parte dell'elenco prima ancora di aprire uno strumento. Un blocco che si verifica a una dimensione costante è un problema di dimensione finché non si dimostra il contrario. Un blocco in punti casuali è un problema di perdita o di stabilità. Un guasto prima che la connessione si apra è un problema di nomi.
Il quarto candidato è l'applicazione. I limiti di caricamento, i timeout delle richieste e i tetti di dimensione del corpo del proxy producono guasti che, dal browser, sembrano difetti di rete, e di solito arrivano come rifiuto anziché come blocco.
Annota la forma osservata prima di testare qualsiasi cosa. «Si ferma all'incirca allo stesso numero di byte, ogni volta, con il tunnel attivo» è un punto di partenza molto più solido di «i caricamenti non funzionano».
Poi mantieni fisso il percorso durante i test. Cambiare l'uscita, il protocollo e il server contemporaneamente produce un risultato che non puoi attribuire a nessuno di essi. Una variabile per esecuzione, e annotala.
Dimezza la dimensione prima di toccare la politica
Il discriminante più economico è una sonda che varia un solo numero. Invia ping senza frammentazione di dimensione crescente verso la destinazione, carica un file che controlli sullo stesso servizio, poi confronta dove si ferma ciascuno.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadIl primo comando indica se un pacchetto a dimensione piena supera il percorso. Con una MTU di 1500 byte, il carico utile ICMP più grande che non viene frammentato è di 1472 byte, e un tunnel preleva ancora di più da quel budget prima che inizi il pacchetto interno. Il secondo ti dà una dimensione e una durata per un trasferimento a livello applicativo, ed è il numero che conta davvero.
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
Leggi la coppia insieme. Sonde che falliscono sopra una soglia e un caricamento che si ferma vicino alla stessa soglia formano una storia coerente. Sonde che riescono tutte mentre il caricamento si blocca a un numero di byte che il percorso trasporta chiaramente indicano l'applicazione o il server, e nessun lavoro sulla MTU lo cambierà. Quel risultato negativo vale quanto uno positivo. Elimina il ramo più costoso dell'indagine.
Poi verifica la stabilità durante il trasferimento, perché un tunnel che rinnova la chiave a metà di un caricamento grande produce un guasto che sembra dipendere dalla dimensione senza esserlo. La lettura del tempo di attività è il modo più economico per confermarlo.
Scegli tra una riparazione e un aggiramento
Se le prove indicano la dimensione, ci sono due risposte oneste e una disonesta. Quelle oneste sono ripristinare la scoperta della MTU del percorso consentendo il feedback ICMP necessario, oppure limitare la dimensione del segmento annunciata perché i pari inviino segmenti più piccoli. Quella disonesta è abbassare la MTU di un'interfaccia a un valore copiato da un forum senza mai verificare cosa ha cambiato.
La scelta dipende da ciò che controlli. Su una rete che gestisci, consentire i messaggi ICMP è la correzione più pulita perché mantiene il meccanismo funzionante per ogni protocollo. Su un percorso che non controlli, la limitazione è l'opzione pratica, e va applicata in modo ristretto e non a tutto il server.
Se le prove indicano l'applicazione, correggi l'applicazione o la sua configurazione del proxy. Una risposta 413 e una connessione bloccata sono guasti diversi, e il secondo è di solito un timeout da qualche parte in una catena che include un proxy con i propri limiti.
In ogni caso, conserva i valori originali e ripeti il test dopo aver annullato. Un cambiamento che coincide con un trasferimento riuscito non è prova che l'abbia causato, e la capacità di annullarlo è ciò che separa una diagnosi da una coincidenza.
Registra la decisione perché sopravviva al prossimo incidente
Quattro fatti bastano: la forma osservata del guasto, i risultati delle sonde, il cambiamento effettuato e il risultato del nuovo test. Con questi, la persona successiva può dire se il problema è lo stesso o uno nuovo con lo stesso sintomo.
Annota anche il contesto del percorso, perché un riscontro sulla MTU è specifico di un collegamento. Un portatile che funziona a casa e fallisce in albergo ha due percorsi, e una correzione applicata a uno di essi non dice nulla sull'altro.
Infine, resisti al riassunto secondo cui «la VPN ha rotto i caricamenti». Il tunnel era presente sia nel caso funzionante sia in quello fallito; ciò che è cambiato era la dimensione del pacchetto che il percorso doveva trasportare, o il punto in cui il trasferimento è stato fermato. Nominare il meccanismo reale è ciò che rende utile la nota.