Sider lastar, men opplastingar stoppar på ein VPN: kva årsak vinn
Ein stopp som avheng av storleiken, passar med ein MTU-feil i ruta, og passar òg med DNS, ei appgrense eller ein ustabil tunnel. Fire observasjonar avgjer kva.
Sider lastar, VPN-en melder at han er tilkopla, og ei filopplasting frys på same punkt kvar gong. Fire forklaringar passar med den skildringa: eit pakkestorleiksproblem, eit namneoppløysingsproblem, ei grense i appen og ein tunnel som stadig nullstiller seg. Kvar av dei kan stadfestast eller utelukkast med ein annan observasjon, så avgjerda handlar om å velje rett test i staden for å gjette årsaka.
Fire kandidatar og éin form
Byrja med forma på feilen, fordi ho fjernar mesteparten av lista før noko verktøy blir opna. Eit stopp som skjer ved ein fast storleik, er eit storleiksproblem til det motsette er bevist. Eit stopp på tilfeldige punkt er eit tap- eller stabilitetsproblem. Ein feil før sambandet opnar, er eit namneproblem.
Den fjerde kandidaten er appen. Opplastingsgrenser, tidsavbrot for førespurnader og grenser for kroppsstorleik i proxyen gjev feil som frå nettlesaren ser ut som nettverksfeil, og dei kjem vanlegvis som ei avvising i staden for ei henging.
Skriv ned den observerte forma før du testar noko. "Stoppar på omtrent same byteantal, kvar gong, med tunnelen oppe" er eit mykje sterkare utgangspunkt enn "opplastingar verkar ikkje".
Hald deretter ruta fast medan du testar. Å endre utgang, protokoll og server samstundes gjev eit resultat du ikkje kan tilskrive nokon av dei. Éin variabel per køyring, og skriv han ned.
Hald storleiken i to før du rører ved policyen
Den billegaste diskriminatoren er ein probe som varierer eitt tal. Send do-not-fragment-pingar med aukande storleik til målet, og last opp ei fil du kontrollerer til same tenesta, og samanlikn deretter kvar av dei 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/uploadDen første kommandoen rapporterer om ein pakke i full storleik i det heile overlever ruta. Ved ein MTU på 1500 byte er den største ICMP-nyttelasta som ikkje fragmenterer, 1472 byte, og ein tunnel tek meir av dette budsjettet før den indre pakken byrjar. Den andre gjev deg ein storleik og ein varigheit for ei overføring på appnivå, og det er talet som faktisk tel.
| 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 |
Les paret saman. Probar som feilar over ein terskel, og ei opplasting som stoppar nær same terskel, er ei samanhengande historie. Probar som alle lukkast medan opplastinga stoppar ved eit byteantal som ruta tydeleg ber, peikar på appen eller serveren, og inga mengd MTU-arbeid vil endre det. Det negative resultatet er like mykje verdt som eit positivt. Det fjernar den dyraste greina av undersøkinga.
Sjekk deretter stabiliteten under overføringa, fordi ein tunnel som fornyar nøkkelen midt i ei stor opplasting, gjev ein feil som ser storleiksavhengig ut utan å vere det. Oppetidsavlesinga er den billegaste måten å stadfeste det på.
Vel mellom ein reparasjon og ein omveg
Viss bevisa peikar på storleik, finst det to ærlege svar og eitt uærleg. Dei ærlege er å gjenopprette MTU-oppdaginga ved å tillate den nødvendige ICMP-tilbakemeldinga, eller å avgrense den annonserte segmentstorleiken slik at partane sender mindre segment. Det uærlege er å senke ein grensesnitt-MTU til ein verdi kopiert frå eit forum og aldri kontrollere kva han endra.
Valet avheng av kva du kontrollerer. På eit nettverk du driv, er det den reinare løysinga å tillate ICMP-meldingane, fordi det held mekanismen i gang for kvar protokoll. På ei rute du ikkje kontrollerer, er avgrensing det praktiske alternativet, og det bør brukast smalt og ikkje på heile serveren.
Viss bevisa peikar på appen, reparer appen eller proxykonfigurasjonen. Eit 413-svar og ei hengande tilkopling er ulike feil, og den andre er vanlegvis ein tidsavbrot ein stad i ei kjede som inkluderer ein proxy med eigne grenser.
Uansett, hald på dei opphavlege verdiane og test på nytt etter tilbakerulling. Ei endring som fell saman med ei fungerande overføring, er ikkje bevis for at ho forårsaka ho, og evna til å angre er det som skil ein diagnose frå eit tilfelle.
Skriv ned avgjerda slik at ho overlever neste hending
Fire fakta er nok: den observerte feilforma, resultata av probane, endringa du gjorde og resultatet av nyttesten. Med dei kan neste person seie om problemet er det same eller eit nytt med same symptom.
Noter òg rutekonteksten, fordi eit MTU-funn er spesifikt for ei lenke. Ein berbar PC som verkar heime og feilar på eit hotell, har to ruter, og ei retting brukt på den eine seier ingenting om den andre.
Til slutt, motstå oppsummeringa om at "VPN-en øydela opplastingane". Tunnelen var til stades både i det fungerande og det feilande tilfellet; det som endra seg, var storleiken på pakken ruta måtte bere, eller kvar overføringa vart stansa. Det er namngjevinga av den faktiske mekanismen som gjer notatet nyttig.