MTU per rutt på Linux: tre storlekskontroller, en rutt
Gränssnittets MTU, ruttens MTU och MSS-gränsen verkar på olika lager. Knyt en budget till rutten som vinner sökningen och håll ändringen återställbar.
Tre inställningar på en Linux-klient låter alla som ”gör paketen mindre”, och de verkar på olika lager. Gränssnittets MTU begränsar varje paket som enheten skickar. En rutts MTU begränsar paket som använder den rutten, och det är ofta det du faktiskt vill ha för en VPN-destination. TCP MSS-gränsen ändrar vad de två ändarna förhandlar om, och den gör ingenting för UDP.
Tre kontroller som ser ut som samma ratt
Ställ dem sida vid sida innan du väljer, för fel rad förklarar det mesta av rådet som inte fungerar:
| 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 |
Att sänka Ethernet-MTU:n för hela maskinen är den grova versionen av den här åtgärden. Det fungerar, och det straffar också alla andra program på värden, inklusive de vars vägar var i ordning. Ett värde per rutt uttrycker samma avsikt utan sidokostnaden.
Jämförelsen gäller bara trafik som värden själv genererar. Vidarebefordran av ett paket för en annan klient involverar dennes egen väg och tunnels yttre budget, och ett ruttmetrik på den här värden når inte över den gränsen.
Knyt budgeten till rutten som vinner sökningen
En illustrativ IPv4-ruttpost ser ut så här:
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 beskrivning av avsikt, inte som ett värde att klistra in. Prefixet, enheten och den föredragna källan måste stämma med den verkliga konfigurationen, och talet måste komma från bevis om den inkapslade vägen, inte från ett blogginlägg. Ruttens MTU begränsar det inre IP-paketet, vilket inte är samma sak som en TCP-nyttolast på 1380 byte eller ett krypterat yttre paket på 1380 byte.
Titta var sökningen faktiskt löses innan du lägger till något. En värd med policyregler kan routa en given destination via en annan tabell än main, och ett metrikvärde som bara finns i main är osynligt för den begäran. Jämför ip -4 route show table all med svaret från ip route get, inklusive mark- eller namnområdeskontexten när reglerna använder dem. Om de två inte stämmer är tabellen som svarade den som behöver metriken, inte den som ser städare ut.
mtu är inte mtu lock
Som standard kan kärnan fortfarande uppdatera vägens MTU från ICMP-återkoppling, och det är vad väg-MTU-upptäckt är till för. Att lägga till lock stoppar det. Det är ett annat beslut, inte ett starkare sätt att behålla samma tal, och för IPv4 ändrar det den dokumenterade hanteringen av ”fragmentera inte”-biten.
Låsning är rimligt när du har mätt vägen och vill att värdet ska stå kvar oavsett vad som kommer. Det är en dålig standard när nätet skickar legitim storleksåterkoppling, eftersom kärnan inte längre kan justera och felet flyttar sig till ett annat symptom.
Om ICMP filtreras någonstans på vägen reparerar ingen ruttinställning det. Rättelsen hör till filtret, och en mindre MTU är en genväg som döljer det egentliga felet till nästa vägändring.
Tunnelprogramvara lägger till sina egna storleksrattar
OpenVPN- mssfix justerar TCP-segmentstorleken för sitt dokumenterade UDP-tunnelfall. Det verkar på TCP-samtalet, så det är inte en annan stavning av operativsystemets rutt-MTU, och det kan inte hjälpa en UDP-tjänst som ignorerar förhandlingen.
Stapla inte en rutt-MTU, en ändring av gränssnitts-MTU och en MSS-gräns i samma ändringsfönster. Om problemet försvinner vet du inte vilken som spelade roll, och de du behåller kommer att begränsa trafik i åratal utan en anledning som någon minns.
Gör det återställbart och bevisa det sedan
Ruttens verkliga ägare avgör om ändringen överlever en återanslutning. En VPN-klient som installerar rutten dynamiskt bygger oftast upp den igen utan ditt metrikvärde, och en manuell ip route add ser då ut som en rättelse som misslyckades en dag senare. Lägg värdet i hanterarens konfiguration, och om du behöver ett tillfälligt experiment, skriv först upp den ursprungliga rutten.
Testa med en ny anslutning som utför operationen som fastnade, och bekräfta sedan att den avsedda privata rutten fortfarande vinner och att orelaterade destinationer är oförändrade. Anslut tunneln igen och läs rutten igen, för ett värde som försvinner vid återanslutning är ingen rättelse.
Om bevisen inte stöder ändringen, ta bort överstyrningen via dess hanterare och återställ de ursprungliga ruttattributen i stället för att radera rutten. Skriv sedan ned vad du mätte och på vilken väg, så att nästa person kan skilja en verklig förbättring från ett experiment som lämnades att köra.