Test en formodet MTU-problem i VPN uden at gætte værdier

At prøve en liste af internet-MTU-værdier, indtil en føles hurtigere, er ikke en test, det er en søgning uden stopregel. Metoden der virker, ændrer én kontrolleret størrelsesbetingelse og sammenligner resultatet med samme sti. Begynd med en gentagelig, uskadelig fejl og behold den fungerende konfiguration, der lader dig rulle eksperimentet tilbage. Alt nedenfor forudsætter den disciplin, for uden den ender du med et tal, du ikke kan forsvare.

Fastlæg stien, før du rører ved et tal

Skriv enheden, adgangsforbindelsen, tunnelprotokollen, endepunktet, destinationen og adressefamilien ned, før du rører ved en indstilling. De seks fakta er stien, og en probe mod en anden sti måler et andet problem. De gør også resultatet reproducerbart, og det er det, der skiller en test fra en eftermiddag med famlen. Hold noten ved terminalen i stedet for i hovedet.

Begynd med den snævreste test, du har tilladelse til at køre. En ændring på serversiden rammer alle brugere af det endepunkt, så den hører til sidst i undersøgelsen, ikke først.

Mål med en størrelse, du styrer

På Linux ser proben sådan ud: ping -M do -s 1400 host, og på Windows: ping -f -l 1400 host. I begge tilfælde sætter du nyttelasten og ikke pakkestørrelsen, fordi IP- og ICMP-headerne lægges ovenpå.

Læs dokumentationen for det system, der står foran dig, i stedet for at kopiere et flag fra et forumindlæg. Vælg en destination, du selv styrer, så et manglende svar er et signal og ikke en gåde. Noter den præcise kommando og den præcise størrelse i samme note som stien. Et resultat uden størrelse er en anekdote. Ændrer du to ting i én kørsel, ved du ikke, hvilken af dem der gav resultatet.

En mislykket probe er ikke bevis for en MTU-grænse

En droppet probe kan betyde ICMP-filtrering og ikke en størrelsesgrænse, og den fejl får folk til at justere en værdi, der aldrig var problemet. Sammenlign proben med den rigtige applikation og med en størrelsesrelateret fejlmeddelelse eller en målrettet optagelse, før du ændrer noget. Vellykkede små ping beviser heller intet, for de kan ligge godt under grænsen. To uafhængige observationer er minimummet, før en konfiguration flyttes.

Hvis applikationen fejler, mens proben lykkes, har du bevis for, at det ikke er en simpel størrelsesgrænse på den sti. Skriv det ned, for det fjerner en hel gren af mulige ændringer.

Juster én parameter, som klienten allerede understøtter

Ændr den indstilling, klienten dokumenterer til denne protokol, og lad endepunktet og destinationen være urørt, ellers har du ændret to ting på én gang. En TCP-MSS-clamp dækker ikke alle UDP-arbejdsbelastninger, og derfor kan en browser, der begynder at virke, lade tunnelprotokollen være præcis lige så brudt. IPv4 og IPv6 er separate stier her, fordi headere er forskellige, før nogen routing gør noget.

Test begge familier, hvis du udgiver begge, for et resultat fra den ene siger intet om den anden. En værdi, der virkede på denne sti i aften, er et datapunkt og ikke en MTU for hele VPN. Forfrem den ikke til en global indstilling på grund af én vellykket overførsel. Skriv værdien ned ved siden af den sti, den kom fra.

Rul tilbage, verificer og skriv det ned

Sæt den oprindelige værdi tilbage, hvis sammenligningen ikke støtter hypotesen. Kontroller, at en netværksmanager ikke har gemt en vedvarende tilsidesættelse et andet sted, for sådan bliver et eksperiment til politik. Forbind igen, og afprøv almindelige applikationer, ikke kun den, du testede. Noter derefter symptomet, den effektive sti, den gamle og den nye værdi og hvor gentageligt resultatet var.

Gem den registrering sammen med ændringsanmodningen, før nogen udvider ændringen. Den sti-MTU-opdagelse i RFC 1191 forklarer, hvorfor en mindre værdi kan redde én sti og intet gøre for en anden, og en liste af tal er ingen erstatning for den model. Testen er færdig, når du kan navngive stien, størrelsen, observationen og den værdi, du genskabte.