Test eit mistenkt MTU-problem i VPN utan å gjette verdiar

Å prøve ei liste med internett-MTU-verdiar til ein kjennest raskare, er ikkje ein test, det er eit søk utan stoppregel. Metoden som verkar, endrar éin kontrollert storleiksvilkår og samanliknar resultatet med same sti. Byrj med ein repeterbar, ufarleg feil og hald den fungerande konfigurasjonen som lèt deg angre eksperimentet. Alt nedanfor føreset den disiplinen, for utan han endar du med eit tal du ikkje kan forsvare.

Fastset stien før du rører eit tal

Skriv ned eininga, tilkoplingslenka, tunnelprotokollen, endepunktet, målet og adressefamilien før du rører ei innstilling. Dei seks fakta er stien, og ein probe mot ein annan sti måler eit anna problem. Dei gjer òg resultatet reproduserbart, og det er det som skil ein test frå ein ettermiddag med pirking. Hald notatet ved terminalen i staden for i hovudet.

Byrj med den smalaste testen du har lov til å køyre. Ei endring på serversida når kvar brukar av det endepunktet, så ho høyrer heime på slutten av undersøkinga, ikkje i byrjinga.

Mål med ein storleik du kontrollerer

På Linux ser proben slik ut: ping -M do -s 1400 host, og på Windows: ping -f -l 1400 host. I båe tilfelle set du nyttelasta og ikkje pakkestorleiken, fordi IP- og ICMP-hovuda blir lagde oppå.

Les dokumentasjonen for systemet framfor deg i staden for å kopiere eit flagg frå eit foruminnlegg. Vel eit mål du kontrollerer, slik at eit manglande svar er eit signal og ikkje ei gåte. Noter den nøyaktige kommandoen og den nøyaktige storleiken i same notat som stien. Eit resultat utan storleik er ein anekdote. Endrar du to ting i éin køyring, veit du ikkje kven av dei som gav resultatet.

Ein mislukka probe er ikkje bevis for ei MTU-grense

Ein droppa probe kan tyde ICMP-filtrering og ikkje ei storleiksgrense, og den feilen får folk til å justere ein verdi som aldri var problemet. Samanlikn proben med den ekte applikasjonen, og med ei storleiksrelatert feilmelding eller eit målretta opptak, før du endrar noko. Vellukka små ping beviser heller ingenting, for dei kan liggje godt under grensa. To uavhengige observasjonar er minimumet før ein konfigurasjon blir flytta.

Viss applikasjonen feilar medan proben lukkast, har du bevis for at dette ikkje er ei enkel storleiksgrense på den stien. Skriv det ned, for det fjernar ei heil grein av moglege endringar.

Juster éin parameter som klienten allereie støttar

Endre innstillinga klienten dokumenterer for denne protokollen, og lat endepunktet og målet vere urørt, elles har du endra to ting samstundes. Ei TCP-MSS-klemme dekkjer ikkje alle UDP-arbeidslaster, og difor kan ein nettlesar som byrjar å verke late tunnelprotokollen vere nøyaktig like øydelagd. IPv4 og IPv6 er separate stiar her, fordi hovuda er ulike før noka ruting gjer noko.

Test båe familiane viss du publiserer båe, for eit resultat frå den eine seier ingenting om den andre. Ein verdi som verka på denne stien i kveld, er eit datapunkt og ikkje ein MTU for heile VPN. Ikkje forfrem han til ei global innstilling på grunnlag av éin vellukka overføring. Skriv verdien ned ved sida av stien han kom frå.

Angre, stadfeste og skrive det ned

Set den opphavlege verdien tilbake viss samanlikninga ikkje støttar hypotesen. Kontroller at ein nettverkshandsamar ikkje har lagra ei varig overstyring ein annan stad, for slik blir eit eksperiment til policy. Kopla til på nytt og prøv vanlege applikasjonar, ikkje berre den du testa. Noter deretter symptomet, den effektive stien, den gamle og den nye verdien og kor repeterbart resultatet var.

Ta vare på den registreringa saman med endringsførespurnaden før nokon utvidar endringa. Den sti-MTU-oppdaging i RFC 1191 forklarer kvifor ein mindre verdi kan redde éin sti og ikkje gjere noko for ein annan, og ei liste med tal er inga erstatning for den modellen. Testen er ferdig når du kan namngje stien, storleiken, observasjonen og verdien du gjenoppretta.