Oppdagelse av banens MTU gjennom en VPN: dimensjonering og ICMP-hullet

En tunnel fullfører håndtrykket, små forespørsler kommer tilbake, og den første store overføringen stopper. Dette mønsteret peker på banens MTU lenge før det peker på gjennomstrømning. Hver lenke langs ruten begrenser pakkestørrelsen, og innkapsling bruker en del av den kvoten på ytre headere, så den indre pakken må være mindre enn den rå banen skulle tilsi. Feilen er stille, og det er nettopp derfor den er dyr å diagnostisere.

Hva banens MTU faktisk måler

Banens MTU er den minste lenke-MTU-en på ruten mellom to verter, ikke MTU-en som er trykket på ditt lokale grensesnitt. Den lokale verdien er der anslaget starter, og banen avgjør hvor det må slutte. Det er derfor en identisk tunnel kan fungere på ett aksessnett og stoppe på et annet: ruten endret seg, ikke konfigurasjonen. Å måle én gang og anta overalt er feilen som holder dette problemet i live.

For en tunnel er tallet som betyr noe den indre MTU-en, som er den ytre banens kvote minus det innkapslingen bruker. WireGuard legger til en ytre IP-header og en UDP-header; andre transportlag legger til sine egne. Sett den indre størrelsen for høyt, og hver fullstørrelsespakke trenger fragmentering som kanskje aldri skjer.

Hvorfor en tunnel krymper den brukbare pakken

Hvis tunnelgrensesnittet beholder den fysiske lenkens MTU, avhenger hver stor pakke av at noen lenger ned er villig til å fragmentere den. IPv4 tillater det i prinsippet, men en ruter som får beskjed om ikke å fragmentere, returnerer en feil i stedet. IPv6-rutere fragmenterer aldri underveis, så samme innstilling oppfører seg ulikt etter adressefamilie. Uansett lærer avsenderen ingenting før noe rapporterer tilbake.

Den praktiske konsekvensen er en størrelse som passer i håndtrykket og ikke i nyttelasten. En TLS ClientHello eller en DNS-spørring er liten nok til å krysse en krympet bane urørt, mens en masseoverføring ikke er det. Symptomene samler seg derfor rundt bestemte operasjoner og ikke bestemte verter.

Oppdagelsen virker bare når tilbakemeldingen kommer frem

IPv4-oppdagelse bygger på don't-fragment-biten: en ruter som ikke kan videresende pakken, returnerer ICMP fragmentation-needed med neste hopps MTU, og avsenderen senker anslaget sitt. IPv6 bruker Packet Too Big-meldinger i stedet, fordi rutere ikke fragmenterer underveis. Begge mekanismene forutsetter at meldingen finner veien tilbake til avsenderen, gjennom tunnelen og forbi enhver brannmur på returveien. Når den forutsetningen svikter, fortsetter avsenderen å prøve en størrelse banen ikke kan bære.

En brannmur som tillater echo request og echo reply har ikke nødvendigvis tillatt de feiltypene. ICMP er en familie, og medlemmene som betyr noe her er feilene, ikke ekkoparet. Sjekk kontrolltrafikkpolitikken i begge ender av tunnelen og på veien mellom dem, og følg plattformens støttede veiledning i stedet for å tillate alle ICMP-typer overalt.

Den samme filtreringen kan sitte inne i tunnelen. Hvis den indre banen slipper feilen, men den ytre banen bærer den, kan avsenderen tilpasse seg en grense som den innkapslede trafikken aldri egentlig ser.

Test banen i stedet for å gjette et tall

Hold destinasjonen, aksessnettet og tunnelen fast, og endre bare pakkestørrelsen. En don't-fragment-test som feiler med et MTU-hint gir deg grensen for neste hopp; gjenta til en størrelse passerer, og noter både størrelsen og adressefamilien.

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

En ping som passer beviser ikke at fullstørrelsessegmentene til en ekte applikasjon passer, så gjenta testen med overføringen som faktisk feilet. Sammenlign den største testen som virket med tunnel-MTU-en du konfigurerte, og hold de to tallene atskilt i notatene dine. Hvis de avviker med omtrent én header, har du funnet innkapslingsoverheaden og ikke en feil.

PLPMTUD, beskrevet i RFC 4821, tester oppover og bruker transportbekreftelser i stedet for å stole på leverte feil. Det hjelper på baner som filtrerer ICMP, men støtten varierer etter stakk og etter applikasjon. En TCP-strøm kan komme seg av seg selv, mens en UDP-applikasjon med fast datagramstørrelse fortsetter å feile.

Velg en verdi og noter begrunnelsen

Å senke tunnel-MTU-en er både en diagnose og en legitim retting når du først kjenner banen. Det er ikke en erstatning for å vite hvilken bane og hvilken tilbakemeldingsmekanisme som var involvert, fordi en verdi tilpasset en mobillenke vil være unødvendig liten på en fiberforbindelse. Noter den valgte størrelsen, testen som begrunnet den og tilbakerullingssteget.

IPv4-mekanismen er beskrevet i RFC 1191 og IPv6-paketeringsveiledningen i RFC 8201; å nevne begge hindrer den neste ingeniøren i å utlede forutsetningen på nytt. Hvis overføringen fortsatt stopper ved størrelsen du valgte, slutt å senke tallet og se på neste lag. En bane som feiler ved enhver størrelse er ikke et MTU-problem.