Sider lastes, men opplastinger stopper på en VPN: hvilken årsak vinner
En stopp som avhenger av størrelsen, passer med en MTU-feil i ruten, og passer også med DNS, en appgrense eller en ustabil tunnel. Fire observasjoner avgjør hvilken.
Sider lastes, VPN-en melder at den er tilkoblet, og en filopplasting fryser på samme punkt hver gang. Fire forklaringer passer med den beskrivelsen: et pakkestørrelsesproblem, et navneoppløsningsproblem, en grense i appen og en tunnel som stadig nullstilles. Hver av dem kan bekreftes eller utelukkes med en annen observasjon, så beslutningen handler om å velge riktig test i stedet for å gjette årsaken.
Fire kandidater og én form
Begynn med feilens form, fordi den fjerner mesteparten av listen før noe verktøy åpnes. En stopp som skjer ved en fast størrelse, er et størrelsesproblem til det motsatte er bevist. En stopp på tilfeldige punkter er et tap- eller stabilitetsproblem. En feil før forbindelsen åpnes, er et navneproblem.
Den fjerde kandidaten er appen. Opplastingsgrenser, tidsavbrudd for forespørsler og grenser for kroppsstørrelse i proxyen gir feil som fra nettleseren ser ut som nettverksfeil, og de kommer vanligvis som en avvisning i stedet for en henging.
Skriv ned den observerte formen før du tester noe. "Stopper på omtrent samme byteantall, hver gang, med tunnelen oppe" er et mye sterkere utgangspunkt enn "opplastinger virker ikke".
Hold deretter ruten fast mens du tester. Å endre utgang, protokoll og server samtidig gir et resultat du ikke kan tilskrive noen av dem. Én variabel per kjøring, og skriv den ned.
Halver størrelsen før du rører ved policyen
Den billigste diskriminatoren er en probe som varierer ett tall. Send do-not-fragment-pinger med økende størrelse til målet, og last opp en fil du kontrollerer til samme tjeneste, og sammenlign deretter hvor hver av 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 kommandoen rapporterer om en pakke i full størrelse i det hele tatt overlever ruten. Ved en MTU på 1500 byte er den største ICMP-nyttelasten som ikke fragmenteres, 1472 byte, og en tunnel tar mer av dette budsjettet før den indre pakken begynner. Den andre gir deg en størrelse og en varighet for en overføring på appnivå, og det er tallet som faktisk betyr noe.
| 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 sammen. Prober som feiler over en terskel, og en opplasting som stopper nær samme terskel, er en sammenhengende historie. Prober som alle lykkes mens opplastingen stopper ved et byteantall som ruten tydelig bærer, peker på appen eller serveren, og ingen mengde MTU-arbeid vil endre det. Det negative resultatet er like mye verdt som et positivt. Det fjerner den dyreste grenen av undersøkelsen.
Sjekk deretter stabiliteten under overføringen, fordi en tunnel som fornyer nøkkelen midt i en stor opplasting, gir en feil som ser størrelsesavhengig ut uten å være det. Oppetidsavlesningen er den billigste måten å bekrefte det på.
Velg mellom en reparasjon og en omvei
Hvis bevisene peker på størrelse, finnes det to ærlige svar og ett uærlig. De ærlige er å gjenopprette MTU-oppdagelsen ved å tillate den nødvendige ICMP-tilbakemeldingen, eller å begrense den annonserte segmentstørrelsen slik at partene sender mindre segmenter. Det uærlige er å senke en grensesnitt-MTU til en verdi kopiert fra et forum og aldri kontrollere hva den endret.
Valget avhenger av hva du kontrollerer. På et nettverk du driver, er det den renere løsningen å tillate ICMP-meldingene, fordi det holder mekanismen i gang for hver protokoll. På en rute du ikke kontrollerer, er begrensning det praktiske alternativet, og det bør brukes snevert og ikke på hele serveren.
Hvis bevisene peker på appen, reparer appen eller proxykonfigurasjonen. Et 413-svar og en hengende forbindelse er forskjellige feil, og den andre er vanligvis en tidsavbrudd et sted i en kjede som inkluderer en proxy med egne grenser.
Uansett, behold de opprinnelige verdiene og test på nytt etter tilbakerulling. En endring som sammenfaller med en fungerende overføring, er ikke bevis for at den forårsaket den, og evnen til å angre er det som skiller en diagnose fra en tilfeldighet.
Skriv ned beslutningen slik at den overlever neste hendelse
Fire fakta er nok: den observerte feilformen, probenes resultater, endringen du gjorde og resultatet av nyttesten. Med dem kan neste person si om problemet er det samme eller et nytt med samme symptom.
Noter også rutekonteksten, fordi et MTU-funn er spesifikt for en lenke. En bærbar PC som virker hjemme og feiler på et hotell, har to ruter, og en rettelse brukt på den ene sier ingenting om den andre.
Til slutt, motstå oppsummeringen om at "VPN-en ødela opplastingene". Tunnelen var til stede både i det fungerende og det feilende tilfellet; det som endret seg, var størrelsen på pakken ruten måtte bære, eller hvor overføringen ble stoppet. Det er navngivningen av den faktiske mekanismen som gjør notatet nyttig.