MTU per route op Linux: drie groteregelaars, één route

Drie instellingen op een Linux-client klinken allemaal als «maak de pakketten kleiner», en ze werken op verschillende lagen. De interface-MTU begrenst elk pakket dat het apparaat verstuurt. Een route-MTU begrenst pakketten die die route gebruiken, en dat is vaak precies wat je voor één VPN-bestemming echt wilt. De TCP MSS-clamp verandert wat de twee uiteinden onderhandelen, en voor UDP doet hij niets.

Drie regelaars die op dezelfde knop lijken

Zet ze naast elkaar voordat je kiest, want de verkeerde rij kiezen verklaart het grootste deel van het advies dat niet werkt:

De Ethernet-MTU voor de hele machine verlagen is de botte versie van deze oplossing. Het werkt, en het straft ook elke andere toepassing op de host, ook degene wier paden in orde waren. Een waarde per route drukt dezelfde bedoeling uit zonder de bijkomende kosten.

De vergelijking geldt alleen voor verkeer dat de host zelf genereert. Een pakket doorsturen voor een andere client omvat diens eigen pad en het buitenbudget van de tunnel, en een routemetriek op deze host reikt niet over die grens.

Hang het budget aan de route die de lookup wint

Een illustratief IPv4-routerecord ziet er zo uit:

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

Lees het record als een beschrijving van de bedoeling, niet als een waarde om te plakken. Het prefix, het apparaat en de voorkeursbron moeten bij de echte configuratie passen, en het getal moet uit bewijs over het ingekapselde pad komen, niet uit een blogpost. De route-MTU begrenst het binnenste IP-pakket, wat niet hetzelfde is als een TCP-lading van 1380 bytes of een versleuteld buitenste pakket van 1380 bytes.

Kijk waar de lookup werkelijk wordt opgelost voordat je iets toevoegt. Een host met beleidsregels kan een bestemming via een andere tabel dan main routeren, en een metriek die alleen in main bestaat, is onzichtbaar voor dat verzoek. Vergelijk ip -4 route show table all met het antwoord van ip route get, inclusief de mark- of naamruimtecontext wanneer de regels die gebruiken. Als de twee het niet eens zijn, is de tabel die antwoordde degene die de metriek nodig heeft, niet degene die er netter uitziet.

mtu is niet mtu lock

Standaard kan de kernel de pad-MTU nog bijwerken op basis van ICMP-feedback, en daar is pad-MTU-detectie voor. Het toevoegen van lock stopt dat. Het is een andere beslissing, geen sterkere manier om hetzelfde getal te bewaren, en voor IPv4 verandert het de gedocumenteerde omgang met de don't-fragment-bit.

Vergrendelen is redelijk wanneer je het pad hebt gemeten en wilt dat de waarde blijft staan, wat er ook aankomt. Het is een slechte standaard wanneer het netwerk legitieme feedback over de grootte stuurt, omdat de kernel niet meer kan bijstellen en de fout naar een ander symptoom verschuift.

Als ICMP ergens op het pad wordt gefilterd, repareert geen enkele route-instelling dat. De correctie hoort bij het filter, en een kleinere MTU is een omweg die de echte fout verbergt tot de volgende padwijziging.

Tunnelsoftware voegt zijn eigen groteregelaars toe

OpenVPN- mssfix past de TCP-segmentgrootte aan voor zijn gedocumenteerde UDP-tunnelgeval. Het werkt op het TCP-gesprek, dus het is geen andere spelling van de route-MTU van het besturingssysteem, en het kan een UDP-dienst die de onderhandeling negeert niet helpen.

Stapel geen route-MTU, een interface-MTU-wijziging en een MSS-clamp in hetzelfde wijzigingsvenster. Als het probleem verdwijnt, weet je niet welke ertoe deed, en degenen die je houdt zullen verkeer jaren beperken zonder reden die iemand zich herinnert.

Maak het omkeerbaar en bewijs het dan

De echte eigenaar van de route bepaalt of de wijziging een herverbinding overleeft. Een VPN-client die de route dynamisch installeert, bouwt hem meestal opnieuw op zonder jouw metriek, en een handmatige ip route add ziet er dan uit als een oplossing die een dag later faalde. Zet de waarde in de configuratie van de beheerder, en als je een tijdelijk experiment nodig hebt, leg dan eerst de oorspronkelijke route vast.

Test met een nieuwe verbinding die de bewerking uitvoert die vastliep, en bevestig dan dat de bedoelde privéroute nog steeds wint en niet-verwante bestemmingen onveranderd zijn. Verbind de tunnel opnieuw en lees de route weer, want een waarde die bij herverbinding verdwijnt is geen oplossing.

Als het bewijs de wijziging niet ondersteunt, verwijder dan de overschrijving via de beheerder en herstel de oorspronkelijke routeattributen in plaats van de route te verwijderen. Noteer daarna wat je hebt gemeten, op welk pad, zodat de volgende persoon een echte verbetering kan onderscheiden van een experiment dat is blijven draaien.