Pagina's laden wel, maar uploads blijven hangen op een VPN: welke oorzaak wint
Een hang die van de grootte afhangt, past bij een MTU-fout in het pad, en ook bij DNS, een applicatielimiet of een instabiele tunnel. Vier observaties beslissen welke.
Pagina's laden, de VPN meldt dat de verbinding er is, en een bestandsupload bevriest elke keer op hetzelfde punt. Vier verklaringen passen bij die beschrijving: een probleem met de pakketgrootte, een probleem met naamresolutie, een limiet van de applicatie en een tunnel die zich steeds opnieuw instelt. Elk daarvan kan met een andere observatie worden bevestigd of uitgesloten, dus de beslissing is de juiste test kiezen in plaats van de oorzaak raden.
Vier kandidaten en één vorm
Begin met de vorm van de fout, want die schrapt het grootste deel van de lijst voordat er ook maar een tool wordt geopend. Een hang bij een constante grootte is een grootteprobleem tot het tegendeel is bewezen. Een hang op willekeurige punten is een verlies- of stabiliteitsprobleem. Een fout voordat de verbinding opent, is een naamprobleem.
De vierde kandidaat is de applicatie. Uploadlimieten, time-outs van verzoeken en limieten voor de lichaamsgrootte bij de proxy veroorzaken fouten die er in de browser uitzien als netwerkstoringen, en ze komen meestal als een afwijzing in plaats van een hang.
Schrijf de waargenomen vorm op voordat je iets test. "Stopt bij ongeveer hetzelfde aantal bytes, elke keer, met de tunnel actief" is een veel sterker uitgangspunt dan "uploads werken niet".
Houd daarna het pad vast tijdens het testen. Het uitgangspunt, het protocol en de server tegelijk wijzigen levert een resultaat op dat je aan geen van die drie kunt toeschrijven. Eén variabele per run, en schrijf die op.
Halveer de grootte voordat je aan beleid komt
De goedkoopste discriminator is een probe die één getal varieert. Stuur do-not-fragment-pings van toenemende grootte naar de bestemming, upload een bestand dat je beheert naar dezelfde dienst, en vergelijk dan waar elk van beide stopt.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadHet eerste commando meldt of een pakket op volle grootte het pad überhaupt overleeft. Bij een MTU van 1500 bytes is de grootste ICMP-payload die niet fragmenteert 1472 bytes, en een tunnel neemt meer uit dat budget voordat het binnenste pakket begint. Het tweede geeft je een grootte en een duur voor een overdracht op applicatieniveau, en dat is het getal dat echt telt.
| 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 |
Lees het paar samen. Probes die boven een drempel falen en een upload die bij dezelfde drempel stopt, vormen een samenhangend verhaal. Probes die allemaal slagen terwijl de upload vastloopt bij een aantal bytes dat het pad duidelijk draagt, wijzen op de applicatie of de server, en geen enkele MTU-wijziging zal dat veranderen. Dat negatieve resultaat is net zoveel waard als een positief. Het verwijdert de duurste tak van het onderzoek.
Controleer daarna de stabiliteit tijdens de overdracht, want een tunnel die midden in een grote upload de sleutel vernieuwt, veroorzaakt een fout die grootteafhankelijk lijkt zonder het te zijn. De uptime-waarde is de goedkoopste manier om dat te bevestigen.
Kies tussen een reparatie en een omweg
Als het bewijs op grootte wijst, zijn er twee eerlijke antwoorden en één oneerlijk. De eerlijke zijn de MTU-detectie van het pad herstellen door de nodige ICMP-feedback toe te staan, of de aangekondigde segmentgrootte beperken zodat peers kleinere segmenten sturen. Het oneerlijke is een interface-MTU verlagen naar een waarde die van een forum is gekopieerd en nooit controleren wat die veranderde.
De keuze hangt ervan af wat je beheert. Op een netwerk dat je beheert, is het toestaan van de ICMP-berichten de schonere oplossing, omdat het mechanisme voor elk protocol blijft werken. Op een pad dat je niet beheert, is beperking de praktische optie, en die moet smal worden toegepast en niet op de hele server.
Als het bewijs op de applicatie wijst, repareer dan de applicatie of de proxyconfiguratie. Een 413-respons en een hangende verbinding zijn verschillende fouten, en de tweede is meestal een time-out ergens in een keten met een proxy die eigen limieten heeft.
Hoe dan ook, bewaar de oorspronkelijke waarden en test opnieuw na het terugdraaien. Een wijziging die samengaat met een geslaagde overdracht is geen bewijs dat die de oorzaak was, en de mogelijkheid om terug te draaien is wat een diagnose van een toeval scheidt.
Leg de beslissing vast zodat die het volgende incident overleeft
Vier feiten zijn genoeg: de waargenomen foutvorm, de resultaten van de probes, de wijziging die je hebt doorgevoerd en het resultaat van de hertest. Daarmee kan de volgende persoon zien of het probleem hetzelfde is of een nieuw probleem met hetzelfde symptoom.
Noteer ook de context van het pad, want een MTU-bevinding geldt voor een specifieke verbinding. Een laptop die thuis werkt en in een hotel faalt, heeft twee paden, en een correctie op het ene zegt niets over het andere.
Weersta ten slotte de samenvatting dat "de VPN de uploads heeft gebroken". De tunnel was aanwezig in zowel het werkende als het falende geval; wat veranderde, was de grootte van het pakket dat het pad moest dragen, of de plek waar de overdracht werd gestopt. Het benoemen van het werkelijke mechanisme is wat de notitie nuttig maakt.