Path-MTU-opdagelse gennem en VPN: dimensionering og ICMP-hullet

En tunnel fuldfører sit håndtryk, små anmodninger kommer tilbage, og den første store overførsel går i stå. Det mønster peger på path-MTU længe før, det peger på gennemstrømning. Hvert led på ruten begrænser pakkestørrelsen, og indkapsling bruger en del af den tilladelse på ydre headere, så den indre pakke skal være mindre, end den rå sti ville antyde. Fejlen er tavs, og det er netop det, der gør den dyr at diagnosticere.

Hvad path-MTU egentlig måler

Path-MTU er den mindste led-MTU på ruten mellem to værter, ikke den MTU, der står på din lokale grænseflade. Den lokale værdi er, hvor skønnet starter, og stien bestemmer, hvor det skal slutte. Derfor kan en identisk tunnel virke på et adgangsnetværk og gå i stå på et andet: ruten ændrede sig, ikke konfigurationen. At måle én gang og antage det overalt er den fejl, der holder dette problem i live.

For en tunnel er det tal, der betyder noget, den indre MTU, altså den ydre stis tilladelse minus alt, hvad indkapslingen bruger. WireGuard tilføjer en ydre IP-header og en UDP-header; andre transportlag tilføjer deres egne. Sæt den indre størrelse for højt, og hver pakke i fuld størrelse kræver fragmentering, som måske aldrig sker.

Hvorfor en tunnel formindsker den brugbare pakke

Hvis tunnelgrænsefladen beholder den fysiske forbindelses MTU, afhænger hver stor pakke af, at nogen længere fremme vil fragmentere den. IPv4 tillader det i princippet, men en router, der får besked på ikke at fragmentere, returnerer i stedet en fejl. IPv6-routere fragmenterer aldrig undervejs, så den samme indstilling opfører sig forskelligt afhængigt af adressefamilien. Uanset hvad lærer afsenderen intet, før noget rapporterer tilbage.

Den praktiske konsekvens er en størrelse, der passer til håndtrykket og ikke til nyttelasten. En TLS ClientHello eller en DNS-forespørgsel er lille nok til at krydse en formindsket sti uberørt, mens en stor overførsel ikke er. Derfor klumper symptomerne sig omkring bestemte handlinger snarere end bestemte værter.

Opdagelse virker kun, når tilbagemeldingen når frem

IPv4-opdagelse hviler på don't-fragment-bitten: en router, der ikke kan videresende pakken, returnerer ICMP fragmentation-needed med næste hop-MTU, og afsenderen sænker sit skøn. IPv6 bruger i stedet Packet Too Big-beskeder, fordi routere ikke fragmenterer undervejs. Begge mekanismer forudsætter, at beskeden finder vej tilbage til afsenderen, gennem tunnelen og forbi enhver firewall på returvejen. Når den forudsætning svigter, bliver afsenderen ved med at forsøge en størrelse, stien ikke kan bære.

En firewall, der tillader echo request og echo reply, har ikke nødvendigvis tilladt de fejltyper. ICMP er en familie, og de medlemmer, der betyder noget her, er fejlene, ikke echo-paret. Kontroller politikken for kontroltrafik i begge tunnelender og på stien mellem dem, og følg platformens understøttede vejledning i stedet for at tillade enhver ICMP-type overalt.

Den samme filtrering kan sidde inde i tunnelen. Hvis den indre sti dropper fejlen, men den ydre bærer den, kan afsenderen tilpasse sig en grænse, som den indkapslede trafik aldrig faktisk ser.

Test stien i stedet for at gætte et tal

Hold destinationen, adgangsnetværket og tunnelen fast og variér kun pakkestørrelsen. En don't-fragment-test, der fejler med et MTU-vink, giver dig næste hop-grænse; gentag, indtil en størrelse passerer, og notér 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, der passer, beviser ikke, at en rigtig applikations segmenter i fuld størrelse passer, så gentag testen med den overførsel, der faktisk fejlede. Sammenlign den største fungerende test med den tunnel-MTU, du konfigurerede, og hold de to tal adskilt i dine noter. Hvis de afviger med omtrent en headers værdi, har du fundet indkapslingens overhead, ikke en fejl.

PLPMTUD, beskrevet i RFC 4821, tester opad og bruger transportbekræftelser i stedet for at stole på leverede fejl. Det hjælper på stier, der filtrerer ICMP, men understøttelsen varierer efter stak og applikation. En TCP-strøm kan komme sig selv, mens en UDP-applikation med fast datagramstørrelse bliver ved med at fejle.

Vælg en værdi, og notér begrundelsen

At sænke tunnelens MTU er både en diagnostik og en legitim rettelse, når du kender stien. Det er ikke en erstatning for at vide, hvilken sti og hvilken tilbagemeldingsmekanisme der var involveret, for en værdi, der er tunet til et mobilt link, vil være unødigt lille på en fiberforbindelse. Notér den valgte størrelse, den test, der begrundede den, og tilbagerulningstrinnet.

IPv4-mekanismen er beskrevet i RFC 1191 og IPv6-paketeringsvejledningen i RFC 8201; at nævne begge forhindrer den næste ingeniør i at udlede forudsætningen igen. Hvis overførslen stadig går i stå ved den størrelse, du valgte, så stop med at sænke tallet og kig på det næste lag. En sti, der fejler ved enhver størrelse, er ikke et MTU-problem.