Test et mistenkt MTU-problem i VPN uten å gjette verdier

Å prøve en liste med internett-MTU-verdier til én føles raskere, er ikke en test, det er et søk uten stoppregel. Metoden som virker, endrer én kontrollert størrelsesbetingelse og sammenligner resultatet med samme sti. Start med en repeterbar, ufarlig feil og behold den fungerende konfigurasjonen som lar deg angre eksperimentet. Alt nedenfor forutsetter den disiplinen, for uten den ender du med et tall du ikke kan forsvare.

Fastsett stien før du rører et tall

Skriv ned enheten, tilkoblingslenken, tunnelprotokollen, endepunktet, målet og adressefamilien før du rører en innstilling. De seks faktaene er stien, og en probe mot en annen sti måler et annet problem. De gjør også resultatet reproduserbart, og det er det som skiller en test fra en ettermiddag med pirking. Hold notatet ved terminalen i stedet for i hodet.

Start med den smaleste testen du har lov til å kjøre. En endring på serversiden når hver bruker av det endepunktet, så den hører hjemme på slutten av undersøkelsen, ikke i begynnelsen.

Mål med en størrelse du kontrollerer

På Linux ser proben slik ut: ping -M do -s 1400 host, og på Windows: ping -f -l 1400 host. I begge tilfeller setter du nyttelasten og ikke pakkestørrelsen, fordi IP- og ICMP-headerne legges oppå.

Les dokumentasjonen for systemet foran deg i stedet for å kopiere et flagg fra et foruminnlegg. Velg et mål du kontrollerer, slik at et manglende svar er et signal og ikke en gåte. Noter den nøyaktige kommandoen og den nøyaktige størrelsen i samme notat som stien. Et resultat uten størrelse er en anekdote. Endrer du to ting i én kjøring, vet du ikke hvilken av dem som ga resultatet.

En mislykket probe er ikke bevis for en MTU-grense

En droppet probe kan bety ICMP-filtrering og ikke en størrelsesgrense, og den feilen får folk til å justere en verdi som aldri var problemet. Sammenlign proben med den ekte applikasjonen, og med en størrelsesrelatert feilmelding eller en målrettet opptak, før du endrer noe. Vellykkede små ping beviser heller ingenting, for de kan ligge godt under grensen. To uavhengige observasjoner er minimumet før en konfigurasjon flyttes.

Hvis applikasjonen feiler mens proben lykkes, har du bevis for at dette ikke er en enkel størrelsesgrense på den stien. Skriv det ned, for det fjerner en hel gren av mulige endringer.

Juster én parameter som klienten allerede støtter

Endre innstillingen klienten dokumenterer for denne protokollen, og la endepunktet og målet være urørt, ellers har du endret to ting samtidig. En TCP-MSS-klemme dekker ikke alle UDP-arbeidslaster, og derfor kan en nettleser som begynner å virke la tunnelprotokollen være nøyaktig like ødelagt. IPv4 og IPv6 er separate stier her, fordi headerne er forskjellige før noen ruting gjør noe.

Test begge familiene hvis du publiserer begge, for et resultat fra den ene sier ingenting om den andre. En verdi som virket på denne stien i kveld, er et datapunkt og ikke en MTU for hele VPN. Ikke forfrem den til en global innstilling på grunnlag av én vellykket overføring. Skriv verdien ned ved siden av stien den kom fra.

Angre, verifiser og skriv det ned

Sett den opprinnelige verdien tilbake hvis sammenligningen ikke støtter hypotesen. Kontroller at en nettverksbehandler ikke har lagret en vedvarende overstyring et annet sted, for slik blir et eksperiment til policy. Koble til på nytt og prøv vanlige applikasjoner, ikke bare den du testet. Noter deretter symptomet, den effektive stien, den gamle og den nye verdien og hvor repeterbart resultatet var.

Ta vare på den registreringen sammen med endringsforespørselen før noen utvider endringen. Den sti-MTU-oppdagelse i RFC 1191 forklarer hvorfor en mindre verdi kan redde én sti og ikke gjøre noe for en annen, og en liste med tall er ingen erstatning for den modellen. Testen er ferdig når du kan navngi stien, størrelsen, observasjonen og verdien du gjenopprettet.