As páginas carregam mas os uploads travam na VPN: qual causa vence
Um travamento que depende do tamanho encaixa numa falha de MTU do caminho, e também em DNS, num limite da aplicação ou num túnel instável. Quatro observações decidem qual.
As páginas carregam, a VPN indica que está conectada e um upload de arquivo congela sempre no mesmo ponto. Quatro explicações encaixam nessa descrição: um problema de tamanho de pacote, um problema de resolução de nomes, um limite da aplicação e um túnel que se reinicia continuamente. Cada uma pode ser confirmada ou descartada por uma observação diferente, então a decisão é escolher o teste certo em vez de adivinhar a causa.
Quatro candidatos e uma forma
Comece pela forma da falha, porque ela elimina a maior parte da lista antes de qualquer ferramenta ser aberta. Um travamento que ocorre num tamanho constante é um problema de tamanho até que se prove o contrário. Um travamento em pontos aleatórios é um problema de perda ou de estabilidade. Uma falha antes de a conexão abrir é um problema de nomes.
O quarto candidato é a aplicação. Limites de upload, tempos limite das requisições e tetos de tamanho do corpo no proxy produzem falhas que, do navegador, parecem defeitos de rede, e elas costumam chegar como rejeição em vez de travamento.
Anote a forma observada antes de testar qualquer coisa. «Para aproximadamente no mesmo número de bytes, todas as vezes, com o túnel ativo» é um ponto de partida muito mais forte do que «os uploads não funcionam».
Depois mantenha o caminho fixo enquanto testa. Mudar a saída, o protocolo e o servidor ao mesmo tempo produz um resultado que você não consegue atribuir a nenhum deles. Uma variável por execução, e anote-a.
Divida o tamanho antes de tocar na política
O discriminador mais barato é uma sonda que varia um único número. Envie pings sem fragmentação de tamanho crescente ao destino, envie um arquivo que você controla ao mesmo serviço e compare onde cada um para.
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 um pacote de tamanho cheio sobrevive ao caminho. Com uma MTU de 1500 bytes, a maior carga ICMP que não é fragmentada é de 1472 bytes, e um túnel retira ainda mais desse orçamento antes de o pacote interno começar. O segundo dá a você um tamanho e uma duração para uma transferência em nível de aplicação, e esse é o número que realmente 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 |
Leia o par em conjunto. Sondas que falham acima de um limite e um upload que para perto do mesmo limite formam uma história coerente. Sondas que todas passam enquanto o upload trava num número de bytes que o caminho claramente transporta apontam para a aplicação ou o servidor, e nenhum trabalho de MTU mudará isso. Esse resultado negativo vale tanto quanto um positivo. Ele elimina o ramo mais caro da investigação.
Depois verifique a estabilidade durante a transferência, porque um túnel que renova a chave no meio de um upload grande produz uma falha que parece depender do tamanho sem ser. A leitura do tempo de atividade é a forma mais barata de confirmar isso.
Escolha entre um reparo e uma gambiarra
Se as evidências apontam para o tamanho, há duas respostas honestas e uma desonesta. As honestas são restaurar a descoberta de MTU do caminho permitindo o feedback ICMP necessário, ou limitar o tamanho de segmento anunciado para que os pares enviem segmentos menores. A desonesta é baixar a MTU de uma interface para um valor copiado de um fórum e nunca verificar o que ele mudou.
A escolha depende do que você controla. Numa rede que você opera, permitir as mensagens ICMP é a correção mais limpa porque mantém o mecanismo funcionando para cada protocolo. Num caminho que você não controla, a limitação é a opção prática, e ela deve ser aplicada de forma estreita e não em todo o servidor.
Se as evidências apontam para a aplicação, corrija a aplicação ou a configuração do proxy. Uma resposta 413 e uma conexão travada são falhas diferentes, e a segunda costuma ser um tempo limite em algum ponto de uma cadeia que inclui um proxy com limites próprios.
De qualquer forma, guarde os valores originais e teste de novo após reverter. Uma mudança que coincide com uma transferência bem-sucedida não é prova de que a causou, e a capacidade de desfazer é o que separa um diagnóstico de uma coincidência.
Registre a decisão para que ela sobreviva ao próximo incidente
Quatro fatos bastam: a forma observada da falha, os resultados das sondas, a mudança que você fez e o resultado do novo teste. Com eles, a próxima pessoa pode dizer se o problema é o mesmo ou um novo com o mesmo sintoma.
Anote também o contexto do caminho, porque um achado de MTU é específico de um link. Um notebook que funciona em casa e falha num hotel tem dois caminhos, e uma correção aplicada a um deles não diz nada sobre o outro.
Por fim, resista ao resumo de que «a VPN quebrou os uploads». O túnel estava presente tanto no caso que funcionava quanto no que falhava; o que mudou foi o tamanho do pacote que o caminho precisava transportar, ou onde a transferência foi interrompida. Nomear o mecanismo real é o que torna a nota útil.