MTU eller MSS? Kva ei VPN-endring faktisk rettar

Ping lukkast, store overføringar heng, og tunnelen melder seg sjølv sunn. Nokon senkjer MTU-en på grensesnittet, ein annan avgrensar MSS, og av og til forsvinn problemet av grunnar ingen skriv ned. Dei to tala skildrar ulike objekt, så å endre det gale gjev ei retting som ser ut som flaks. Her er framgangsmåten: identifiser laget, bruk den samsvarande justeringa, og test deretter på ei ny tilkopling.

To tal, to objekt

MTU høyrer til eit samband eller eit grensesnitt: det er den største pakken som kan overleverast utan å verte delt. MSS høyrer til TCP: det er den største mengda TCP-nyttelast eit segment kan føre, og det utelèt både TCP- og IP-hovudet. På eit vanleg Ethernet-samband med IPv4 gjev ein MTU på 1500 byte den kjende MSS-en på 1460 byte. Desse tala skildrar ulike lag og vert utveksla av ulike mekanismar. Det er lett å blande dei fordi begge vert målte i byte og begge ligg nær 1500.

Det eine kjem som ei innstilling på grensesnittet. Det andre kjem som eit alternativ inne i eit SYN-segment, forhandla mellom endepunkt som aldri ser grensesnittet ditt.

Kvar den ytre overheaden landar

Ein VPN puttar den indre pakken inni ein annan, og den ytre pakken må passe til den fysiske vegen. Innkapslingshovud, det ytre IP-hovudet, transportørhovudet og eit kvar autentiseringstag brukar alle byte den indre pakken ikkje kan bruke. Lat tunnelgrensesnittet stå på 1500, og den ytre pakken overskrid rutinemessig det vegen kan føre. Med 'ikkje fragmenter'-biten sett slepp rutaren han og skal sende ein ICMP-feil tilbake; om den feilen vert filtrert, får avsendar aldri vita det.

Det er difor feilen ser selektiv ut. Små førespurnader vert fullførte, og alt som fyller eit segment stoppar, fordi berre dei store pakkane vert kasta. Ein tunnel som slepp ein ping gjennom, er ikkje ein tunnel som fører data.

MSS-avgrensing, og kvar ho gjeld

MSS-avgrensing skriv om verdien i SYN-segmentet når det passerer eit valt punkt, noko som får begge endepunkta til å velje ei mindre nyttelast utan at nokon av dei veit kvifor. På Linux er det eit mål i mangle-tabellen som vert brukt av ein eksplisitt regel, og det må treffe SYN-pakkar i retninga du ønskjer. Avgrens det til tunnelgrensesnittet og adresseområdet, fordi ein brei regel endrar åtferda til trafikk som aldri kjem inn i tunnelen.

Effekten er berre på TCP. Ein UDP-applikasjon, ein QUIC-økt og ein kvar protokoll som byggjer sine eigne datagram, er urørte.

Diagnostiser med ein fast veg

Hald éin variabel om gongen. Test med ein pakke der du vel storleiken sjølv, og set flagget 'ikkje fragmenter' slik at kjernen rapporterer resultatet i staden for å skjule det.

Noter kvar feilen byrjar: inne i tunnelen, ved tunnelgrensesnittet eller på den fysiske vegen etter innkapslinga. Bytt så eitt tal og gjer den same testen om att i staden for ein annan. Eksisterande tilkoplingar held på MSS-en dei forhandla, så ei policyendring er berre synleg på ei ny tilkopling, og difor provar ei bufreidd side ingenting i nokon retning. Om éin stor opplasting byrjar å verke, har du lært om den vegen og ikkje om kvar protokoll på han.

Kva kvar endring ikkje rettar

Det hjelper ikkje å senkje MTU-en på grensesnittet for MSS-en til ei økt som alt er etablert. MSS-avgrensing hjelper ikkje ein UDP-straum, og ho reparerer ikkje ein veg der ICMP-feil berre vert filtrerte i éi retning. Kvar endring rettar éin klasse problem og let resten vere nøyaktig som dei var.

Skriv ned kva justering du brukte, kvar, og kva test som viste skilnaden, for elles brukar neste ingeniør begge og mistar evna til å seie kva som betydde noko. Om avgrensinga er reell og permanent, føretrekk ein tunnel-MTU som speglar henne framfor ei avgrensing som skjuler henne. Om du må avgrense, lat regelen vere trong og kommentert, sidan ein uforklart mangle-regel vert permanent som standard.