MTU eller MSS? Hva en VPN-endring faktisk fikser

Ping lykkes, store overføringer henger, og tunnelen melder seg selv sunn. Noen senker MTU-en på grensesnittet, en annen begrenser MSS, og iblant forsvinner problemet av grunner ingen skriver ned. De to tallene beskriver forskjellige objekter, så å endre det feil gir en rettelse som ser ut som flaks. Her er fremgangsmåten: identifiser laget, bruk den matchende justeringen, og test deretter på en ny tilkobling.

To tall, to objekter

MTU tilhører en forbindelse eller et grensesnitt: det er den største pakken som kan overleveres uten å bli delt. MSS tilhører TCP: det er den største mengden TCP-nyttelast et segment kan bære, og det utelukker både TCP- og IP-headeren. På en vanlig Ethernet-forbindelse med IPv4 gir en MTU på 1500 byte den kjente MSS-en på 1460 byte. Disse tallene beskriver forskjellige lag og utveksles av forskjellige mekanismer. Det er lett å forveksle dem fordi begge måles i byte og begge ligger nær 1500.

Det ene kommer som en innstilling på grensesnittet. Det andre kommer som et alternativ inne i et SYN-segment, forhandlet mellom endepunkter som aldri ser grensesnittet ditt.

Hvor den ytre overheaden lander

En VPN putter den indre pakken inni en annen, og den ytre pakken må passe til den fysiske veien. Innkapslingsheadere, den ytre IP-headeren, transportheaderen og enhver autentiseringstagg bruker alle byte den indre pakken ikke kan bruke. La tunnelgrensesnittet stå på 1500, og den ytre pakken overskrider rutinemessig det veien kan bære. Med 'ikke fragmenter'-biten satt slipper ruteren den og skal sende en ICMP-feil tilbake; hvis den feilen filtreres, får avsenderen aldri vite det.

Det er derfor feilen ser selektiv ut. Små forespørsler fullføres, og alt som fyller et segment stopper, fordi bare de store pakkene forkastes. En tunnel som slipper en ping gjennom, er ikke en tunnel som bærer data.

MSS-begrensning, og hvor den gjelder

MSS-begrensning skriver om verdien i SYN-segmentet når det passerer et valgt punkt, noe som får begge endepunktene til å velge en mindre nyttelast uten at noen av dem vet hvorfor. På Linux er det et mål i mangle-tabellen som brukes av en eksplisitt regel, og det må treffe SYN-pakker i retningen du ønsker. Begrens det til tunnelgrensesnittet og adresseområdet, fordi en bred regel endrer oppførselen til trafikk som aldri kommer inn i tunnelen.

Effekten er bare på TCP. En UDP-applikasjon, en QUIC-økt og enhver protokoll som bygger sine egne datagrammer, er urørt.

Diagnostiser med en fast vei

Hold én variabel om gangen. Test med en pakke der du velger størrelsen selv, og sett flagget 'ikke fragmenter' slik at kjernen rapporterer resultatet i stedet for å skjule det.

Noter hvor feilen begynner: inne i tunnelen, ved tunnelgrensesnittet eller på den fysiske veien etter innkapslingen. Bytt så ett tall og gjenta den samme testen i stedet for en annen. Eksisterende tilkoblinger beholder MSS-en de forhandlet, så en policyendring er bare synlig på en ny tilkobling, og derfor beviser en bufret side ingenting i noen retning. Hvis én stor opplasting begynner å virke, har du lært om den veien og ikke om hver protokoll på den.

Hva hver endring ikke fikser

Å senke grensesnittets MTU endrer ikke MSS-en til en økt som allerede er etablert. MSS-begrensning hjelper ikke en UDP-strøm, og den reparerer ikke en vei der ICMP-feil bare filtreres i én retning. Hver endring fikser én klasse problemer og lar resten være nøyaktig som de var.

Skriv ned hvilken justering du brukte, hvor, og hvilken test som viste forskjellen, for ellers bruker neste ingeniør begge og mister evnen til å si hvilken som betydde noe. Hvis begrensningen er reell og permanent, foretrekk en tunnel-MTU som gjenspeiler den fremfor en begrensning som skjuler den. Hvis du må begrense, la regelen være snever og kommentert, siden en uforklart mangle-regel blir permanent som standard.