Sidor laddas men uppladdningar fastnar på ett VPN: vilken orsak vinner
Ett stopp som beror på storleken passar ihop med ett MTU-fel i vägen, och också med DNS, en appgräns eller en instabil tunnel. Fyra observationer avgör vilken.
Sidor laddas, VPN:t rapporterar anslutning, och en filuppladdning fryser varje gång på samma punkt. Fyra förklaringar passar den beskrivningen: ett paketstorleksproblem, ett namnmatchningproblem, en gräns i appen och en tunnel som ständigt återställs. Var och en kan bekräftas eller uteslutas med en annan observation, så beslutet handlar om att välja rätt test i stället för att gissa orsaken.
Fyra kandidater och en form
Börja med felets form, eftersom den tar bort större delen av listan innan något verktyg öppnas. Ett stopp som inträffar vid en konstant storlek är ett storleksproblem tills motsatsen bevisats. Ett stopp på slumpmässiga punkter är ett förlust- eller stabilitetsproblem. Ett fel innan anslutningen öppnas är ett namnproblem.
Den fjärde kandidaten är appen. Uppladdningsgränser, tidsgränser för förfrågningar och tak för kroppsstorlek i proxyn ger fel som från webbläsaren ser ut som nätverksfel, och de kommer vanligtvis som en avvisning i stället för en hängning.
Skriv ner den observerade formen innan du testar något. "Stannar vid ungefär samma antal byte, varje gång, med tunneln uppe" är en mycket starkare utgångspunkt än "uppladdningar fungerar inte".
Håll sedan vägen oförändrad medan du testar. Att ändra utgång, protokoll och server samtidigt ger ett resultat som du inte kan tillskriva någon av dem. En variabel per körning, och skriv ner den.
Halvera storleken innan du rör vid policyn
Den billigaste urskiljaren är en sond som varierar ett enda tal. Skicka do-not-fragment-pingar med ökande storlek till målet, ladda upp en fil du kontrollerar till samma tjänst och jämför sedan var respektive stoppar.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadDet första kommandot rapporterar om ett paket i full storlek över huvud taget överlever vägen. Vid en MTU på 1500 byte är den största ICMP-nyttolast som inte fragmenteras 1472 byte, och en tunnel tar mer av den budgeten innan det inre paketet börjar. Det andra ger dig en storlek och en varaktighet för en överföring på appnivå, och det är talet som verkligen spelar roll.
| 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 |
Läs paret tillsammans. Sonder som misslyckas över en tröskel och en uppladdning som stannar nära samma tröskel är en sammanhängande historia. Sonder som alla lyckas medan uppladdningen fastnar vid ett byteantal som vägen tydligt bär, pekar på appen eller servern, och inget MTU-arbete kommer att ändra det. Det negativa resultatet är lika mycket värt som ett positivt. Det tar bort den dyraste grenen av utredningen.
Kontrollera sedan stabiliteten under överföringen, eftersom en tunnel som förnyar nyckeln mitt i en stor uppladdning ger ett fel som ser storleksberoende ut utan att vara det. Avläsningen av drifttiden är det billigaste sättet att bekräfta det.
Välj mellan en reparation och en kringgående lösning
Om bevisen pekar på storlek finns det två ärliga svar och ett oärligt. De ärliga är att återställa MTU-upptäckten genom att tillåta den nödvändiga ICMP-återkopplingen, eller att begränsa den annonserade segmentstorleken så att parterna skickar mindre segment. Det oärliga är att sänka en gränssnitts-MTU till ett värde kopierat från ett forum och aldrig kontrollera vad det ändrade.
Valet beror på vad du kontrollerar. I ett nätverk du driver är det den renare lösningen att tillåta ICMP-meddelandena, eftersom det håller mekanismen igång för varje protokoll. På en väg du inte kontrollerar är begränsning det praktiska alternativet, och det bör tillämpas snävt och inte på hela servern.
Om bevisen pekar på appen, reparera appen eller dess proxykonfiguration. Ett 413-svar och en hängande anslutning är olika fel, och det andra är vanligtvis en tidsgräns någonstans i en kedja som innehåller en proxy med egna gränser.
Hur som helst, behåll de ursprungliga värdena och testa igen efter återställning. En ändring som sammanfaller med en fungerande överföring är inte bevis för att den orsakade den, och förmågan att ångra är det som skiljer en diagnos från ett sammanträffande.
Skriv ner beslutet så att det överlever nästa incident
Fyra fakta räcker: den observerade felformen, sondernas resultat, den ändring du gjorde och resultatet av omtestet. Med dem kan nästa person avgöra om problemet är detsamma eller ett nytt med samma symptom.
Notera också vägens sammanhang, eftersom ett MTU-fynd är specifikt för en länk. En bärbar dator som fungerar hemma och misslyckas på ett hotell har två vägar, och en rättelse som tillämpas på den ena säger ingenting om den andra.
Till sist, stå emot sammanfattningen att "VPN:t förstörde uppladdningarna". Tunneln fanns både i det fungerande och det misslyckade fallet; det som ändrades var storleken på det paket som vägen måste bära, eller var överföringen stoppades. Det är namngivningen av den faktiska mekanismen som gör anteckningen användbar.