MTU per rute på Linux: tre storleikskontrollar, éi rute

Tre innstillingar på ein Linux-klient høyrest alle ut som «gjer pakkane mindre», og dei verkar på ulike lag. Grensesnitt-MTU avgrensar kvar pakke eininga sender. Ei rute-MTU avgrensar pakkar som brukar den ruta, og det er ofte det du faktisk vil ha for ein VPN-destinasjon. TCP MSS-grensa endrar kva dei to endane forhandlar om, og ho gjer ingenting for UDP.

Tre kontrollar som ser ut som same knott

Set dei side om side før du vel, fordi feil rad forklarer det meste av rådet som ikkje verkar:

Å senke Ethernet-MTU-en for heile maskina er den grove versjonen av denne fiksen. Det verkar, og det straffar også alle andre program på verten, også dei som stiane deira var i orden. Ein verdi per rute uttrykkjer same intensjon utan sidekostnaden.

Samanlikninga gjeld berre for trafikk verten sjølv genererer. Vidaresending av ein pakke for ein annan klient involverer stien hans og det ytre budsjettet til tunnelen, og ein rutemetrikk på denne verten når ikkje over den grensa.

Fest budsjettet til ruta som vinn oppslaget

Ei illustrerande 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 1380

Les posten som ei skildring av intensjon, ikkje som ein verdi å lime inn. Prefikset, eininga og føretrekt kjelde må samsvare med den verkelege konfigurasjonen, og talet må kome frå prov om den innkapsla stien, ikkje frå eit blogginnlegg. Rute-MTU-en avgrensar den indre IP-pakken, som ikkje er det same som ein TCP-nyttelast på 1380 byte eller ein kryptert ytre pakke på 1380 byte.

Sjå kvar oppslaget faktisk blir løyst før du legg til noko. Ein vert med policyreglar kan rute ein gitt destinasjon gjennom ein annan tabell enn main, og ein metrikk som berre finst i main , er usynleg for den førespurnaden. Samanlikn ip -4 route show table all med svaret frå ip route get, inkludert mark- eller namneromskonteksten når reglane brukar dei. Viss dei to er usamde, er tabellen som svara den som treng metrikken, ikkje den som ser ryddigare ut.

mtu er ikkje mtu lock

Som standard kan kjernen framleis oppdatere sti-MTU-en frå ICMP-tilbakemelding, og det er det sti-MTU-oppdaging er til. Å leggje til lock stoppar det. Det er ei anna avgjerd, ikkje ein sterkare måte å ta vare på same talet, og for IPv4 endrar det den dokumenterte handteringa av don't-fragment-biten.

Låsing er rimeleg når du har målt stien og vil at verdien skal bli ståande uansett kva som kjem. Det er ein dårleg standard når nettet sender legitim storleikstilbakemelding, fordi kjernen ikkje lenger kan justere og feilen flyttar seg til eit anna symptom.

Viss ICMP blir filtrert ein stad på stien, reparerer inga ruteinnstilling det. Rettinga høyrer til filteret, og ein mindre MTU er ein omveg som skjuler den eigentlege feilen til neste stiendring.

Tunnelprogramvare legg til sine eigne storleiksknottar

OpenVPN- mssfix justerer TCP-segmentstorleiken for sitt dokumenterte UDP-tunneltilfelle. Det verkar på TCP-samtalen, så det er ikkje ein annan stavemåte for rute-MTU-en til operativsystemet, og det kan ikkje hjelpe ein UDP-teneste som ignorerer forhandlinga.

Ikkje stable ein rute-MTU, ei endring av grensesnitt-MTU og ei MSS-grense i same endringsvindauge. Viss problemet forsvinn, veit du ikkje kva som gjaldt, og dei du held vil avgrense trafikk i årevis utan ein grunn nokon hugsar.

Gjer det reversibelt, og prov det så

Den eigentlege eigaren av ruta avgjer om endringa overlever ein gjenoppkopling. Ein VPN-klient som installerer ruta dynamisk, vil vanlegvis byggje henne opp att utan metrikken din, og ein manuell ip route add ser då ut som ei retting som feila ein dag seinare. Set verdien i konfigurasjonen til behandlaren, og viss du treng eit mellombels eksperiment, noter den opphavlege ruta først.

Test med ei ny tilkopling som utfører operasjonen som stoppa, og stadfest deretter at den tiltenkte private ruta framleis vinn og at ikkje-relaterte destinasjonar er uendra. Kopla til tunnelen på nytt og les ruta igjen, fordi ein verdi som forsvinn ved gjenoppkopling ikkje er ei retting.

Viss prova ikkje støttar endringa, fjern overstyringa via behandlaren og gjenopprett dei opphavlege ruteattributta i staden for å slette ruta. Noter deretter kva du målte, på kva sti, slik at neste person kan skilje ei reell betring frå eit eksperiment som vart late stå på.