Pad-MTU-ontdekking via een VPN: dimensionering en het ICMP-gat

Een tunnel rondt zijn handshake af, kleine verzoeken komen terug, en de eerste grote overdracht stokt. Dat patroon wijst veel eerder op de pad-MTU dan op doorvoer. Elke schakel langs de route begrenst de pakketgrootte, en inkapseling besteedt een deel van die ruimte aan buitenste headers, dus het binnenste pakket moet kleiner zijn dan het ruwe pad suggereert. De fout is stil, en dat maakt hem duur om te diagnosticeren.

Wat de pad-MTU werkelijk meet

De pad-MTU is de kleinste schakel-MTU op de route tussen twee hosts, niet de MTU die op je lokale interface staat. De lokale waarde is waar de schatting begint, en het pad bepaalt waar die moet eindigen. Daarom kan dezelfde tunnel op het ene toegangsnetwerk werken en op het andere vastlopen: de route veranderde, niet de configuratie. Eén keer meten en overal aannemen is de fout die dit probleem in leven houdt.

Voor een tunnel is het getal dat telt de binnenste MTU, dat is de ruimte van het buitenste pad min wat de inkapseling verbruikt. WireGuard voegt een buitenste IP-header en een UDP-header toe; andere transporten voegen hun eigen toe. Zet de binnenste grootte te hoog en elk pakket op volle grootte heeft fragmentatie nodig die misschien nooit gebeurt.

Waarom een tunnel het bruikbare pakket verkleint

Als de tunnelinterface de MTU van de fysieke schakel aanhoudt, hangt elk groot pakket ervan af of iemand stroomafwaarts bereid is het te fragmenteren. IPv4 staat dat in principe toe, maar een router die te horen kreeg niet te fragmenteren geeft in plaats daarvan een fout terug. IPv6-routers fragmenteren onderweg helemaal nooit, dus dezelfde instelling gedraagt zich anders per adresfamilie. Hoe dan ook leert de afzender niets tot iets terugrapporteert.

Het praktische gevolg is een grootte die in de handshake past en niet in de payload. Een TLS ClientHello of een DNS-query is klein genoeg om een gekrompen pad onaangetast over te steken, terwijl een bulkoverdracht dat niet is. Symptomen clusteren daarom rond specifieke bewerkingen in plaats van specifieke hosts.

Ontdekking werkt alleen als de terugkoppeling aankomt

IPv4-ontdekking leunt op de don't-fragment-bit: een router die het pakket niet kan doorsturen, retourneert ICMP fragmentation-needed met de MTU van de volgende hop, en de afzender verlaagt zijn schatting. IPv6 gebruikt in plaats daarvan Packet Too Big-berichten, omdat routers onderweg niet fragmenteren. Beide mechanismen gaan ervan uit dat het bericht de weg terug naar de afzender vindt, door de tunnel en langs elke firewall op het retourpad. Als die aanname faalt, blijft de afzender een grootte herhalen die het pad niet kan dragen.

Een firewall die echo request en echo reply toestaat, heeft niet noodzakelijk die fouttypen toegestaan. ICMP is een familie, en de leden die hier van belang zijn, zijn de fouten, niet het echopaar. Controleer het beleid voor controleverkeer aan beide uiteinden van de tunnel en op het pad ertussen, en volg de ondersteunde richtlijnen van het platform in plaats van overal elk ICMP-type toe te staan.

Dezelfde filtering kan binnen de tunnel zitten. Als het binnenste pad de fout laat vallen maar het buitenste pad hem draagt, kan de afzender zich aanpassen aan een limiet die het ingekapselde verkeer nooit echt ziet.

Test het pad in plaats van een getal te raden

Houd de bestemming, het toegangsnetwerk en de tunnel vast, en varieer alleen de pakketgrootte. Een don't-fragment-test die faalt met een MTU-hint geeft je de limiet van de volgende hop; herhaal tot een grootte slaagt, en noteer zowel de grootte als de adresfamilie.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

Een ping die past bewijst niet dat volledige segmenten van een echte toepassing passen, dus herhaal de test met de overdracht die echt faalde. Vergelijk de grootste werkende test met de tunnel-MTU die je hebt geconfigureerd, en houd de twee getallen apart in je notities. Als ze ongeveer een header verschillen, heb je de inkapselingsoverhead gevonden en geen fout.

PLPMTUD, beschreven in RFC 4821, test omhoog en gebruikt transportbevestigingen in plaats van afgeleverde fouten te vertrouwen. Het helpt op paden die ICMP filteren, maar de ondersteuning verschilt per stack en per toepassing. Een TCP-stroom kan zichzelf herstellen terwijl een UDP-toepassing met vaste datagramgrootte blijft falen.

Kies een waarde en leg de redenering vast

De tunnel-MTU verlagen is zowel een diagnose als een legitieme oplossing zodra je het pad kent. Het is geen vervanging voor weten welk pad en welk terugkoppelingsmechanisme betrokken waren, want een waarde die op een mobiele schakel is afgestemd, is onnodig klein op een glasvezelverbinding. Noteer de gekozen grootte, de test die hem rechtvaardigde en de terugdraaistap.

Het IPv4-mechanisme staat in RFC 1191 en de IPv6-pakketteringsrichtlijn in RFC 8201; beide noemen weerhoudt de volgende engineer ervan de aanname opnieuw af te leiden. Als de overdracht bij de gekozen grootte nog steeds stokt, stop dan met het verlagen van het getal en kijk naar de volgende laag. Een pad dat bij elke grootte faalt, is geen MTU-probleem.