Oppdaging av banen sin MTU gjennom eit VPN: dimensjonering og ICMP-holet

Ein tunnel fullfører handtrykket, små førespurnader kjem tilbake, og den første store overføringa stoppar. Dette mønsteret peikar på banen sin MTU lenge før det peikar på gjennomstrøyming. Kvar lenkje langs ruta avgrensar pakkestorleiken, og innkapsling brukar ein del av den kvoten på ytre headarar, så den indre pakken må vere mindre enn den rå banen skulle tilseie. Feilen er stille, og det er nettopp derfor han er dyr å diagnostisere.

Kva banen sin MTU faktisk målar

Banen sin MTU er den minste lenkje-MTU-en på ruta mellom to vertar, ikkje MTU-en som er trykt på det lokale grensesnittet ditt. Den lokale verdien er der anslaget byrjar, og banen avgjer kvar det må slutte. Det er derfor ein identisk tunnel kan fungere på eitt aksessnett og stoppe på eit anna: ruta endra seg, ikkje konfigurasjonen. Å måle ein gong og anta overalt er feilen som held dette problemet i live.

For ein tunnel er talet som betyr noko den indre MTU-en, som er den ytre banen sin kvote minus det innkapslinga brukar. WireGuard legg til ein ytre IP-header og ein UDP-header; andre transportlag legg til sine eigne. Set den indre storleiken for høgt, og kvar fullstorleikspakke treng fragmentering som kanskje aldri skjer.

Kvifor ein tunnel krympar den brukbare pakken

Viss tunnelgrensesnittet held på MTU-en til den fysiske lenkja, avheng kvar stor pakke av at nokon lenger nede er viljug til å fragmentere han. IPv4 tillèt det i prinsippet, men ein rutar som får beskjed om ikkje å fragmentere, returnerer ein feil i staden. IPv6-rutarar fragmenterer aldri undervegs, så same innstillinga oppfører seg ulikt etter adressefamilie. Uansett lærer avsendararen ingenting før noko rapporterer tilbake.

Den praktiske konsekvensen er ein storleik som passar i handtrykket og ikkje i nyttelasta. Ein TLS ClientHello eller ein DNS-spørjing er liten nok til å krysse ein krympa bane urørt, medan ei masseoverføring ikkje er det. Symptoma samlar seg derfor rundt bestemte operasjonar og ikkje bestemte vertar.

Oppdaginga verkar berre når tilbakemeldinga kjem fram

IPv4-oppdaging byggjer på don't-fragment-biten: ein rutar som ikkje kan vidaresende pakken, returnerer ICMP fragmentation-needed med MTU-en til neste hopp, og avsendararen senkjer anslaget sitt. IPv6 brukar Packet Too Big-meldingar i staden, fordi rutarar ikkje fragmenterer undervegs. Begge mekanismane føreset at meldinga finn vegen tilbake til avsendararen, gjennom tunnelen og forbi kvar brannmur på returvegen. Når den føresetnaden sviktar, held avsendararen fram med å prøve ein storleik som banen ikkje kan bera.

Ein brannmur som tillèt echo request og echo reply har ikkje nødvendigvis tillate dei feiltypane. ICMP er ein familie, og medlemmene som betyr noko her er feila, ikkje ekkoparet. Sjekk kontrolltrafikkpolitikken i begge endar av tunnelen og på vegen mellom dei, og følg den støtta rettleiinga til plattforma i staden for å tillate alle ICMP-typar overalt.

Den same filtreringa kan sitje inne i tunnelen. Viss den indre banen slepp feilen, men den ytre banen ber han, kan avsendararen tilpasse seg ei grense som den innkapsla trafikken aldri eigentleg ser.

Test banen i staden for å gjette eit tal

Hald destinasjonen, aksessnettet og tunnelen fast, og endre berre pakkestorleiken. Ein don't-fragment-test som feilar med eit MTU-hint gjev deg grensa for neste hopp; gjenta til ein storleik passerer, og noter både storleiken 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

Ein ping som passar beviser ikkje at fullstorleikssegmenta til ein ekte applikasjon passar, så gjenta testen med overføringa som faktisk feila. Samanlikn den største testen som verka med tunnel-MTU-en du konfigurerte, og hald dei to tala åtskilde i notata dine. Viss dei avvik med omtrent ein header, har du funne innkapslingsoverheaden og ikkje ein feil.

PLPMTUD, skildra i RFC 4821, testar oppover og brukar transportstadfestingar i staden for å stole på leverte feil. Det hjelper på baner som filtrerer ICMP, men støtta varierer etter stakk og etter applikasjon. Ein TCP-straum kan kome seg av seg sjølv, medan ein UDP-applikasjon med fast datagramstorleik held fram med å feile.

Vel ein verdi og noter grunngjevinga

Å senke tunnel-MTU-en er både ein diagnose og ei legitim retting når du først kjenner banen. Det er ikkje ein erstatning for å vite kva bane og kva tilbakemeldingsmekanisme som var involvert, fordi ein verdi tilpassa ei mobillenkje vil vere unødvendig liten på ei fibertilkopling. Noter den valde storleiken, testen som grunngav han og tilbakerullingssteget.

IPv4-mekanismen er skildra i RFC 1191 og IPv6-paketeringsrettleiinga i RFC 8201; å nemne begge hindrar den neste ingeniøren i å utleie føresetnaden på nytt. Viss overføringa framleis stoppar ved storleiken du valde, slutt å senke talet og sjå på neste lag. Ein bane som feilar ved kvar storleik er ikkje eit MTU-problem.