MTU per rute på Linux: tre størrelseskontroller, én rute
Grensesnitt-MTU, rute-MTU og MSS-grensen virker på ulike lag. Fest et budsjett til ruten som vinner oppslaget, og hold endringen reversibel.
Tre innstillinger på en Linux-klient høres alle ut som «gjør pakkene mindre», og de virker på ulike lag. Grensesnitt-MTU begrenser hver pakke enheten sender. En rute-MTU begrenser pakker som bruker den ruten, og det er ofte det du faktisk vil ha for én VPN-destinasjon. TCP MSS-grensen endrer hva de to endene forhandler om, og den gjør ingenting for UDP.
Tre kontroller som ser ut som samme knott
Sett dem side om side før du velger, fordi feil rad forklarer det meste av rådet som ikke fungerer:
| Control | Scope | What it cannot fix |
|---|---|---|
| Interface MTU | Every packet the device sends | Nothing, but it over-constrains unrelated traffic |
| Route MTU | Packets using that route | A send that the lookup never routes there |
| MSS clamp | TCP handshake on that path | UDP payload sizes and ICMP |
Å senke Ethernet-MTU-en for hele maskinen er den grove versjonen av denne fiksen. Det virker, og det straffer også alle andre programmer på verten, inkludert dem hvis stier var fine. En verdi per rute uttrykker samme intensjon uten sidekostnaden.
Sammenligningen gjelder bare for trafikk verten selv genererer. Videresending av en pakke for en annen klient involverer dens egen sti og tunnelens ytre budsjett, og en rutemetrikk på denne verten når ikke over den grensen.
Fest budsjettet til ruten som vinner oppslaget
En illustrerende IPv4-rutepost ser slik ut:
ip -4 route get 10.60.0.20
ip -4 route add 10.60.0.0/16 dev tun-office src 10.90.0.2 mtu 1380Les posten som en beskrivelse av intensjon, ikke som en verdi å lime inn. Prefikset, enheten og foretrukket kilde må samsvare med den virkelige konfigurasjonen, og tallet må komme fra bevis om den innkapslede stien, ikke fra et blogginnlegg. Rute-MTU-en begrenser den indre IP-pakken, som ikke er det samme som en TCP-nyttelast på 1380 byte eller en kryptert ytre pakke på 1380 byte.
Se hvor oppslaget faktisk løses før du legger til noe. En vert med policyregler kan rute en gitt destinasjon gjennom en annen tabell enn main, og en metrikk som bare finnes i main , er usynlig for den forespørselen. Sammenlign ip -4 route show table all med svaret fra ip route get, inkludert mark- eller navneromskonteksten når reglene bruker dem. Hvis de to er uenige, er tabellen som svarte den som trenger metrikken, ikke den som ser ryddigere ut.
mtu er ikke mtu lock
Som standard kan kjernen fortsatt oppdatere sti-MTU-en fra ICMP-tilbakemelding, og det er det sti-MTU-oppdagelse er til. Å legge til lock stopper det. Det er en annen beslutning, ikke en sterkere måte å bevare samme tall, og for IPv4 endrer det den dokumenterte håndteringen av don't-fragment-biten.
Låsing er rimelig når du har målt stien og vil at verdien skal bli stående uansett hva som kommer. Det er en dårlig standard når nettet sender legitim størrelsesfeedback, fordi kjernen ikke lenger kan justere og feilen flytter seg til et annet symptom.
Hvis ICMP filtreres et sted på stien, reparerer ingen ruteinnstilling det. Rettelsen hører til filteret, og en mindre MTU er en omvei som skjuler den egentlige feilen til neste stiendring.
Tunnelprogramvare legger til sine egne størrelsesknotter
OpenVPN- mssfix justerer TCP-segmentstørrelsen for sitt dokumenterte UDP-tunneltilfelle. Det virker på TCP-samtalen, så det er ikke en annen stavemåte for operativsystemets rute-MTU, og det kan ikke hjelpe en UDP-tjeneste som ignorerer forhandlingen.
Ikke stable en rute-MTU, en endring av grensesnitt-MTU og en MSS-grense i samme endringsvindu. Hvis problemet forsvinner, vet du ikke hvilken som gjaldt, og dem du beholder vil begrense trafikk i årevis uten en grunn noen husker.
Gjør det reversibelt, og bevis det så
Rutens egentlige eier avgjør om endringen overlever en gjenoppkobling. En VPN-klient som installerer ruten dynamisk, vil vanligvis bygge den opp igjen uten metrikken din, og en manuell ip route add ser da ut som en rettelse som feilet en dag senere. Sett verdien i behandlerens konfigurasjon, og hvis du trenger et midlertidig eksperiment, noter den opprinnelige ruten først.
Test med en ny tilkobling som utfører operasjonen som stoppet, og bekreft deretter at den tiltenkte private ruten fortsatt vinner og at ikke-relaterte destinasjoner er uendret. Koble til tunnelen på nytt og les ruten igjen, fordi en verdi som forsvinner ved gjenoppkobling ikke er en rettelse.
Hvis bevisene ikke støtter endringen, fjern overstyringen via dens behandler og gjenopprett de opprinnelige ruteattributtene i stedet for å slette ruten. Noter deretter hva du målte, på hvilken sti, slik at neste person kan skille en reell forbedring fra et eksperiment som ble latt stå på.