Sider indlæses, men uploads går i stå på en VPN: hvilken årsag vinder
Et stop, der afhænger af størrelsen, passer på en MTU-fejl i ruten og passer også på DNS, en grænse i programmet eller en ustabil tunnel. Fire observationer afgør hvilken.
Sider indlæses, VPN'en melder forbindelse, og en filupload fryser hver gang på samme punkt. Fire forklaringer passer på den beskrivelse: et pakkestørrelsesproblem, et navneopløsningsproblem, en grænse i programmet og en tunnel, der bliver ved med at nulstille. Hver af dem kan bekræftes eller udelukkes med en forskellig observation, så beslutningen handler om at vælge den rigtige test i stedet for at gætte årsagen.
Fire kandidater og én form
Begynd med fejlens form, fordi den fjerner det meste af listen, før noget værktøj åbnes. Et stop, der sker ved en fast størrelse, er et størrelsesproblem, indtil det modsatte er bevist. Et stop på tilfældige punkter er et tab- eller stabilitetsproblem. En fejl, før forbindelsen åbnes, er et navneproblem.
Den fjerde kandidat er programmet. Uploadgrænser, anmodningstimeouts og proxyens grænser for body-størrelse giver fejl, der fra browseren ligner netværksfejl, og de kommer normalt som en afvisning snarere end et hæng.
Skriv den observerede form ned, før du tester noget. "Stopper ved omtrent samme byteantal, hver gang, med tunnelen oppe" er et langt stærkere udgangspunkt end "uploads virker ikke".
Hold så ruten fast, mens du tester. At ændre udgang, protokol og server på samme tid giver et resultat, du ikke kan tilskrive nogen af dem. Én variabel pr. kørsel, og skriv den ned.
Halvér størrelsen, før du rører ved politikken
Den billigste diskriminator er en probe, der varierer ét tal. Send do-not-fragment-pings med stigende størrelse til destinationen, og upload en fil, du kontrollerer, til samme tjeneste, og sammenlign derefter, hvor hver af dem stopper.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadDen første kommando rapporterer, om en pakke i fuld størrelse overhovedet overlever ruten. Ved en MTU på 1500 bytes er den største ICMP-payload, der ikke fragmenteres, 1472 bytes, og en tunnel tager mere af det budget, før den indre pakke begynder. Den anden giver dig en størrelse og en varighed for en overførsel på programniveau, og det er det tal, der faktisk betyder noget.
| 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 parret sammen. Prober, der fejler over en tærskel, og en upload, der stopper nær samme tærskel, er en sammenhængende historie. Prober, der alle lykkes, mens uploaden går i stå ved et byteantal, som ruten tydeligt bærer, peger på programmet eller serveren, og ingen mængde MTU-arbejde vil ændre det. Det negative resultat er lige så meget værd som et positivt. Det fjerner den dyreste gren af undersøgelsen.
Kontroller derefter stabiliteten under overførslen, fordi en tunnel, der fornyer nøglen midt i en stor upload, giver en fejl, der ser størrelsesafhængig ud, uden at være det. Oppetidstallet er den billigste måde at bekræfte det på.
Vælg mellem en reparation og en workaround
Hvis beviserne peger på størrelse, er der to ærlige svar og ét uærligt. De ærlige er at genoprette MTU-opdagelsen ved at tillade den nødvendige ICMP-feedback eller at fastlåse den annoncerede segmentstørrelse, så parterne sender mindre segmenter. Det uærlige er at sænke en interface-MTU til en værdi kopieret fra et forum og aldrig kontrollere, hvad den ændrede.
Valget afhænger af, hvad du kontrollerer. På et netværk, du driver, er det den renere løsning at tillade ICMP-beskederne, fordi det holder mekanismen kørende for hver protokol. På en rute, du ikke kontrollerer, er fastlåsning den praktiske mulighed, og den bør anvendes snævert og ikke på hele serveren.
Hvis beviserne peger på programmet, skal du rette programmet eller dets proxykonfiguration. Et 413-svar og en hængende forbindelse er forskellige fejl, og den anden er normalt en timeout et sted i en kæde, der indeholder en proxy med sine egne grænser.
Under alle omstændigheder skal du beholde de oprindelige værdier og teste igen efter tilbagerulning. En ændring, der falder sammen med en fungerende overførsel, er ikke bevis for, at den forårsagede den, og evnen til at fortryde er det, der adskiller en diagnose fra en tilfældighed.
Skriv beslutningen ned, så den overlever den næste hændelse
Fire fakta er nok: den observerede fejlform, probens resultater, den ændring, du lavede, og resultatet af gentest. Med dem kan den næste person se, om problemet er det samme, eller et nyt med samme symptom.
Noter også rutekonteksten, fordi en MTU-konklusion er specifik for et link. En bærbar, der virker derhjemme og fejler på et hotel, har to ruter, og en rettelse anvendt på den ene siger intet om den anden.
Til sidst: modstå opsummeringen om, at "VPN'en ødelagde uploads". Tunnelen var til stede i både det fungerende og det fejlende tilfælde; det, der ændrede sig, var størrelsen på den pakke, ruten skulle bære, eller hvor overførslen blev stoppet. Det er navngivningen af den faktiske mekanisme, der gør noten nyttig.