VPN-MTU-myter: hvorfor pakkene dine krymper og hvor plassen blir av

Noen forteller deg at VPN-et "mister pakker på grunn av MTU", du setter tunnelen til 1400, og overføringen virker igjen. Det resultatet føles som en diagnose. Som regel er det en tilfeldighet i aritmetikken: du valgte et tall som er lite nok til å passe under en grense du aldri identifiserte, og du vil møte den samme grensen igjen på det neste nettet med et annet budsjett.

To myter forårsaker det meste av dette. Den første er at tunnelgrensesnittets MTU er banens MTU. Den andre er at innkapsling koster "én header" og at PPPoE ikke koster noe som er verdt å telle. Begge er feil på måter som får tallet du velger til å se vilkårlig ut når det faktisk er bestemt.

Myte én: tunnelens MTU er banens MTU

Verdien du setter på et tunnelgrensesnitt er et lokalt løfte om den største indre pakken implementasjonen vil levere nedover. Banens reelle kapasitet er en egenskap ved hver lenke mellom deg og den fjerne enden, og den kan endre seg når en rute endres, når en mobilforbindelse overlates, eller når trafikken tar en annen peering. En konfigurert 1500 forteller hva verten din bygger, ikke hva nettet bærer.

Oppdagelse av banens MTU finnes for å forene de to, og den avhenger av tilbakemelding. Med IPv4 skal en ruter som ikke kan videresende en pakke i full størrelse, sende en ICMP-melding "fragmentation needed", og avsenderen senker anslaget sitt. Med IPv6 er motstykket en Packet Too Big-melding, og rutere fragmenterer ikke i det hele tatt underveis. Når den tilbakemeldingen filtreres, fortsetter avsenderen å produsere pakker som banen ikke kan bære, og ingenting forteller den hvorfor.

Myte to: innkapsling koster én header

Tell de ytre lagene ærlig. En ytre IP-header er 20 byte ved IPv4 eller 40 ved IPv6. UDP-innkapsling for NAT-gjennomgang legger til 8. Tunnelprotokollen legger til sin egen header, en initialiseringsvektor eller nonce, utfylling til chifferens blokk- eller justeringsgrense, en trailer og en integritetskontrollverdi. Avhengig av protokoll og chiffer ligger totalen komfortabelt i titalls byte før den indre pakken i det hele tatt begynner.

Trekk så fra igjen for den indre pakkens egne headere. Et TCP-segment inne i tunnelen bærer sin egen 20-byte IP-header og 20-byte TCP-header, og TCP-ens MSS utledes fra MTU-en, ikke fra tunnelens nominelle nyttelast. Derfor kan ping med mindre nyttelast lykkes mens en filoverføring stopper: verktøyene tester forskjellige ting, og bare ett av dem øver på et TCP-segment i full 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 kommandoen rapporterer den konfigurerte tunnel-MTU-en. De to probene sender en nyttelast på 1472 byte, som med 28 byte IPv4- og ICMP-headere er en pakke på 1500 byte, og deretter en mindre. Hvis den store proben feiler helt og den lille lykkes, har du en størrelsesavhengig feil og ikke et generelt rutingproblem.

Myte tre: PPPoE gir deg fortsatt rene 1500

En vanlig PPPoE-tilgangslenke bærer ikke en IP-pakke på 1500 byte. PPPoE-headeren pluss PPP-protokollfeltet tar 8 byte inne i Ethernet-rammen, noe som etterlater 1492 til IP-pakken. Det er den tradisjonelle grensen som er beskrevet i RFC 2516. Kjører du en VPN over en slik lenke, kommer tunnelens overhead ut av de 1492, ikke av 1500.

RFC 4638 definerer en måte å forhandle om en større PPP-nyttelast når både tilgangskonsentratoren og kundens utstyr støtter det, og derfor beviser "denne forbindelsen bruker PPPoE" alene ikke et bestemt tall. En lokal innstilling kan ikke tvinge en mellomliggende enhet til å godta en pakke den aldri ble konfigurert for, så det nyttige spørsmålet er hva lenken faktisk forhandlet, ikke hva etiketten sier.

Hvorfor feilen virker selektiv

At små forespørsler lykkes og store overføringer stopper, er den klassiske signaturen på et svart hull i banens MTU. Håndtrykket, DNS-spørringen og API-kallet passer alle; masseoverføringen produserer segmenter i full størrelse som dør på én lenke, og ICMP-meldingen som skulle ha rapportert problemet, kommer aldri frem. Forbindelsen ser fin ut og nedlastingen henger, noe som får folk til å se på serveren i stedet for banen.

En annen, beslektet feil er å blande tre tall: grensesnittets MTU, TCP-ens MSS og protokollens egen fragmenterings- eller utfyllingsinnstilling. MSS-clamping på en ruter skriver om den annonserte MSS-en slik at avsenderen bygger mindre segmenter; det endrer ikke tunnel-MTU-en og hjelper ikke UDP-trafikk. Å gi alle tre samme tall fordi de virker beslektet, er måten en velment endring ødelegger et fungerende oppsett.

Hva skal endres, og i hvilken rekkefølge

Begynn med bevis. Bekreft med probene ovenfor at feilen er størrelsesavhengig, og finn den minste størrelsen som går gjennom og den største som feiler. Kontroller tilgangslenkens reelle MTU før du gir tunnelen skylden; en PPPoE-lenke begrenser budsjettet før VPN-en din berører den. Noter de opprinnelige verdiene slik at endringen kan rulles tilbake.

Bruk deretter den minste justeringen klienten dokumenterer. Mange klienter tilbyr en tunnel-MTU pluss et MSS-reparasjonsvalg, og MSS-valget er ofte den bedre spaken for TCP fordi det når avsenderen uten å krympe hver pakke. Test samme destinasjon og samme overføring på nytt, og noter tallene du landet på. En tunnelverdi som virker på ett tilgangsnett, er ikke en universell konstant, og neste sted vil ha sitt eget budsjett.