MTU eller MSS? Hvad en VPN-ændring reelt løser

Ping lykkes, store overførsler hænger, og tunnelen melder sig selv sund. Nogen sænker interfacets MTU, en anden begrænser MSS, og ind imellem forsvinder problemet af grunde, som ingen skriver ned. De to tal beskriver forskellige objekter, så at ændre det forkerte giver en rettelse, der ligner held. Her er fremgangsmåden: identificér laget, anvend den matchende justering, og test derefter på en ny forbindelse.

To tal, to objekter

MTU hører til et link eller et interface: det er den største pakke, der kan overleveres uden at blive delt. MSS hører til TCP: det er den største mængde TCP-nyttelast, et segment kan bære, og det udelukker både TCP- og IP-headeren. På et almindeligt Ethernet-link med IPv4 giver en MTU på 1500 bytes den velkendte MSS på 1460 bytes. De tal beskriver forskellige lag og udveksles af forskellige mekanismer. Det er let at forveksle dem, fordi begge måles i bytes og begge ligger nær 1500.

Det ene kommer som en interface-indstilling. Det andet kommer som en option inde i et SYN-segment, forhandlet mellem endepunkter, der aldrig ser dit interface.

Hvor det ydre overhead lander

En VPN putter den indre pakke ind i en anden, og den ydre pakke skal passe til den fysiske vej. Indkapslingsheadere, den ydre IP-header, transportheaderen og enhver autentificeringstag bruger alle bytes, som den indre pakke ikke kan bruge. Lad tunnelinterfacet stå på 1500, og den ydre pakke overskrider rutinemæssigt, hvad vejen kan bære. Med bittet 'fragmentér ikke' sat dropper routeren den og skulle sende en ICMP-fejl tilbage; hvis den fejl filtreres, får afsenderen det aldrig at vide.

Det er derfor, fejlen ser selektiv ud. Små anmodninger fuldføres, og alt, der fylder et segment, går i stå, fordi kun de store pakker kasseres. En tunnel, der slipper et ping igennem, er ikke en tunnel, der bærer data.

MSS-begrænsning, og hvor den gælder

MSS-begrænsning omskriver værdien i SYN-segmentet, når det passerer et valgt punkt, hvilket får begge endepunkter til at vælge en mindre nyttelast uden at nogen af dem ved hvorfor. På Linux er det et mangle-tabelmål, der anvendes af en eksplicit regel, og det skal ramme SYN-pakker i den retning, du ønsker. Afgræns det til tunnelinterfacet og adresseområdet, fordi en bred regel ændrer adfærden for trafik, der aldrig kommer ind i tunnelen.

Effekten er kun på TCP. En UDP-applikation, en QUIC-session og enhver protokol, der bygger sine egne datagrammer, er urørte.

Diagnosticér med en fast vej

Hold én variabel ad gangen. Test med en pakke, hvis størrelse du selv vælger, og sæt flaget 'fragmentér ikke', så kernen rapporterer resultatet i stedet for at skjule det.

Notér, hvor fejlen begynder: inde i tunnelen, ved tunnelinterfacet eller på den fysiske vej efter indkapslingen. Skift derefter ét tal, og gentag den samme test i stedet for en anden. Eksisterende forbindelser beholder den MSS, de forhandlede, så en politikændring er kun synlig på en ny forbindelse, og derfor beviser en cachet side intet i nogen retning. Hvis én stor upload begynder at virke, har du lært om den vej og ikke om hver protokol på den.

Hvad hver ændring ikke løser

At sænke interfacets MTU ændrer ikke MSS for en session, der allerede er etableret. MSS-begrænsning hjælper ikke en UDP-strøm og reparerer ikke en vej, hvor ICMP-fejl kun filtreres i én retning. Hver ændring løser én klasse af problemer og efterlader resten præcis, som de var.

Skriv ned, hvilken justering du anvendte, hvor, og hvilken test der viste forskellen, for ellers anvender den næste ingeniør begge og mister evnen til at sige, hvilken der gjorde en forskel. Hvis begrænsningen er reel og permanent, foretræk en tunnel-MTU, der afspejler den, frem for en begrænsning, der skjuler den. Hvis du må begrænse, så lad reglen være afgrænset og kommenteret, da en uforklaret mangle-regel som standard bliver permanent.