MTU pr. rute på Linux: tre størrelsesknapper, én rute
MTU for grænsefladen, MTU for ruten og MSS-begrænsningen virker på forskellige lag. Sæt et budget på den rute, der vinder opslaget, og hold ændringen reversibel.
Tre indstillinger på en Linux-klient lyder alle som »gør pakkerne mindre«, og de virker på forskellige lag. Grænsefladens MTU begrænser hver pakke, enheden sender. En rutes MTU begrænser pakker, der bruger den rute, og det er ofte det, du faktisk vil have til én VPN-destination. TCP MSS-begrænsningen ændrer, hvad de to ender forhandler, og den gør intet for UDP.
Tre knapper, der ligner det samme håndtag
Sæt dem side om side, før du vælger, fordi den forkerte række forklarer det meste af det råd, der ikke virker:
| 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 |
At sænke Ethernet-MTU'et for hele maskinen er den grove version af denne løsning. Det virker, og det straffer også alle andre programmer på værten, inklusive dem, hvis stier var fine. En værdi for hver rute udtrykker den samme hensigt uden sideomkostningen.
Sammenligningen gælder kun for trafik, som værten selv genererer. Videresendelse af en pakke for en anden klient involverer den klients egen sti og tunnelens ydre budget, og en rutemetrik på denne vært når ikke over den grænse.
Sæt budgettet på den rute, der vinder opslaget
En illustrativ IPv4-rutepost ser sådan ud:
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 1380Læs posten som en beskrivelse af hensigten, ikke som en værdi, der skal indsættes. Præfiks, enhed og foretrukken kilde skal matche den virkelige konfiguration, og tallet skal komme fra evidens om den indkapslede sti, ikke fra et blogindlæg. Rutens MTU begrænser den indre IP-pakke, hvilket ikke er det samme som en TCP-nyttelast på 1380 byte eller en krypteret ydre pakke på 1380 byte.
Se, hvor opslaget faktisk afgøres, før du tilføjer noget. En vært med politikregler kan rute en given destination gennem en anden tabel end main, og en metrik, der kun findes i main , er usynlig for den anmodning. Sammenlign ip -4 route show table all med svaret fra ip route get, inklusive mark- eller navnerumskonteksten, når reglerne bruger dem. Hvis de to er uenige, er den tabel, der svarede, den, der har brug for metrikken, ikke den, der ser pænere ud.
mtu er ikke mtu lock
Som standard kan kernen stadig opdatere stiens MTU ud fra ICMP-feedback, og det er det, sti-MTU-opdagelse er til. At tilføje lock standser det. Det er en anden beslutning, ikke en stærkere måde at gemme det samme tal, og for IPv4 ændrer det den dokumenterede håndtering af don't-fragment-bittet.
Låsning er rimelig, når du har målt stien og vil have værdien til at blive stående, uanset hvad der ankommer. Det er en dårlig standard, når netværket sender legitim størrelsesfeedback, fordi kernen ikke længere kan justere, og fejlen flytter sig til et andet symptom.
Hvis ICMP filtreres et sted på stien, reparerer ingen ruteindstilling det. Rettelsen hører til filteret, og en mindre MTU er en omvej, der skjuler den egentlige fejl, indtil den næste stiændring.
Tunnelsoftware tilføjer sine egne størrelsesknapper
OpenVPN- mssfix justerer TCP-segmentstørrelsen til sit dokumenterede UDP-tunneltilfælde. Det virker på TCP-samtalen, så det er ikke en anden stavemåde for operativsystemets rute-MTU, og det kan ikke hjælpe en UDP-tjeneste, der ignorerer forhandlingen.
Stabl ikke en rute-MTU, en ændring af grænseflade-MTU og en MSS-begrænsning i samme ændringsvindue. Hvis problemet forsvinder, ved du ikke, hvilken der gjaldt, og dem, du beholder, vil begrænse trafik i årevis uden en grund, nogen husker.
Gør det reversibelt, og bevis det så
Rutens egentlige ejer afgør, om ændringen overlever en genopkobling. En VPN-klient, der installerer ruten dynamisk, vil normalt genopbygge den uden din metrik, og en manuel ip route add ser så ud som en rettelse, der fejlede en dag senere. Sæt værdien i managerens konfiguration, og hvis du har brug for et midlertidigt eksperiment, så noter den oprindelige rute først.
Test med en ny forbindelse, der udfører den handling, der gik i stå, og bekræft derefter, at den tilsigtede private rute stadig vinder, og at ikke-relaterede destinationer er uændrede. Genopkobl tunnelen, og læs ruten igen, fordi en værdi, der forsvinder ved genopkobling, ikke er en rettelse.
Hvis evidensen ikke understøtter ændringen, fjern tilsidesættelsen via dens manager, og gendan de oprindelige ruteattributter i stedet for at slette ruten. Noter derefter, hvad du målte, og på hvilken sti, så den næste person kan skelne en reel forbedring fra et eksperiment, der blev ladt kørende.