As páxinas cargan pero as subidas atascan na VPN: que causa gaña
Un atasco que depende do tamaño encaixa cun defecto de MTU da ruta, e tamén con DNS, un límite da aplicación ou un túnel inestable. Catro observacións deciden cal.
As páxinas cargan, a VPN di que está conectada e unha subida de ficheiro conxélase sempre no mesmo punto. Catro explicacións encaixan con esa descrición: un problema de tamaño de paquete, un problema de resolución de nomes, un límite da aplicación e un túnel que se reinicia continuamente. Cada unha pódese confirmar ou descartar cunha observación distinta, así que a decisión consiste en escoller a proba correcta en lugar de adiviñar a causa.
Catro candidatos e unha forma
Empeza pola forma do fallo, porque elimina a maior parte da lista antes de abrir calquera ferramenta. Un atasco que ocorre cun tamaño constante é un problema de tamaño ata que se demostre o contrario. Un atasco en puntos aleatorios é un problema de perda ou de estabilidade. Un fallo antes de que se abra a conexión é un problema de nomes.
O cuarto candidato é a aplicación. Os límites de subida, os tempos de espera das solicitudes e os topes de tamaño do corpo do proxy producen fallos que, desde o navegador, parecen fallos de rede, e adoitan chegar como un rexeitamento en lugar dun bloqueo.
Anota a forma observada antes de probar nada. «Détese aproximadamente no mesmo número de bytes, cada vez, co túnel levantado» é un punto de partida moito máis sólido que «as subidas non funcionan».
Despois mantén a ruta fixa mentres probas. Cambiar a saída, o protocolo e o servidor ao mesmo tempo produce un resultado que non podes atribuír a ningún deles. Unha variable por execución, e anótaa.
Divide o tamaño antes de tocar a política
O discriminador máis barato é unha sonda que varía un só número. Envía pings sen fragmentación de tamaño crecente ao destino, sube un ficheiro que controles ao mesmo servizo e compara onde se detén cada un.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadO primeiro comando informa se un paquete de tamaño completo sobrevive á ruta. Cunha MTU de 1500 bytes, a maior carga ICMP que non se fragmenta é de 1472 bytes, e un túnel saca aínda máis dese orzamento antes de que comece o paquete interior. O segundo dache un tamaño e unha duración para unha transferencia a nivel de aplicación, e ese é o número que de verdade importa.
| 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 |
Le o par en conxunto. Sondas que fallan por riba dun limiar e unha subida que se detén preto do mesmo limiar é unha historia coherente. Sondas que teñen éxito todas mentres a subida atasca nun número de bytes que a ruta claramente transporta apuntan á aplicación ou ao servidor, e ningún traballo de MTU o cambiará. Ese resultado negativo vale tanto como un positivo. Elimina a rama máis cara da investigación.
Despois comproba a estabilidade durante a transferencia, porque un túnel que renova a chave no medio dunha subida grande produce un fallo que parece depender do tamaño sen selo. A lectura do tempo de actividade é a forma máis barata de confirmalo.
Decide entre unha reparación e unha solución provisional
Se as probas apuntan ao tamaño, hai dúas respostas honestas e unha deshonesta. As honestas son restaurar o descubrimento de MTU da ruta permitindo a retroalimentación ICMP necesaria, ou fixar o tamaño de segmento anunciado para que os pares envíen segmentos máis pequenos. A deshonesta é baixar a MTU dunha interface a un valor copiado dun foro e non verificar nunca que cambiou.
A escolla depende do que controles. Nunha rede que operas, permitir as mensaxes ICMP é a solución máis limpa porque mantén o mecanismo funcionando para cada protocolo. Nunha ruta que non controlas, fixar o tamaño é a opción práctica, e debe aplicarse de forma estreita e non a todo o servidor.
Se as probas apuntan á aplicación, repara a aplicación ou a súa configuración de proxy. Unha resposta 413 e unha conexión colgada son fallos distintos, e o segundo adoita ser un tempo de espera nalgún punto dunha cadea que inclúe un proxy cos seus propios límites.
De calquera xeito, conserva os valores orixinais e volve probar despois de reverter. Un cambio que coincide cunha transferencia correcta non é proba de que a causase, e a capacidade de desfacelo é o que separa un diagnóstico dunha coincidencia.
Rexistra a decisión para que sobreviva ao próximo incidente
Catro feitos abondan: a forma observada do fallo, os resultados das sondas, o cambio que fixeches e o resultado da repetición da proba. Con eles, a seguinte persoa pode dicir se o problema é o mesmo ou un novo co mesmo síntoma.
Anota tamén o contexto da ruta, porque un achado de MTU é específico dunha ligazón. Un portátil que funciona na casa e falla nun hotel ten dúas rutas, e unha corrección aplicada a unha delas non di nada sobre a outra.
Por último, resiste o resumo de que «a VPN rompeu as subidas». O túnel estaba presente tanto no caso que funcionaba como no que fallaba; o que cambiou foi o tamaño do paquete que a ruta debía transportar, ou onde se detivo a transferencia. Nomear o mecanismo real é o que fai útil a nota.