VPN-MTU-myter: hvorfor dine pakker skrumper, og hvor pladsen bliver af

Nogen fortæller dig, at VPN'et "taber pakker på grund af MTU", du sætter tunnelen til 1400, og overførslen virker igen. Det resultat føles som en diagnose. Det er som regel et tilfælde i aritmetikken: du valgte et tal, der var lille nok til at passe under en grænse, du aldrig identificerede, og du møder den samme grænse igen på det næste netværk med et andet budget.

To myter forårsager det meste af dette. Den første er, at tunnelinterfacets MTU er stiens MTU. Den anden er, at indkapsling koster "én header" og PPPoE koster intet, der er værd at tælle. Begge er forkerte på måder, der får det tal, du vælger, til at se vilkårligt ud, når det faktisk er bestemt.

Myte et: tunnelens MTU er stiens MTU

Den værdi, du sætter på et tunnelinterface, er et lokalt løfte om den største indre pakke, som implementeringen vil give videre nedad. Stiens reelle kapacitet er en egenskab ved hvert led mellem dig og den fjerne ende, og den kan ændre sig, når en rute ændres, når en mobilforbindelse overlades, eller når trafikken tager en anden peering. En konfigureret 1500 fortæller, hvad din vært bygger, ikke hvad netværket bærer.

Opdagelse af stiens MTU findes for at forene de to, og den afhænger af feedback. Med IPv4 skal en router, der ikke kan videresende en pakke i fuld størrelse, sende en ICMP-meddelelse "fragmentation needed", og afsenderen sænker sit skøn. Med IPv6 er modstykket en Packet Too Big-meddelelse, og routere fragmenterer slet ikke undervejs. Når den feedback filtreres, bliver afsenderen ved med at producere pakker, som stien ikke kan bære, og intet fortæller den hvorfor.

Myte to: indkapsling koster én header

Tæl de ydre lag ærligt. En ydre IP-header er 20 byte ved IPv4 eller 40 ved IPv6. UDP-indkapsling til NAT-gennemgang tilføjer 8. Tunnelprotokollen tilføjer sin egen header, en initialiseringsvektor eller nonce, udfyldning til chifferens blok- eller justeringsgrænse, en trailer og en integritetskontrolværdi. Afhængigt af protokol og chiffer ligger totalen komfortabelt i snesevis af byte, før den indre pakke overhovedet begynder.

Træk derefter igen fra for den indre pakkes egne headere. Et TCP-segment inde i tunnelen bærer sin egen 20-byte IP-header og 20-byte TCP-header, og TCP's MSS udledes af MTU'en, ikke af tunnelens nominelle nyttelast. Derfor kan ping med en mindre nyttelast lykkes, mens en filoverførsel går i stå: værktøjerne tester forskellige ting, og kun én af dem udøver et TCP-segment i fuld størrelse.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

Den første kommando rapporterer den konfigurerede tunnel-MTU. De to prober sender en nyttelast på 1472 byte, hvilket med 28 byte IPv4- og ICMP-headere er en pakke på 1500 byte, og derefter en mindre. Hvis den store probe fejler helt, og den lille lykkes, har du en størrelsesafhængig fejl og ikke et generelt routingproblem.

Myte tre: PPPoE giver dig stadig rene 1500

Et konventionelt PPPoE-adgangsled bærer ikke en IP-pakke på 1500 byte. PPPoE-headeren plus PPP-protokolfeltet optager 8 byte inde i Ethernet-rammen, hvilket efterlader 1492 til IP-pakken. Det er den traditionelle grænse, der er beskrevet i RFC 2516. Kører du en VPN over sådan et led, kommer tunnelens overhead ud af de 1492, ikke af 1500.

RFC 4638 definerer en måde at forhandle en større PPP-nyttelast, når både adgangskoncentratoren og kundens udstyr understøtter det, og derfor beviser "denne forbindelse bruger PPPoE" alene ikke et bestemt tal. En lokal indstilling kan ikke få en mellemliggende enhed til at acceptere en pakke, den aldrig blev konfigureret til, så det nyttige spørgsmål er, hvad leddet faktisk forhandlede, ikke hvad etiketten siger.

Hvorfor fejlen virker selektiv

At små anmodninger lykkes, og store overførsler går i stå, er den klassiske signatur på et sort hul i stiens MTU. Håndtrykket, DNS-forespørgslen og API-kaldet passer alle; masseoverførslen producerer segmenter i fuld størrelse, der dør på ét led, og den ICMP-meddelelse, der skulle have rapporteret problemet, når aldrig frem. Forbindelsen ser fin ud, og downloadet hænger, hvilket får folk til at kigge på serveren i stedet for stien.

En anden, beslægtet fejl er at blande tre tal sammen: interface-MTU'en, TCP-MSS'en og protokollens egen fragmenterings- eller udfyldningsindstilling. MSS-clamping på en router omskriver den annoncerede MSS, så afsenderen bygger mindre segmenter; det ændrer ikke tunnel-MTU'en og hjælper ikke UDP-trafik. At give alle tre det samme tal, fordi de ser beslægtede ud, er måden, hvorpå en velment ændring ødelægger et fungerende setup.

Hvad skal ændres, og i hvilken rækkefølge

Begynd med beviser. Bekræft med proberne ovenfor, at fejlen er størrelsesafhængig, og find så den mindste størrelse, der går igennem, og den største, der fejler. Kontroller adgangsleddets reelle MTU, før du giver tunnelen skylden; et PPPoE-led begrænser budgettet, før din VPN rører det. Notér de oprindelige værdier, så ændringen kan rulles tilbage.

Anvend derefter den mindste justering, klienten dokumenterer. Mange klienter tilbyder en tunnel-MTU plus en MSS-rettelsesmulighed, og MSS-muligheden er ofte den bedre håndtag for TCP, fordi den når afsenderen uden at formindske hver pakke. Test samme destination og samme overførsel igen, og notér de tal, du landede på. En tunnelværdi, der virker på ét adgangsnetværk, er ikke en universel konstant, og det næste sted har sit eget budget.