Testa ett misstänkt MTU-problem i VPN utan att gissa värden

Att prova en lista med internet-MTU-värden tills ett känns snabbare är inte ett test, det är en sökning utan stoppregel. Metoden som fungerar ändrar ett kontrollerat storleksvillkor och jämför resultatet med samma väg. Börja med ett repeterbart, ofarligt fel och behåll den fungerande konfigurationen som låter dig ångra experimentet. Allt nedan förutsätter den disciplinen, för utan den slutar du med en siffra du inte kan försvara.

Fastställ vägen innan du rör en siffra

Skriv ner enheten, åtkomstlänken, tunnelprotokollet, slutpunkten, målet och adressfamiljen innan du rör en inställning. De sex fakta är vägen, och en mätning mot en annan väg mäter ett annat problem. De gör också resultatet reproducerbart, och det är vad som skiljer ett test från en eftermiddag av petande. Håll anteckningen vid terminalen i stället för i huvudet.

Börja med det snävaste test du har tillstånd att köra. En ändring på serversidan når varje användare av den slutpunkten, så den hör hemma i slutet av utredningen, inte i början.

Mät med en storlek du kontrollerar

På Linux ser mätningen ut som ping -M do -s 1400 host, och på Windows som ping -f -l 1400 host. I båda fallen ställer du in nyttolasten och inte paketstorleken, eftersom IP- och ICMP-huvudena läggs ovanpå.

Läs dokumentationen för systemet framför dig i stället för att kopiera en flagga från ett foruminlägg. Välj ett mål du kontrollerar, så att ett uteblivet svar är en signal och inte en gåta. Anteckna det exakta kommandot och den exakta storleken i samma anteckning som vägen. Ett resultat utan storlek är en anekdot. Ändrar du två saker i en körning vet du inte vilken av dem som gav resultatet.

En misslyckad mätning bevisar ingen MTU-gräns

En tappad mätning kan betyda ICMP-filtrering och inte en storleksgräns, och det misstaget får folk att justera ett värde som aldrig var problemet. Jämför mätningen med den riktiga applikationen och med ett storleksrelaterat felmeddelande eller en riktad avlyssning, innan du ändrar något. Lyckade små ping bevisar inte heller något, eftersom de kan ligga bekvämt under gränsen. Två oberoende observationer är minimumet innan en konfiguration flyttas.

Om applikationen misslyckas medan mätningen lyckas har du bevis för att det inte är en enkel storleksgräns på den vägen. Skriv ner det, för det tar bort en hel gren av möjliga ändringar.

Justera en parameter som klienten redan stöder

Ändra den inställning som klienten dokumenterar för det här protokollet och lämna slutpunkten och målet orörda, annars har du ändrat två saker samtidigt. En TCP-MSS-klämma täcker inte alla UDP-arbetslaster, vilket är varför en webbläsare som börjar fungera kan lämna tunnelprotokollet precis lika trasigt. IPv4 och IPv6 är separata vägar här, eftersom huvudena skiljer sig innan någon routning gör det.

Testa båda familjerna om du publicerar båda, eftersom ett resultat från den ena inte säger något om den andra. Ett värde som fungerade på den här vägen i kväll är en mätpunkt och inte en MTU för hela VPN. Befordra det inte till en global inställning på styrkan av en enda lyckad överföring. Skriv ner värdet bredvid vägen det kom från.

Ångra, verifiera och skriv ner det

Sätt tillbaka det ursprungliga värdet om jämförelsen inte stöder hypotesen. Kontrollera att en nätverkshanterare inte har sparat en beständig åsidosättning någon annanstans, för så blir ett experiment till policy. Anslut igen och prova vanliga applikationer, inte bara den du testade. Anteckna sedan symtomet, den effektiva vägen, det gamla och det nya värdet och hur repeterbart resultatet var.

Förvara den anteckningen med ändringsbegäran innan någon breddar ändringen. Den väg-MTU-upptäckt i RFC 1191 förklarar varför ett mindre värde kan rädda en väg och inte göra något för en annan, och en lista med siffror ersätter inte den modellen. Testet är klart när du kan namnge vägen, storleken, observationen och värdet du återställde.